Swizec Teller - a geek with a hatswizec.com

Senior Mindset Book

Get promoted, earn a bigger salary, work for top companies

Senior Engineer Mindset cover
Learn more

    What I learned from Team Topologies

    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 🤔

    Team Topologies cover
    Team Topologies cover

    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.

    Conway's law

    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.

    Scaling teams is a technical problem

    There are two types of "scale" in software:

    1. Performance scale
    2. 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.

    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.

    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.

    Reverse Conway manuever

    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. ✌️

    Two types of teams

    Like many others, Team Topologies recommends 2 types of teams using its own words:

    1. Vertical teams – can deliver user value end-to-end
    2. 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.

    You see this concept in The Phoenix Project, The Unicorn Project, the Empowered teams book, and a bunch that I'm forgetting. Everyone eventually learns this lesson – being blocked by others sucks.

    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.

    Cheers,
    ~Swizec

    PS: as an experiment, I had ChatGPT write a version of this newsletter. It was pretty okay

    Published on July 21st, 2023 in Architecture, Leadership, Teams, Books, Management

    Did you enjoy this article?

    👎👍

    Continue reading about What I learned from Team Topologies

    Semantically similar articles hand-picked by GPT-4

    Senior Engineer Mindset cover

    Senior Mindset Book

    Get promoted, earn a bigger salary, work for top companies

    Learn 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

    Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections

    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

    Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com

    By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️

    Created by Swizec with ❤️