Today I wanted to talk about my path as an engineering manager. It's a story I've told to countless team members before to help frame their career advancement in a way that enhances the appeal of engineering management; a path most engineers I know avoid.
A lot of engineers get into engineering so they can build things. This desire to create is the passion that drives them to work countless hours. This desire is what inspired me to become an engineer. I love building things. I love being able to look at a finished product knowing I made it. I built legos as a kid, and now I engineer things for a living.
Although there is nothing wrong with staying on the technical path, I know quite a few engineers who purposely avoid the managerial path. There are always different reasons why, but a frequent one I hear is they want to keep their hands' dirty building something.
I too was a reluctant engineering manager. I'm an introvert who prefers to put my head down and bust out code. The thought of having to deal with everyone's drama, both personal and professional, is not appealing. However, at the time, the only path to career advancement was through management. The company was very focused on headcount. The more headcount you had, the more "important" you appeared and the more compensation you received. So off I went into the managerial path.
I can't say it was a smooth ride to start. But at a certain point, I changed my perception which changed the game. I quickly realized I didn't want to get bogged down in the weeds of people management. It wasn't rewarding enough. Plus it had a low ROI where I might put in a lot of effort to help a single person advance to have them eventually move up the ladder or move on to a different company. Instead, I focused on the culture, environment, and process. In other words, I started engineering the team.
For example, I have team members in the US and team members overseas. If someone complained about communication problems with their overseas counterparts, I analyzed the environment. I could have looked at trying to coach a single person on how to increase their communication skills, but that gives a very low ROI. Instead of trying to correct individuals, I would look at how could we change our tools or processes to promote communication.
This thought process led to holding the majority of team discussions, including daily standups, in IM so everyone could catch up to the conversation on their own time and contribute. No one was left out. All team status or staff meetings were moved to a wiki so that both the US and overseas could remain informed. This change ensured everyone was treated equally and could get the same updates. When doubling up engineers to work on a task, I would purposely assign one from each time zone to force them to collaborate. This assignment forced people to break out of their comfort zone and break communication barriers.
Additionally, I encouraged everyone to send their peer code reviews to someone in a different time zone instead of the person sitting next to them. This encouragement taught them to seek out new team members on their own. Even peer code reviews had guidelines on how to review to avoid divisive and confrontational language and promote collaborative and constructive dialogue. I could go on, but every part of the team was thought out to encourage communication.
Not everyone warmed up to this culture, and some people left. But the people who stuck around have become highly collaborative across time zones, cultures, and consider all their teammates as close peers. Over the years continue growing; we continue to hit growing pains; we fall into our old traps, but we've managed to remain highly collaborative throughout it all because we engineered the team that way. It naturally falls into place more than it falls apart.
Communication is just one example, but I engineered every possible aspect of my teams in this manner. Once I viewed management as engineering a team culture, I became highly engaged. It became an exciting challenge to look at tendencies and patterns that emerged, and through modifications to the team setup, change the natural outputs into something desirable. This process became my primary focus; I go to work to make sure they can work well together and deliver at the highest level of productivity possible. Team engineering became more rewarding than software engineering ever did.
It didn't stop at engineering the team. At this point, I've engineered multiple high performing and versatile teams. My attention has been freed up to move even higher. I now engineer the system. Figuring out how everyone's finished projects interact, how each team interacts with each other, how different disciplines (engineer or product manager) interact, how different personas (employees or customers) communicate, and even how our products interact with the customers and how it should grow. In other words, I'm turning director responsibilities into an engineering challenge too.
It turns out, a change in perspective can take an undesired pain point and turn it into an exciting engineering challenge.
(Written 2019.05.04)
A lot of engineers get into engineering so they can build things. This desire to create is the passion that drives them to work countless hours. This desire is what inspired me to become an engineer. I love building things. I love being able to look at a finished product knowing I made it. I built legos as a kid, and now I engineer things for a living.
Although there is nothing wrong with staying on the technical path, I know quite a few engineers who purposely avoid the managerial path. There are always different reasons why, but a frequent one I hear is they want to keep their hands' dirty building something.
I too was a reluctant engineering manager. I'm an introvert who prefers to put my head down and bust out code. The thought of having to deal with everyone's drama, both personal and professional, is not appealing. However, at the time, the only path to career advancement was through management. The company was very focused on headcount. The more headcount you had, the more "important" you appeared and the more compensation you received. So off I went into the managerial path.
I can't say it was a smooth ride to start. But at a certain point, I changed my perception which changed the game. I quickly realized I didn't want to get bogged down in the weeds of people management. It wasn't rewarding enough. Plus it had a low ROI where I might put in a lot of effort to help a single person advance to have them eventually move up the ladder or move on to a different company. Instead, I focused on the culture, environment, and process. In other words, I started engineering the team.
For example, I have team members in the US and team members overseas. If someone complained about communication problems with their overseas counterparts, I analyzed the environment. I could have looked at trying to coach a single person on how to increase their communication skills, but that gives a very low ROI. Instead of trying to correct individuals, I would look at how could we change our tools or processes to promote communication.
This thought process led to holding the majority of team discussions, including daily standups, in IM so everyone could catch up to the conversation on their own time and contribute. No one was left out. All team status or staff meetings were moved to a wiki so that both the US and overseas could remain informed. This change ensured everyone was treated equally and could get the same updates. When doubling up engineers to work on a task, I would purposely assign one from each time zone to force them to collaborate. This assignment forced people to break out of their comfort zone and break communication barriers.
Additionally, I encouraged everyone to send their peer code reviews to someone in a different time zone instead of the person sitting next to them. This encouragement taught them to seek out new team members on their own. Even peer code reviews had guidelines on how to review to avoid divisive and confrontational language and promote collaborative and constructive dialogue. I could go on, but every part of the team was thought out to encourage communication.
Not everyone warmed up to this culture, and some people left. But the people who stuck around have become highly collaborative across time zones, cultures, and consider all their teammates as close peers. Over the years continue growing; we continue to hit growing pains; we fall into our old traps, but we've managed to remain highly collaborative throughout it all because we engineered the team that way. It naturally falls into place more than it falls apart.
Communication is just one example, but I engineered every possible aspect of my teams in this manner. Once I viewed management as engineering a team culture, I became highly engaged. It became an exciting challenge to look at tendencies and patterns that emerged, and through modifications to the team setup, change the natural outputs into something desirable. This process became my primary focus; I go to work to make sure they can work well together and deliver at the highest level of productivity possible. Team engineering became more rewarding than software engineering ever did.
It didn't stop at engineering the team. At this point, I've engineered multiple high performing and versatile teams. My attention has been freed up to move even higher. I now engineer the system. Figuring out how everyone's finished projects interact, how each team interacts with each other, how different disciplines (engineer or product manager) interact, how different personas (employees or customers) communicate, and even how our products interact with the customers and how it should grow. In other words, I'm turning director responsibilities into an engineering challenge too.
It turns out, a change in perspective can take an undesired pain point and turn it into an exciting engineering challenge.
(Written 2019.05.04)
