Avoid Shipping Your Org Chart

I’ve worked at a few different companies, and at every one of them I’ve watched the same pattern play out. Somebody decides we should pull a chunk of functionality out into its own service. Two years later, somebody else decides we should consolidate it back. In between, a small group of people did the same job they were already doing, except now over HTTPS, with worse latency, query semantics they don’t control, and a dependency graph nobody can hold in their head. The system isn’t better. The org chart is.

That’s the failure mode I want to name. People keep shipping the org chart as a service architecture and pretending they’ve solved a system problem.

Here’s how it actually unfolds. A team owns a chunk of functionality. They look at the codebase and decide it would be cleaner if their stuff lived behind its own boundary. They build a service with a tidy scope, a clean SLA, a good README. They ship it, get applause, and move on. The complexity that used to live in one repo (joins across tables, in-process filtering, transactional consistency) doesn’t vanish. It migrates. Now it lives in every upstream caller. Somebody whose feature used to be a WHERE clause is writing a paginated HTTP loop and filtering rows in memory because the new API doesn’t support filter composition, retrying on a 503 they didn’t expect. They ask the owning team for a richer query. They’re told it’s not on the roadmap.

A few quarters later, the extracted team is doing serene work behind their boundary. They refactor. They write design docs. Their tests pass. Meanwhile the apps that generate the revenue (the ones now carrying all the displaced complexity in their callsites) are getting harder to change. The pain got redistributed, and it got redistributed unevenly. The people who moved fastest got cleanliness. The people who own outcomes got a tax.

Service extractions feel like progress while you’re doing them. You can name the boundary, count the lines moved, the wiki page reads well. What you can’t easily count is the cost you pay forever after: the deploy, the on-call rotation, the SDK, the schema versioning, the latency floor, the eternal question of who owns the thing nobody quite remembers extracting. Services aren’t free. The bill is paid by people who didn’t benefit from the extraction.

I’ve boiled it down to one test. A service should exist only when it’s genuinely the wrong thing to keep in the monolith. Not when it would feel better to work on. Not when one team wants to stop coordinating with another. The worst version is when somebody pitches a service to escape gnarly SQL. That one sounds virtuous, and people fall for it constantly. You can’t trade expressive, optimizable, indexable SQL for HTTP parameters and call it an improvement. JOINs don’t get better when they become network hops. If the database is the bottleneck, fix the database. Add the index. Denormalize where the access pattern demands it. Move heavy aggregations into materialized views. Don’t throw away the query planner because somebody got tired of writing CTEs.

The less popular reason people ship the org chart is that the codebase is painful to work in, and a new service feels like a fresh start. It isn’t. The new service will inherit, within six months, the same conditions that made the old codebase painful, because those conditions are organizational and not technical. The fix to a painful codebase is to fix the codebase. The fix to a fragmented system is rarely to fragment it more.

If you’re sitting in a meeting where the company is gearing up for its third “this time we’re going to do it right” microservices push, stay in the monolith until the monolith stops working in a way you can describe in a single sentence. Performance isolation the runtime can’t provide. A scaling axis that genuinely diverges. A datasource that simply has to be owned somewhere else. When the answer is “so my team has its own thing to ship,” you’re not solving a system problem. You’re solving an org problem with a system tool, and the system will spend the next five years pushing back.

The cleanest engineering organizations I’ve worked in weren’t the ones with the prettiest service catalog. They were the ones whose engineers had the conviction, every time it came up, that adding another box to the architecture diagram was a cost. The burden of proof was always on extraction, never on consolidation.

Don’t ship the org chart. If you ever need to extract a service, it should be because the system actually demanded it, in a sentence you can write down. Anything else is a reorg in disguise.