I have happily lurked here for years, but upon seeing Team Topologies mentioned I felt an overwhelming urge to create an account, if only to give a strong negat

I have happily lurked here for years, but upon seeing Team Topologies mentioned I felt an overwhelming urge to create an account, if only to give a strong negative review. I was a part of an organization that implemented this book's recommendations, and it did not go well. We had high performing teams that worked well together and all shared roughly equal responsibility for tech, features, oncall, and tech debt. The organization wasn't perfect -- we had scaled down the org for covid, only to be surprisingly successful (a great problem to have) which was brutal on us engineers and we incurred a ton of tech debt. And we had the standard issues with some collaboration and some politics. Then someone was brought in who applied the concepts in this book, and it went very poorly. Suddenly we were shuffled into teams that weren't much larger but had huge areas of responsibility. In addition to the tech debt we already had, the breadth of our responsibility was expanded drastically. For example, instead of having one team responsible for kakfa, now 3 teams all owned slices of it, but in a way that we each had to become experts in order to satisfy our oncall obligations (I'm oversimplifying, but hopefully you get the point). Multiply that by 3-5 serious backend systems for each team, and you can hopefully appreciate the high cognitive load we were under. To make matters worse, most of the teams doing the heavy lifting were now "product teams" which had UI ("fullstack") people thrown onto them, but those teams now owned 92% distributed backend tech, and 8% user interface. Almost all of the fullstack people had a great attitude about it and learned as fast as they could but it did not go well. I was effectively oncall 24/7 from that point. Also the oncall burden and areas of responsibility were unbalanced between teams. Two teams bascially ended up with the most fragile, unstable systems with the highest oncall burden while others had almost exclusively brand new things that did not yet have serious flaws. And then, to twist the knife, while we are drowning in our own tech debt and heterogenous team structure, there began a pattern of reducing our autonomy. Important decisions, or strategies, like how we test our software, or how we deploy, we suddenly being dictated by other teams full of recently hired junior engineers who knew less about these things than the staff engineers did, especially since they lacked the tribal knowledge we had built up (and still had not managed to offload onto our own teams!). I gave some careful feedback about the most obvious problems to the director who seemed responsible for implementing all this, and she brushed off my concerns. That was weird, but made sense when I later learned she was implementing the concepts in Team Topologies. The teams had ridiculously large areas of responsibility because we were the feature teams ("stream-aligned" in Team Topologies b.s.) and we were supposed to crank out features without talking to other teams. That is also why some teams had practically no on call burden and others' on call rotations were full of sev 1s: when your ownership is based on features, some teams will own the one of the newer features that doesn't have tech debt, race conditions, or scaling issues yet, and other teams will end up with the older features, which we could barely keep online. And the teams full of idiots bossing us around? Well those were the "enabling teams." This was especially bad on the infrastructure side, because these engineers would only talk about the way a perfect system should work, and refused to acknowledge any reality of the existing system. For example, we had a rather homegrown EC2-based autoscaling infrastructure with what I would call a "bespoke" service discovery implementation. The k8s-enabler assigned to one project insisted that k8s+consul was the answer, and the only answer. When I asked how that would work with the existing system in prod, he explained why k8s is better than EC2 and I'd better get with the program. When I brought up the source code of what we had deployed in prod and pointed at the exact line I expected to fail, he insisted it was working. He lied. We lost three weeks. When I eventually heard about the book and read it, it make me angry to see what people in management (or that style of management) actually thought about us (there's some stuff about using teams as units to make us all fungible cogs but I'll skip that because this comment is already very long). Especially because most of the companies cited in the book were awful, boring places to work at. I sorry I can't remember any examples (other than maybe an online casino); all I remember is the case studies were all done for companies that I would never want to work at, and most of them were outside the tech sector entirely. Another thing they did was disband the regular meetings of all of the senior engineers, and even told us to stop collaborating with each other a few times. I'm not 100% sure I can pin this one on Team Topologies, although it the book does promote the idea of trying to control communication between teams. I watched the org decline for about 1.75 years before I left. That stupid ass book was not the only problem we had, and not even the biggest. But it certainly made things chaotic and unpleasant for a while. I realize that there is an obvious counter point to everything I've written -- maybe my org was just "doing it wrong." Maybe this post will get a bunch of replies saying a long the lines of "well actually, chapter X doesn't say you supposed to do Y". And I would just like to point out that if it is so easy to misinterpret this book, if our Director and VP's best efforts simply fell short of understanding the text, and the claimed success is only possible with your enlightened interpretation, well that's a problem too. If you are a staff engineer, I actually recommend reading it (hopefully in some manner that does not involve a purchase, like borrowing from someone). It can give you a useful perspective and insight into what some managers are thinking. If you are some kind of manager or director or VP, I don't know what to tell you. Managing an org is hard. I certainly don't know how to do it. But if you are learning how to do it from this book, I hope I never have to work for you.