How should we organize our engineering teams
Classify every team, name the interaction mode between each pair, and flag the ones carrying too many domains.
Physical products get designed once, then manufactured and distributed along a value stream. Digital product development does not work that way, and it needs a different way of thinking about how value flows through a team.
Team Topologies, the model Matthew Skelton and Manuel Pais laid out in their book, is the clearest answer for digital product organizations. Four team types, three interaction modes, and the core insight underneath both: cognitive load is the real constraint. Limit the number of technologies or domains any one team is responsible for, and let structures evolve rather than freezing them at whatever shape made sense on day one.
Leaders are usually the last to know which model is failing. It is the people on the front line who notice that this does not make sense, or that they are pulled in too many directions. This sheet is a way to see it on one page.
What you get
- The four team types and the three interaction modes, defined briefly
- A mapping table for every team you have, with a column for the domains each one carries
- An overloaded flag, which is the column that matters
- Three fixes for a team you ticked, including what to do when Collaboration quietly became permanent
Where should we send it?
One email with the worksheet. You can unsubscribe from anything else in one click.
On its way
Check your inbox. If it has not landed in a minute or two, look in promotions or spam, and add sam@startuppatterns.com to your contacts so the rest arrive.
Adapted from the Organization chapter of The Mindful Product Company by Sam McAfee.