Is Becoming an EM a Promotion

Problem

In the early days of my career, I would equalize becoming an engineering manager and being promoted. And certainly, I was not the only one. For quite some time, I believed that I wanted to become an EM because it felt like a natural progression, the next step on the career ladder.

Once I became an EM for the first time, I realized how the reasons that drove me to the role might not be the right ones. I questioned my motivation candidly and thoroughly. If I didn’t, I would end up in a role I didn’t understand, which then wouldn’t allow me to be productive and meet the expectations. I underwent a profound mindset change that helped me approach my new role from an entirely different perspective.

Actions taken

For starters, I put a 30/60/90 days check-in plan for myself and made sure to follow it day by day. I did extensive research on what an EM role entails in different industries and settings. Before delving into the role, I knew little about it and what would be expected of me. This is not an uncommon scenario. Oftentimes, a person does well as an IC and is made an EM without any training or coaching provided. One day you are promoted; the next day, you are managing a team.

After I gathered some information through reading, I compiled a list of core responsibilities and structured my working week accordingly. I realized that I would have to make some tradeoffs to make the most of my new role. To start with, I began to spend more time working together with the team on developing solutions. Though it was faster and easier for me to do some things by myself, I wanted to be a true enabler who would help the team come up with a solution instead of telling them what to do. If I kept telling them what the solution was, I would become a permanent bottleneck and would curtail their growth.

Next, I initiated closer collaboration with internal stakeholders, most notably product, design, and QA people. From the technical product management perspective, I had to ensure continuous progress in terms of my sprint goals. To do so, I wanted to make sure I would be providing timely updates and flagging things early on to other stakeholders. That would allow them to course-correct or readjust their activities. I wanted them to be informed timely about what was happening in Engineering, and I wanted to be proactive; hence I would be the one to share (unsolicited) updates frequently.

In the end, I had to become more versed in the subtle art of delegation and stop doing every single thing by myself. I wanted to utilize my team to its full potential and leverage the strengths of my team members. Oftentimes, I would overcommit to a number of action items, and with back-to-back meetings and context switching, I wouldn’t be able to deliver if I didn’t delegate. I would trim down the to-do list to what would be reasonable and achievable and then give the team the opportunity to take ownership and demonstrate accountability by taking some action items off that list.

I would also try to nurture trust with my direct reports. This comes in stark contrast to what were my priorities as an IC, where I was concerned about myself and my output only. Now, I want to make the team and every individual on that team happy, which can mean different things to different people. For some, it is having clarity, while others prefer work-life balance or attending meetings; getting to know their goals and figuring out what makes them happy is a key to building trust.

Lessons learned

• Question your motives when transitioning from an IC to a manager. By questioning, I don’t mean self-doubt but digging deeper into your motivation and values. Are you ready for new responsibilities? Are you aware of the expectations the new role carries? Make sure you can answer what I call “suggestive signals” about the role -- is it about financial compensation, influence, authority, or personal growth. Some of those, in my opinion, are not the right signals.
• You can practice self-leadership at any stage of your career. If you want to demonstrate leadership, you can pick any task and make it a polygon to demonstrate your leadership skills. Financial compensation is something I consider a by-product, and for people who want to get promoted without becoming managers, many companies offer dual career tracks. If you don’t want to become a manager, make sure that the company offers a tech career path.
• Get used to the fact that success will be more abstract. When I was an engineer, I had very tangible metrics before me of what made me successful: lines of code, number of features, the complexity of a solution, etc. That is vanishing as you move up the ladder, and you will need to come up with metrics that are much less tangible. For example, some of my metrics that, as a manager, I find relevant are that my team is happy, that they don’t have any blockers, that we collaborate well with different stakeholders, etc.