Your Organization Has a Complexity Budget

Every organization has a budget for money. Most have a budget for headcount. Very few admit they have a budget for complexity, but they all do, and most are overspent.

Here’s what I mean. Your organization can only understand, operate, secure, and change so many things at once. Every system, integration, vendor, programming language, deployment pipeline, and “special case” uses up part of that capacity. Spend more than you have, and the effects show up somewhere else: slower delivery, more incidents, longer onboarding, and the same few people who are always on every escalation.

The authors of Team Topologies describe this at the team level as cognitive load. A team can only hold so much in its head, and when you give it more, quality drops. I’d argue the same thing applies to the whole enterprise.

How the budget gets spent

Complexity spending rarely looks like a big decision. It looks like this:

A one-off exception. “We’ll run this one on a different database. It’s just one app.” Now you have two database platforms to patch, back up, monitor, and staff.
An acquisition that never gets integrated. You bought the company and also bought its stack, its identity provider, and its way of doing things. Five years later, you still have all of it.
A pilot that never ends. A proof of concept became production when nobody was looking. It has no owner, no monitoring, and three integrations.
A vendor product that “does everything.” It replaced two tools and added forty configuration screens nobody fully understands.
A reorganization. New team boundaries that don’t match the system boundaries mean every change now needs three teams to coordinate. (Conway’s Law always wins.)

None of these is wrong on its own. That’s the trap. Each spend is reasonable, and the total is what hurts.

Make the budget visible

You can’t manage a budget you can’t see. Some practical ways to make complexity visible:

Count your nouns. How many applications, databases, languages, cloud services, integration patterns, and vendors does your enterprise run? Write it down. Track it every quarter. The trend matters more than the number.
Map ownership. For every system, who owns it? If the answer is “nobody” or “a team that was reorganized away,” that system is spending budget without anyone accounting for it.
Measure time-to-understand. How long does it take a capable new engineer to make a meaningful change? That’s one of the most honest complexity metrics there is.
Watch your heroes. If the same three people show up on every incident bridge, they’re holding complexity in their heads that the organization hasn’t absorbed. That’s a liability, not a strength.

Spend on purpose

The goal isn’t zero complexity. Some complexity is the point. It’s where your competitive advantage lives. Dan McKinley’s idea of innovation tokens is really a complexity budget with a nicer name. You get a few. Spend them on what makes your business different, and choose boring, proven, shared solutions for everything else.

A few rules of thumb I’ve found useful:

New things should replace old things. When you bring in a new platform, make retiring the old one part of the project. If it isn’t in scope and funded, it won’t happen.
Standardize the boring parts. Logging, identity, deployment, monitoring, and data integration should have one obvious, paved way. Spend your creativity elsewhere.
Make exceptions expensive. Not impossible, just visible. An exception should come with an owner, a reason, and a review date.
Budget for paying it down. Set aside real capacity every quarter for removing things. It won’t happen in leftover time, because there is no leftover time.

The architect’s job

If you’re an enterprise architect, this is your job, whether or not it’s in your job description. You’re the one person whose scope covers the whole enterprise. You can see that the budget is overspent when each individual team can only see its own line item.

Making that budget visible, and helping leadership spend it on purpose, may be the most valuable thing an architecture practice can do. It’s certainly more valuable than another reference architecture nobody reads.