Growing Engineering Organization: One Step At a Time

Problem

When we were acquired by a large company I was working on a small engineering team of five people. In two years we scaled from seven to 30 engineers -- more than quadrupling the number of people. The rapid scale impacted both the existing and newly arriving employees as well as managers who were handling that growth. I faced multiple challenges along the road that I dealt with one step at a time.

Actions taken

I was initially tempted to manage everything by myself. I was avoiding hiring managers and deliberating on the organizational structure. Hiring only engineers positively impacted scale and velocity short-term, but threatened to harm not only my performance and well-being as a manager but the efficiency of the organization as a whole.

I had to delegate some of my responsibilities but we were short of managers who could take it on. Moreover, we lacked the organizational structure that would enable those managers to propel our work forward.

For starters, I had to develop the organizational structure that would serve our need for rapid growth. I would sit down with every person on the team to discuss the draft that included roles and responsibilities and solicit their feedback and ideas. I received far better feedback than I could have possibly imagined. I tried not to be misled by what would look good in the Powerpoint presentation and I relied on the perspective of my employees. For example, if I were to place a UI engineer in every team -- because presumably, every team would need one -- I would have to confront realistic arguments of my engineers who would then explain to me that they had already established good cooperation with another team that excelled at UI. Moreover, people would be very appreciative that their voice had been heard which increased their engagement and sense of ownership.

When developing the structure, you should think about roles and responsibilities, write that down, instill it into every new leader and a new team, and repeat it unsparingly. I made sure to avoid any blind spots around who owns what and why. The latter you would deal with that, the more opportunities would be lost. By the time people would start shifting their responsibilities around, it would be much harder to fix the problem. I would bring a chart with me and facilitate a session during which I would encourage feedback from the team. They would likely add a problem you overlooked or further specify (part of) a role.

I would follow the MECE principle (Mutually Exclusive, Collectively Exhaustive) principle when I was developing our structure. I wanted the teams to be functional and able to cover a variety of different tasks but you want them to be -- as seen from the outside -- as much autonomous and self-reliant. I would always give teams autonomy but I would stay away from managing dependencies.

Hiring and recruiting is always hugely time-consuming as well as onboarding and introducing new people to all the details of your ongoing business and I was putting that off for a while. Only once when I was unable to streamline a focus on my own responsibilities, I started to think about adding a few managers to the team.

Lessons learned

• I started to think about the organizational structure too late. Growing internal leaders or hiring external managers takes more time than onboarding new engineers. If you start onboarding new engineers without having EMs you will end up with too many direct reports and most likely the complete overwhelm. Then, you’ll get stuck in a vicious circle of not having time to grow people, while not having people means that you will have to do everything by yourself and have no time for anything else, including growing people. Think about prospective leaders in advance, identify those with leadership potential on your team before you even start to grow.
• Usually, organizations are structured from the front- to back-end and database teams where people are organized by their expertise while the work needed to support the business should usually require their cross-functional collaboration. Leaders you will choose should be able to manage people to have their work done, not manage different capabilities.
• Initially, when I was deciding on new managers I was looking for high performers among ICs and more often than not that didn’t work. More than once I was disappointed by people who were highly productive as ICs but failed as leaders managing people.