Learnings after a year as an engineering manager

One year ago, Cabify gave me the opportunity to make a change in my professional career. Until that moment, I was working as a Software Engineer, and I was offered to switch to the management path.

At that time, I thought that you would only need to be empathetic to be a good Engineering Manager (EM). Now I know how wrong I was, because I needed to learn a lot of other aptitudes to lead a team properly.

During this year I learnt a lot of useful topics and frameworks for this role, and I would like to reflect a high overview of the most important ones to me in this article.

The People

With the career switch, all of my responsibilities changed. Now, the important ones were the motivation and the professional growth of the engineers.

When I talk about motivation I refer to two aspects:

• Ensure that people understands the team’s purpose so they are aligned with the company’s vision.

• Understand the engineers’ motivation, and spark their interest in the product and the project.

When working on motivating an engineer, it is important to set clear expectations, otherwise they can end up disappointed and frustrated.

I like to discuss and explicitly agree with the engineer these expectations, so I can encourage them to deliver.

For many people, their expectations and motivations are directly related with their professional growth. Finding opportunities where they can learn new skills and demonstrate what they have learnt usually works really well. If your company has a list of competencies and responsibilities defined for each role and level, this can be a good starting point to find these opportunities.

One of the most useful tools that a manager can have to work on this is the One on One.

The 1:1 is a private and recurrent meeting between the manager and the direct report. This space will be used to:

• Give and receive feedback.

• Ensure that the engineer is motivated and understands the team’s purpose.

• Follow up on their professional career.

• Deal with conflicts and try to solve them.

• Correct undesirable behaviours.

This meeting will help you to build a relationship of trust, increasing the efficiency of the 1:1. Engineers will be more comfortable and open when talking to you.

As mentioned before, the 1:1 could be a good place to give feedback, but also to receive it. I try to ask for feedback using specific examples or situations like what could I improve on this presentation? *instead of using an open question like *do you have any feedback for me?.

Also, I usually use this meeting as a good opportunity to see if there is something that I can do for the engineers or to see how I can help them.

When talking about feedback, we have to take into account that it has to be clear and focused on behaviour and facts. There are a lot of frameworks to help with it. A well-known one is the COIN model¹, that follows the guidelines below:

• Context. Give information about what was the issue or event that you want to discuss.

• Observation. Show what was the specific fact that happened.

• Impact. Explain what was the positive or negative impact that it had on the project, colleague, team or company.

• Next Steps. Make an agreement about the action that we are going to take.

Recently, I read about the concept of Radical Candor², and I think it is well worth mentioning it here. This concept, developed by Kim Scott, says that to build a candid culture of feedback and guidance, the manager has to:

• Care personally. It means that you should care about the people and build a relationship that goes beyond work. Listen them. And, as Kim says, put their needs first above yours.

• Challenge directly. It means that you have to be honest and clear when telling the people that they are not meeting expectations.

The Team

One of my responsibilities as a manager is empowering the team and making the most out of them.

I have tried to build a safe place, where people can contribute, participate and provide feedback without being judged. Because every opinion matters, I tried to create a diverse and inclusive environment. Note that the inclusive part is key here, it doesn’t make sense having a team of junior and senior people if the decisions are always made by the senior ones.

Don’t forget about communication, because it can take you to success or to failure. For example, if you are in a distributed team, work more asynchronously³ and avoid unnecessary meetings and interruptions. This will help everyone to be more focused on the important tasks.

Another aspect to take into account is fulfilling the role of a Servant Leadership⁴. This means that above all, you have to be at the team’s disposal.

When dealing with conflicts, listen, be empathetic, adopt an unbiased position and always **assume good intentions **from the people.

The Project

When I started with this new role, I thought that I should be the main responsible for any given project. But I was wrong there. I had to understand that the project belongs to all the people involved in it.

I have to ensure that I’m not a bottleneck. I don’t have to be the person that has an answer for everything and especially the person that makes the final decision. Instead, I have to be the person that knows where to find the answers. I have to encourage the team to unblock themselves providing the necessary tools that allow them to grow.

Sometimes, when we are discussing a technical solution or an issue, we never get a final decision and the conversation never ends. This situation leaves us in the well-known analysis paralysis⁵**. **Try to avoid this. A nice approach to solve this problem could be releasing smaller deliverables. Split the problem into small pieces, start by one, and then iterate it. It doesn’t matter if it is not perfect, once it is released you will have time to improve it.

The Product Mindset

Since I’m working for a product company, I find very important that everyone on the team embraces a product-focused mindset. This is not just about working closely with the Product Manager and being aligned with them.

An important part, and key for the success of the product, is that the team has a sense of ownership. We should encourage them to use technology to find the best solution to the problems presented⁶.

To achieve this, engineers should be participants in the decision making process for the product from the beginning, not only be coders. We are doing it wrong if the problems are presented to them with a final solution ready to be developed at the beginning of each Sprint.

As you see, the article is focused on topics that require time and preparation. So it is important that you have enough time and space to think carefully about the next steps that you are going to take.

The most challenging and helpful aspect that I had to embrace is that the vision has changed with the new role. Stop focusing on the tactical tasks (short term), and **start thinking strategically **(long term). This is a long journey, and you have to be prepared for those uncertain things that will come in the future.

https://svpg.com/the-most-important-thing/