How to Structure Engineering Teams 🏯
A thorough guide about principles, roles, growth stages, and plenty of resources.
Since the very beginning of Refactoring, I have written a lot about organizing and scaling engineering teams.
That’s because this is a core part of my work experience — as CTO of an early stage startup first, and manager of a high-growth, larger company later.
There is even a full section in the Library about it 👇
Articles I have written usually cover specific aspects — from the need for managers, to how communication changes with growth.
So, today I am publishing a comprehensive Guide 📖 that puts together everything I said about this topic in a coherent framework that you can use at work. It will be a way longer, more in-depth and more researched article than usual!
I write one of such guides about once a month. You can learn more about Refactoring Guides below 👇
So, here is what we’ll cover today:
🔭 Principles — what makes a team good? Mental models for creating effective engineering teams.
⏳ Teams longevity — how long should a team last? What are teams *really* about?
🎽 Roles — what are the core roles and responsibilities you should assign?
🪴 Growth Stages — how does structure change through the various growth stages of a company?
🤔 Unconventional Teams — stories and tactics of companies that do things differently.
💬 Community Stories — two real-world team structures from the Refactoring community.
📌 Takeaways — summarizing this long guide into four main actionable points.
Let’s dive in!
🔭 Principles
Within each company, there are groups of people who are more likely to work together than others. Creating teams simply means defining processes that make it easier for such people to interact on a regular basis.
Team structure shapes how communication happens, which, in turn, shapes how software gets made. As by Conway’s law 👇
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. — Melvin Conway, circa 1967
The main takeaway of Conway’s law is that if you create a good team organization, software will largely take care of itself.
But what makes a team organization good?
I have a personal heuristic that looks at three things: Autonomy, Cognitive Load, and Responsibilities.
1) Autonomy 🏃♂️
You want teams to be autonomous.
What makes a small startup go fast is how cohesive and nimble the team is — people can work quick and without overhead. In a larger org, you most likely want to replicate this by creating many of such teams.
2) Cognitive Load 🧠
A good team should own an amount of software that can fit in their head.
Engineers and teams are able to bring the most value when they sustain the right amount of cognitive load for their work: not too much, not too little.
Optimizing cognitive load is one of the main takeaways from Team Topologies — which we reviewed earlier this year:
Also, not all cognitive load is created equal: you should spend most of your cognitive budget on domain and business knowledge, which creates actual value, and minimize what comes from extraneous stuff like bad DX and convoluted tech.
3) Responsibilities 👑
On good teams, all the bases are covered. You know exactly who is responsible for what, and people have the right skills for the job.
In a modern software team there are three main responsibilities:
🎨 Product — owning the roadmap, feature requirements, and communication with customers & stakeholders. Creating alignment and removing obstacles from the way of the team.
🔨 Tech — owning the technical direction of the product. Making design decisions and guiding the development.
🌱 People — taking care of people’s growth and wellbeing. Working on processes, hiring, and career tracks.
Should these responsibilities belong to separate people or can they partially conflate on the same ones?
It’s… complicated.
Let’s talk about roles 👇