There's a lot that I like about this book. Splitting up the mandate between platform and products teams, and eliminating friction, letting each team be good at their thing is I think an efficiency many companies indeed could benefit from.
But I've also seen this book promoted heavily within an org, and the one core strength kept feeling like a core weakness that mades me incredibly sad, about how isolated it made work.
It doesn't insist it has to be so, but the org I saw that was so excited for TEam Topologies loved how it continually stressed independence of teams. And as a direct result, I've seen cooperation, coordination, & cross-team planning plummet. In ways that keep having suboptimal plans get put into action with bad outcomes. Stream aligned teams would turn into complicated subsystem teams, after they created something complicated and gnarly while being stream/product aligned, and unchecked.
I think the topologies here are quite useful framings, and as Fowler says the idea of trying to reduce cognitive complexity is an interesting one we haven't heard well represented before. And is probably due given how impractical making each team truly full stack devops has become, as the CI/CD/observability stack complexity has expanded. But I caution so much against the messages this book gives management, which is that stream/product aligned teams just need to be racehorses with blinders on & interference is bad. The book glories the stream aligned team, the value creator, and makes everyone else auxiliary, which is sort of true & great. But the book's glorification of execution speed doesn't leave much space for how and where cross-team wisdom happens, what kind of processes you have there. Broader cross-team architecture reviews, brainstorming, systems planning, systems coordination aren't well captured here: most teams need a strong collaboration mode to build good software that fits the architecture well. But the book only really regards a single collaboration need: those of platform teams to get feedback to ease their Developer's Experience.
The missing element was ubuntu. If you want to go fast, go alone. If you want to go far, go together. - African Proverb
How big was your company? I think beyond a certain size, independence of the team is the prize. You are not alone, for you have your mates. Beyond your team, trying to collaborate is like herding cats. Every team has its own priorities, everything moves more slowly, and the more stakeholders there are, the greater the risk of the project falling through. Bezos' stipulation that teams communicate through interfaces was a stroke of genius. This created a standard which allowed teams to self serve.
I agree that teams must collaborate to go farther. One team can only do so much. Management should make sure all the teams stay aligned and hold them all accountable, but the teams themselves should still strive to be independent.
It sounds like what your organization needed was a project manager to co-ordinate or a forum for the teams to share information.
Every large company I've worked at on implementing the ideas from this book that was successful put a lot of effort into supporting the chapters/guilds/communities of practice or whatever you want to call them that encouraged this cross-team collaboration. Sure every team had their DevSecOps person, but that person was also a member of the chapter that met regularly and maintained an active channel on Slack or similar to help each other out. Along with a standard framework for picking new things to minimise the sprawl of tooling where possible.
I’ve experienced something akin to the isolation you experienced in a relatively mid sized (about 300 devs) org. While team isolation made it possible to move fast, there was a lot of chaos and duplicated effort all over the place, lessons learned was promptly forgotten etc.
I think what made it kinda work is when they introduced “infra” dev teams that tried to see what the global problems were and solve them on a library/infra level.
Networking was one terraform module away, kafka integration was solved with in house abstractions, design systems, knowledge bases, etc. While not perfect there was a sense that “if its too gnarly a solution, ask around, somebody probably already solved it more elegantly”.
They would talk to all the teams and if someone developed an elegant package/lib/idea they would promote it to other teams.
Key was to have people working explicitly on tech sharing and global problem solving. Ended up quite a nice team environment by the time I was leaving the company, though it took years to get to that point.
But I've also seen this book promoted heavily within an org, and the one core strength kept feeling like a core weakness that mades me incredibly sad, about how isolated it made work.
It doesn't insist it has to be so, but the org I saw that was so excited for TEam Topologies loved how it continually stressed independence of teams. And as a direct result, I've seen cooperation, coordination, & cross-team planning plummet. In ways that keep having suboptimal plans get put into action with bad outcomes. Stream aligned teams would turn into complicated subsystem teams, after they created something complicated and gnarly while being stream/product aligned, and unchecked.
I think the topologies here are quite useful framings, and as Fowler says the idea of trying to reduce cognitive complexity is an interesting one we haven't heard well represented before. And is probably due given how impractical making each team truly full stack devops has become, as the CI/CD/observability stack complexity has expanded. But I caution so much against the messages this book gives management, which is that stream/product aligned teams just need to be racehorses with blinders on & interference is bad. The book glories the stream aligned team, the value creator, and makes everyone else auxiliary, which is sort of true & great. But the book's glorification of execution speed doesn't leave much space for how and where cross-team wisdom happens, what kind of processes you have there. Broader cross-team architecture reviews, brainstorming, systems planning, systems coordination aren't well captured here: most teams need a strong collaboration mode to build good software that fits the architecture well. But the book only really regards a single collaboration need: those of platform teams to get feedback to ease their Developer's Experience.
The missing element was ubuntu. If you want to go fast, go alone. If you want to go far, go together. - African Proverb