“What if centralized dominance is just what success looks like in our current system?”
You can subscribe and listen to the podcast on Apple Podcasts or wherever you listen to podcasts.
Be sure to leave me a Rating and Review!
That’s not a defense of centralization; it is a challenge to how we think about centralization vs decentralization, and how we define progress in enterprise systems and platform design. In tech, success is often framed in terms of scale, speed, and adoption. The bigger you grow, the more central you become. And we rarely stop to ask: Is that centralization a feature… or a failure of imagination?
This is the third post in a series about decentralization in enterprise systems, not as an ideal, but as a spectrum of tradeoffs we all navigate:
- In Engineering Meets Economics, I argued that flexibility is more valuable than ideological purity. We need systems that can move between centralized and decentralized states.
- In How Decentralized Are You Willing to Pay For?, I explored what that flexibility actually costs in time, money, tooling, and culture.
Today, I want to take a step back and ask: Why is it so hard to justify decentralization in the first place? What are we really rewarding when we call a system “successful”?
Success Metrics That Skew Centralized
Let’s be honest: most of our current incentives favor centralization. Consider how we measure success in enterprise or platform strategy:
- Market share → the more users you serve, the more value you’re assumed to create
- Efficiency → fewer systems, fewer teams, tighter control
- Reliability → built-in resilience that looks like robustness, even when it’s just concentration
- Governance → top-down visibility, fast decision-making, single owners
These are all perfectly reasonable goals. But these goals bias us toward consolidation. And once centralized systems become dominant, they become self-reinforcing; technically, economically, and even culturally.
That said, even centralized dominance is rarely permanent. In his book Clockspeed (have you read that book? No? You should.), Charles Fine argues that competitive advantage, whether it comes from control of the supply chain, platform dominance, or speed to market, is always temporary. The faster your environment moves, the more critical it becomes to reconfigure quickly. That makes modular systems, distributed governance, and optionality not just design preferences, but survival traits.
In that light, centralization might get you to success, but it won’t keep you there.
What’s the Alternative? Success as a Balancing Act
So let’s ask a different question:
- What if success isn’t just about growth, but instead about sustaining healthy tension between centralized power and distributed control?
That’s what good governance often looks like. It’s not pure autonomy or rigid hierarchy. It’s a structure that lets people collaborate without collapsing into uniformity.
This isn’t a utopian call for federating all the things. It’s a call to recognize when centralization is helping and when it’s masking fragility, dependency, or misalignment.
We decentralize within organizations all the time:
- We spin up new product teams
- We delegate budget and decision-making to local units
- We distribute accountability through OKRs and KPIs
But we do it with clear guardrails, shared incentives, and coordination models. In those cases, decentralization is seen as a sign of maturity, not a threat.
So why do we treat infrastructure decentralization like chaos? (Probably because we don’t do it well, but we can fix that.)
What This Means for Architecture (and the Org Chart)
If we accept that centralization is often the default path, not necessarily the best one, then we need to build systems that allow for intentional divergence.
That means:
- Designing systems that don’t break when more than one authority exists
- Structuring metrics to reward adaptability, not just consolidation
- Treating decentralization not as risk, but as a capacity for complexity
And yes, it also means knowing when centralization is a good choice because it simplifies the right things, not everything.
Rethinking the Goal
You don’t need to decentralize your stack into a thousand services. (Good gravy, can you even imagine the insanity?) But you do need to ask:
Are we building systems that grow toward concentration by default because that’s easier to explain, easier to pitch, or easier to measure? Or are we designing for the kinds of success that hold space for flexibility, autonomy, and resilience?
If centralization is the only outcome we allow ourselves to count, we’re optimizing for a world where fragility just looks like efficiency … until it doesn’t.
There’s one more post in this series coming up next week: Governance Is the Next Bottleneck. I hope you’ve subscribed to get your notification when it comes out!
📩 Want to stay updated? I write about digital identity and related standards—because someone has to keep track of all this! Subscribe to get a notification when new blog posts go live. No spam, just announcements of new posts. [Subscribe here]
Transcript
[00:00:00]
Welcome to the Digital Identity Digest, the audio companion to the blog at Spherical Cow Consulting. I’m Heather Flanagan, and every week I break down interesting topics in the field of digital identity—from credentials and standards to browser weirdness and policy twists. If you work with digital identity but don’t have time to follow every specification or hype cycle, you’re in the right place.
[00:00:26]
Let’s get into it.
[00:00:29]
Hey everybody, welcome back. This is the third episode in our series on centralization and decentralization, and the balance between the two.
If you’re just tuning in now, here’s what you’ve missed:
- In episode one, we explored why resilience isn’t about being centralized or decentralized. It’s about being able to move between the two models when circumstances change.
- In episode two, we looked at the real cost of building that kind of flexibility. Because optionality isn’t free. It takes planning, coordination, and a willingness to invest before you need it.
Why Is Decentralization a Hard Sell?
[00:01:01]
And that brings us to today’s topic. Why is decentralization often still such a hard sell, especially inside enterprises?
[00:01:09]
One answer is because most of our success metrics reward centralization.
[00:01:15]
If we don’t challenge how we’re defining success, we’re going to keep optimizing for systems that look great—right up until the point that they don’t.
Centralization and Scale
[00:01:22]
Let’s talk about that in tech. We don’t just love things at scale; we know how to do things at scale fairly well.
[00:01:31]
When we’re working with centralized systems, we know the playbook:
- Throw more hardware at it
- Replicate the databases
- Spin things up in other regions
- Set up failovers, caching, and routing magic to absorb traffic
And that totally works—up to a point. Even when control is centralized, we’re very good at scaling the infrastructure around it.
[00:01:50]
When it comes to decentralized models, we know how to do that too. We just don’t plan that way as often.
[00:01:56]
At least not anymore. Think about the protocols from the early days of the Internet: DNS, BGP, SMTP. They’re not flawless or simple, but they work at global scale because they were built to distribute control and survive failure.
[00:02:14]
Everyone gets a piece of the responsibilities in those protocols. Everyone can operate within a shared structure. That’s decentralized centralization, and we did it really well.
The Problem with Success Metrics
[00:02:25]
But now, today’s challenge: most of the success metrics we use today, especially in enterprise systems, still push us towards centralization.
[00:02:33]
Why? Because it looks faster, is easier to explain, and is a lot easier to report on.
[00:02:40]
But when success is only measured by how tightly we can control the system, we end up building architectures that aren’t particularly flexible. And that’s a problem.
Centralization Helped Us Grow—But Does It Still?
[00:02:49]
Now let’s step back for a moment. You might be thinking, “Well, yes, but centralization is what helped us grow as a company, helped us grow at speed.” And yes, you are absolutely right. Centralization often is what helps organizations move fast, simplify complexity, and work at scale. It gives you:
- Clean handoffs
- Predictable systems
- Fewer moving parts
- Optimized performance without needing to get everyone to agree on everything
And when you’re trying to move quickly, those things are real advantages.
[00:03:19]
But the thing is, those advantages—whether from your infrastructure perspective or your market perspective—don’t last forever.
[00:03:30]
Markets might shift, regulations might change, vendor lock-in might become a liability, and the systems that helped you grow start to hold you back.
[00:03:40]
There’s a great idea from supply chain strategy that applies here: the faster your environment moves, the more important it becomes to reconfigure quickly.
[00:03:48]
And that’s where centralized success starts to crack—not because it failed technically, but because it couldn’t adapt fast enough.
[00:03:56]
So the question isn’t, “Didn’t centralization help us grow?” It’s, “Can we keep growing without the ability to be a little bit more flexible?”
Decentralization in Organizations
[00:04:07]
It’s kind of funny—we decentralize all the time, but just not when it comes to our infrastructure and definitely not our identity infrastructures.
Inside organizations, we break up control and distribute responsibility on purpose:
- Teams have their own budgets
- Product groups make roadmap decisions
- Key performance indicators are set at the department level, not just at the company level
[00:04:31]
Why? Because trying to control everything from the top down slows you down. It’s more sustainable to align goals than to micromanage every function.
Take a typical enterprise product org as an example. One team focuses on mobile, another on partner integrations, a third on internal tooling. Each team moves independently within shared priorities. They don’t all escalate to the CIO to push code; they’re trusted to make decisions locally based on their goals and context. We don’t call that chaos—we call that autonomy and maturity.
[00:05:05]
Think of it like a city: every neighborhood has its own character, maybe its own rules, but they follow the same traffic lights, zoning laws, public services. That’s decentralization with coordination.
[00:05:17]
The control, to an extent, is distributed. If we can do this with people and even in governments—if we can handle distributed authority in complex orgs—why does decentralizing infrastructure sometimes feel so risky? It’s not because we can’t do it. It’s because we haven’t applied the same thinking to systems that we apply to teams of people.
Building Flexibility into Identity
[00:05:42]
If centralization has been our default version of success, what does success look like when you build in the flexibility to decentralize?
[00:05:50]
It doesn’t mean blowing up your current architecture, because that would probably be bad and you wouldn’t get very far.
[00:05:56]
It doesn’t mean ditching your identity provider or rebuilding everything from scratch, because that also wouldn’t make you very popular and probably wouldn’t get you very far. But it does mean designing for modularity and movement.
[00:06:07]
A successful, flexible identity system might include:
- Federated logins that work across partners but don’t collapse if one party changes their trust model
- Credential issuance that’s anchored to your core directory but usable outside your domain
- Policy enforcement that supports delegation, so different teams or regions can adapt without rewriting global configurations
- Flexible authentication layers that can shift to support new protocols without breaking legacy systems
[00:06:42]
Another good example of flexible identity systems that don’t require a centralized focus.
[00:06:49]
Ask yourself in your organization:
- Can you change identity providers without breaking logins for 50,000 users?
- Can you delegate trust without rerouting everything through one central system?
[00:07:03]
Are you prepared to adapt when legal or business requirements shift, or will you end up frozen and need to make a plan on the fly?
[00:07:14]
Being able to say “yes” to those things—that’s what success with flexibility looks like.
Key Takeaways
[00:07:25]
You don’t have to decentralize everything—and probably shouldn’t. But if your architecture can accommodate controlled divergence and flexibility, you’re set up for long-term success.
[00:07:43]
That’s what matters. That’s what’s really cool.
[00:07:46]
Here’s the takeaway from today.
[00:07:50]
Centralization isn’t the enemy. But if success only counts as scale, simplicity, or speed, that story can get brittle quickly.
[00:08:03]
We already know how to decentralize in our org charts and delegate decisions without chaos. We just haven’t always brought that thinking into our infrastructure and identity systems—but we could.
[00:08:15]
Success doesn’t have to mean one system to rule them all. It can mean systems that adapt without starting over. That adaptability only works when you’ve got governance built in to support it.
[00:08:30]
Our technology is almost good enough—sometimes more than good enough. But shared control takes more than configuration files. It takes structure, accountability, and intention.
Closing Thoughts
[00:08:53]
And remember, resilient systems don’t just run well—they recover well and grow on purpose.
[00:09:04]
That’s it for this week’s episode of the Digital Identity Digest. If this helped make things clearer or more interesting, share it with a friend or colleague and connect with me on LinkedIn @hlflanagan. If you enjoyed the show, subscribe and leave a rating or review on Apple Podcasts or wherever you listen. You can also find the full post at sphericalcowconsulting.com.
Stay curious, stay engaged, and let’s keep these conversations going.