Growing Engineering Organization: One Step At a Time
2 August, 2020
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.
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.
- 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.
Himanshu Gahlot, Director of Engineering at Lambda School, explains how he improved the hiring process at his new company by applying the knowledge he acquired working on different teams with different hiring processes in place.
Director of Engineering at Lambda School
Pete Murray, Principal Software Engineer at Electronic Arts, discusses what makes one a great engineering leader and singles out creating opportunities and motivating engineers as two key characteristics.
Principal Software Engineer at Electronic Arts
Adam Bauman, Engineering Manager at Quizlet, shares how he had to find his way through when the company he was working at transitioned from one stage to another leaving many people redundant.
Engineering Manager at Quizlet
Mason Mclead, CTO at Software.com, highlights all the advantages of hiring at once a group of people who have already worked together.
CTO at Software.com
David La France, VP of Engineering at Kenna Security, explains how managers can level up their skills and scale in their roles by learning to work less, but smarter.
David La France
VP Engineering at Synack
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.