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