You can't escape Conway's Law. Might as well use it for good.
That's the core lesson from Team Topologies, a book on engineering org design. Or maybe software design. It's hard to tell 🤔
The authors' message is that that's the same thing. You design an engineering team to design your software. That's what good architects do.
Team Topologies is an easy read. Strong recommend. I blazed through the audiobook on a single Sunday run a while back. Here's the good shit that stayed.
In case you haven't heard, Conway's law says that the structure of your software will naturally follow the structure of your org.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
— Melvin E. Conway
You can fight against this, or you can embrace it.
There are two types of "scale" in software:
- Performance scale
- Team scale
Scaling for performance means building software that can handle more load. More requests, heavier requests, faster responses, etc. This is the scale we bicker about online.
Developers: Performanc! Kilobytes! Make it fast!!!— Swizec Teller (@Swizec) July 20, 2023
Real people: Shares video of a guy reading a screenshot of an article
Scaling for teams means building software that more people can work on. How do we work without stepping on each other's toes, avoid too many cooks in the kitchen, ensure consistency, avoid bugs when the left hand doesn't know what the right is doing, etc.
The biggest mental shift for a programmer is going from projects that fit in 1 person’s head to projects that nobody understands fully. Your whole approach changes.— Swizec Teller (@Swizec) April 19, 2023
Microservices are the canonical example of scaling for teams not performance. I first wrote about this back in 2019 in What Microservices are for. On paper, microservices make your software slower – you're replacing fast function calls with slow network calls – but they help large teams to work together.
And I had this thought again in 2022 with Scaling Teams is a Technical Challenge.
Now, because your software is eventually going to reflect your team structure, that means team design is a technical problem. You are designing your software by designing your teams.
Team Topologies takes this "team design is a technical problem" approach even further and suggests using it aggressively.
See a big ball of mud that needs cleaning? Assign ownership of different parts of the ball to different teams, wait for engineers to duke it out, voila you have 2 modules.
The process is messy and annoying and your engineers might hate you. But if you say "No this is the way, just try it. I trust you to figure it out" then give the teams enough time and space and management cover, they will split the domains.
Because they'll be too annoyed bumping into each other. Boundaries will show up. It's great.
If you find yourself in a confusing situation with another team where you suddenly have weirdly shared ownership of a domain you barely understand, this is likely what's happening. ✌️
Like many others, Team Topologies recommends 2 types of teams using its own words:
- Vertical teams – can deliver user value end-to-end
- Horizontal teams – build platforms for vertical teams to use
Team Topologies calls the first a "flow aligned team" and I forget what they call the 2nd. It doesn't matter, the point is in the concept.
For a team to be truly independent, it needs to own the full stack of its domain. Build features from idea to deploy without having to wait on others.
And my own pet theory is this: Much of engineering meta-work, the kind that doesn't directly drive user value, comes from poor org design.
PS: as an experiment, I had ChatGPT write a version of this newsletter. It was pretty okay
Continue reading about What I learned from Team Topologies
Semantically similar articles hand-picked by GPT-4
- What I learned from Software Engineering at Google
- Scaling teams is a technical challenge
- Can I get your opinion
- What microservices are for
- The 3 types of scalability
Get promoted, earn a bigger salary, work for top companies
Getting that senior title is easy. Just stick around. Being a true senior takes a new way of thinking. Do you have it?
Get a free chapter from the Senior Engineer Mindset book and a sample audiobook chapter, followed by a Senior Mindset 101 email course.
You'll get insights to apply at your work right away.
Senior Mindset Book
Get promoted, earn a bigger salary, work for top companiesLearn more
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️