Hacker News new | ask | show | jobs
by jauntywundrkind 905 days ago
I feel like we are going to spend many years coping with Team Topologies, a book which idolizes a seeming infinite and vast independence of teams from each other in the name of 'spending things up' or some such.

I love, respect, & cherish the ideas here. But the sound-bite ideas of the book vastly overweigh the practical complexities of development.

Yeah, giving each team authority to do their thing is desperately necessary today; there's too much organizational confusion & unclear decision making processes. Teams need autonomy. Yes. But the book really seems to have so little to say about how to play together. It doesn't talk hardly at all about how to find concordance & to make decisions across teams. What are good common techs to adopt? Microservices as I'm everyone can pick whatever (Haskell for this, pho for that, & 12 varieties of node) is one organizational end, monolith is another end. The confusion and angst Team Topologies let's dwell and build is infinite, because it's pretense is that there are many parallel streams of development and that inter-team work is a negative.

The books is so good and so important. Because so many orgs are fucked and doing things terribly. Cognitive load is massively over managed and it's impossible to do anything to escape the tar pit the shitty ancient overly established pretentious shitbag elders have dictated. But the result of what Team Topologies says is such an opposite and shitty fucked, where cognitive loads expand exponentially because every team is independent & fucking off into their own space, with only vague constraining behavior or nebulous "platform" teams that "support" or maybe dictate to these platforms teams.

Never have I seen a book I both respect so highly & think so terrible & awful.