We love to blame “legacy code” for everything. Slow delivery? Legacy. Fragile releases? Legacy. That haunted service nobody wants to touch? Legacy again. It is a comforting story because the villain sits in a repository rather than in the mirror.
In the Simplicity First essay, “Stop Blaming Legacy Code: Your Org Chart Is the Real Technical Debt,” I argue that the real mess often lives in reporting lines, team boundaries, and incentive structures. The code is just following orders. If every feature crosses four teams, two committees, and a shared “platform” group, no rewrite will save you. You will rebuild the same distributed knot, only this time with a new framework and fresh stickers on the laptops.
Drawing on ideas from the book Team Topologies, the essay examines how stream-aligned, platform, and enabling teams actually behave when they encounter real organizational politics. It explores why “platform” groups so often become ticket queues, how shared modules turn into junk drawers, and why your incident response diagram usually aligns more with your org chart than with your architecture slide. Then it makes a simple claim: if you want simpler systems, start by refactoring who owns what, not just how the code is shaped.
If you look at your current stack and see the same problems reappearing in every “modernization” project, this piece is meant to sting a bit and then give you practical moves you can run on Monday.
Read the full essay here:
