20 things I learned as a Lead engineer

5 minute read

dist files

In this post I’m going to talk about my learnings as a lead engineer in this last 2 years. I can be wrong in some points, it’s my opinion and my thoughts wrote down here in this post.

1 - Create a team environment where it’s safe to talk.

It’s important that all the team members are able to express their views on a particular subject without fear. All opinions are valuable, as long as the opinions are expressed with respect and without harming nobody in the team. The team accepts challenge but disrespectful attitudes are not.

2 - Recognize team and individual achievements.

Every time a team member gets something delivered to production it’s important to recognize the good work done. When there’s a milestone or something is achieved is a good moment to stop and give kudos. Recognizing the effort done is important.

3 - Let the team come up with the answer.

This is not always possible but as long as the team comes with the answer everybody is more open to contributing to the task and feel more part in the decision-making. Our job here is to guide in a way that the answer is suitable for the project, team and company interests.

4 - Reaching agreements within the team.

Open the conversation with the team members about some topic to see if it’s possible to reach an agreement. It’s better to listen to all the opinions and reaching a team agreement about some topic is the way to go.

5 - You can’t force individuals to grow.

Self-development it’s an individual responsibility, you can’t force someone to a place that doesn’t want to go. Maybe this person doesn’t know where he can go or this person prefers to stay in the same place because it’s difficult to go out from the confort zone. You should read people and what they want asking questions. If a team member wants to grow you need the commitment of this person with actions that go in the direction that this person wants to go and help him.

6 - Redirect questions to a common team channel.

You cannot be a single point of failure. What if you go on holiday? The team needs to keep working without you. If you respond to all the questions even if you can answer them, your team doesn’t learn and doesn’t grow. You have to make that the team is able to respond and look for the responses.

7 - Document team processes.

If there are processes that are not automated and someone has to follow a list of tasks to reach a goal it’s important to have documentation where these processes are explained. You should use some kind of wiki to document these things.

8 - Document the asked questions.

To avoid repeating the same answers to people is good to have a place with all the asked questions. Having them in a common wiki where everybody can access to this documentation it’s the best practice. Share the knowledge.

9 - Protect team focus.

Is good to do a rotative role that handles interruptions during the week, this way the people of the team that is not in charge of handling interruptions can keep working on what they were doing.

10 - Set clear expectations.

If you set expectations for team members, then there will be no surprises in the assessments because you would have set expectations beforehand. In assessments there should not be surprises.

11 - Help to unblock tasks.

Helping the team members to work without blockers or to work around them is also a duty of a lead engineer. Any doubts or blockers you can help are more than welcome for your team members.

12 - Communicate all the important things to the team.

The people on your team want to receive the relevant information about the company, area at the right time. Weekly team meetings is a good moment to share this information with the team because there they have space to give their opinions or view on the subject.

13 - Reduce development efforts by reducing the project scope.

There are times when stakeholders can ask for more things that are necessary to deliver a project. Reducing the scope to deliver the minimum value product (MVP) it’s the right thing to do because it frees the team to do other tasks.

14 - Listen more than you talk.

You have to listen more than you talk, we have 2 ears and 1 mouth. Seems obvious but it’s important to listen to people and not only in your job also in your life.

15 - Delegate the task to the right profile.

You can’t delegate the most difficult task to the person with less experience in the team, and you cannot also delegate the easiest task to the person that is more senior of the team because he will get bored.

16 - Have metrics to improve as a team.

If you want to improve something, you have to have metrics and review them . The next step is also to take action on those metrics.

17 - Communicate what the team does in your vertical area and the impact.

If your team is working in an area with many teams is good to communicate what your team is doing. It benefits your team because gives you more clarity to write down past deliveries.

18 - Challenge/discuss why some project has to be done.

Questioning why a project has to be done is a good way to select the projects that have more impact from the ones that have less impact or are less meaningful.

19 - Have an open agenda for team meetings.

Having an agenda for the team meetings is something that helps to engage more the team members to attend and take part in those meetings, because during the week everyone is encouraged to fill the agenda, and topics that there’s no time to discuss in other meetings are good candidates to appear in that agenda.

20 - Adapt methodologies to your context and team.

Not breaking the work in progress (WIP) it’s a rule in kanban where you try to avoid multitasking within the members of the team. If the WIP is broken for some hours is not the end of the world or if you want to do a prioritization meeting at the begining of the week even that this event doesn’t exist and the team agrees on doing that is ok to do it.

Alex Manrique