I used to be a M2 and manage a 30 people team. But in 2014, I became a M1 and only manage 3 people. It was a deliberate choice I made. I have been asked many times why I made such a choice, since such a choice seemingly hurts my career. I guess it’s a good idea to write the answer down if it’s asked repeatedly.
Here it is:
Azure shifted to the combined engineering model in 2014. Before that shift, we were in a functional model: I was the test manager and I had 30 people, including SDETs and test leads. I reported to a Director of Test, who reported to a VP of Test. The dev manager that I partnered with had 60 people, including SDEs and dev leads. He reported to a Director of Dev, who reported to a VP of Dev. After the shift, all individual contributors were now SWEs (Software Engineer). Their managers were Engineering Managers, who reported to Group Engineering Managers, who reported to a Director of Engineering, or a VP of Engineering.
Back in 2014, when the leadership pulled the trigger to make the combined engineering shift, I sat down with my dev manager. I told him that in my view, the best way to implement that change is to simply merge our two teams, put the SDEs and SDETs who used to work on the same projects and components under the same engineering manager, who might be the previous dev lead, or the previous test lead. That way gives us the best continuity, minimum tribal knowledge loss and minimum disruption to the projects.
The question was where I would be after the merge.
First to decide is whether I would remain in the team or not. For the benefit of the team, I chose to stay. Two reasons. For one, I had quite some tribal knowledge, as I was quite a hands-on manager (but not micro managing). If I leave right after the merge, those knowledge will be lost. For two, my staying in the team would demonstrate my commitment and support to this paradigm shift of combined engineering. That will help the team maintain the morale level and keep attrition low. These all serve the team’s best interest.
Now I had chosen to stay. The next question: what should be my team size.
I applied two principles. They are, not in any particular order: first, only one chef in a kitchen; second, less layers. If I remain in the same team and continue to have a large team, there would be only two choices: a) I remain as a “sibling” as the dev manager (now group engineering manager), b) I report to the dev manager. The choice (a) violates the first principle. The choice (b) violates the second principle, since managing a large team means I would have a couple leads. Therefore, in order to stay in the team and not violate my two principles, I should have a smaller team.
Last question: why only 3 engineers.
That’s at the low end of how many people a M1 usually manages. After the combined engineering shift, the top-down guidance was around 10-12 engineers for each M1. I went for a lower number for two reasons. First, I wanted to lower my managerial work load since the combined engineering was a new thing to me. That’s similar to that when I first came to US in 2010, I started with managing only one person. I picked up more after I got familiar with the new country, new culture and new working environment. Second, these 3 engineers were all top performers. I wanted to see what it is like to have a Navy SEAL team: small in number, but each team member is highly capable. That was intriguing as I never had such a chance before.
That’s the whole story.
I left that team in a year. By the time I left, knowledge had been shared, everybody had settled in their new roles and the transition to the combined engineering model was completed successfully a while back. Since then, I have been focused on a different area under the same VP. The choice I made in 2014 did disrupt my career growth a little bit, but I got back on track soon. In my current role, I still only manage 3 engineers. That’s mainly because it’s the optimal resourcing model for the problem space that I am working on. That will be a story for another day.
