Lessons learned in managing engineering team growth
Over the last couple of years the engineering team at Mendix has grown fast. Over the last 1.5 years the team has almost doubled and we are still looking for bright minds. There is a lot that can and will go wrong if you grow this fast. Here are my four most important lessons learned during the process (disclaimer: a lesson learned doesn’t necessarily mean that I execute it flawlessly 😉 ):
Try to avoid team growth
Bo Burlingham describes 14 companies in his book “Small Giants” that “choose to be great instead of big” (my review). I like the gist of that book: focus on being great in every area of the business, grow only when necessary, and only if it doesn’t compromise your core values.
Growing the engineering team should never become a goal itself. For a lot of things it is better to have a small team. No need for “managers”, less overhead, everybody is aligned, easier to maintain emotional attachment to business, just to name a few. So, don’t listen to your first urge to hire more people. For me the first assignment when thinking about team growth is not writing a new vacancy, it is having an in-depth product management discussion.
In software development there is always a long list of things that need to be done. Backlogs with ideas for product improvements are often long and grow easily. This could easily lead to the conclusion that more engineers are needed to cope with this backlog. However, the first questions to ask are: what’s most important? What improvement will have the most impact? Do we really need to have all of this at a certain deadline? And if so, do we need to build it ourselves? Can we outsource, partner, buy? What is the unique value of our product and should hence be our focus?
That being said, there are times that (fast) growth is needed to grab opportunities and to stay innovative in all important areas of your product.
Manage team growth by building stable teams
They key to scaling an engineering organisation is stable teams. Chris Fry compares it with the Roman army:
“One of the most scalable organizations in human history was the Roman army. Its defining unit: The squad — eight guys. The number of guys that could fit in a tent.”
Build on that lesson, what we need to build an efficient engineering organisation is to build strong teams first and assign them problems later. If a team works well together their output can be so much better than just the sum of the individuals. That’s why you need to focus on building stable teams that have a high level of trust. To quote Chris again:
“This is one of the key reasons to keep teams together. Trust is a much bigger deal than most people think in this context. But trust breeds healthy communication, and that’s ultimately what boosts you into that high-performance zone where teams tackle problems with all cylinders firing.”
Stable teams of talented people with a clear mission are unstoppable.
Create new teams by splitting them out of existing teams
The question that immediately follows is how to form these teams. The first advice here seems to be in contradiction with the previous section: always create new teams by splitting them out of existing teams. It is essential to form new teams around “old-timers”, engineers that have been in your organisation for a longer time. This ensures a proper transfer of knowledge, best practices, and, maybe even more important, culture.
To align this team growth lessons learned with the previous one you should consider these suggestions:
- Try to keep teams as stable as possible, don’t let the same people endure more than one team split per year.
- Consider to start a new team with a core of people that already highly trust each other.
- It is much easier to create trust in a team if you only add A-players to a team of A-players.
Avoid the most common team growth pitfall
Why is it that so many larger organisations don’t seem to be better or faster in delivering quality software? The biggest challenge in engineering team growth is to avoid an exponential growth of dependencies among teams. The key here is to avoid hand-offs. There are two main approaches to do this:
- Build autonomous, cross-functional teams: teams should be able to build and release functionality all by themselves. This means that teams should be cross-functional, including quality assurance. There are no hand-offs needed to get new functionality into production.
- Make “hand-offs” self-service via APIs: there will always be things that a team needs from other teams. Features that need work from multiple teams or teams that build on top of layers provided by other teams. In these cases hand-offs should be “hardened” in APIs. This turns a dependency into a self-service capability. Some clarifying examples: your infra team should provide APIs so that development teams can self-service deploy new functionality. “Feature teams” working on user-facing functionality should build upon the APIs provided by “device teams”, which in their turn ensure a proper functioning of cross-platform functionality on a specific device.
You can and should combine both approaches. Whenever possible the first approach should be the first priority.
There is much more to say about growing engineering teams (e.g. hiring, managers vs. leaders, etc.), but for me these four simple lessons are key to the success of any team growth approach.