Building a New Central Organization: Earn the Mandate Before You Scale It
But there's one pattern I've seen often enough that I think it's worth writing about.
A company decides it needs a central team. SRE, platform engineering, observability, developer tooling. The name varies. So do the reasons, but two come up again and again.
One common reason is efficiency.
Teams operating in silos.
Each one building its own tooling.
Each one solving the same problems in slightly different ways.
The same rollback mechanism gets built three times. The same alerting logic lives in five repos. The same lessons get learned again and again, team by team.
That duplication is expensive. Not just in headcount, but in focus. Every engineer rebuilding something that already exists elsewhere is an engineer not working on something new. Deduplicating that work frees engineers to focus on additive work instead of duplicative work.
Another reason is coherence.
The systems are tightly coupled in the technology stack. But the teams supporting them aren't. Each has its own processes, its own tooling, its own working rhythms.
This can work up to a certain point. People bridge the gaps informally. A quick message, a shared runbook, someone who just knows who to call.
But as the systems scale, or as the teams continue to diverge in how they work, the cracks start to show. And they show more and more. Incidents fall between teams. Changes in one layer surprise another. Nobody has the full picture of how a failure actually travels through the stack.
Tightly coupled systems supported by disconnected teams are a reliability risk waiting for the complex failure, the one that cuts across teams and lives in the seams between them. In distributed systems, that failure is bound to happen.
Both are good reasons to centralize.
First, Diagnose the Situation
Before deciding how fast to move, it helps to understand what kind of situation you're actually in.
One of the most useful frameworks I've come across for this is the STARS model from Michael Watkins' The First 90 Days. Watkins describes five business situations a leader can walk into: start-up, turnaround, accelerated growth, realignment, and sustaining success. Each one calls for a very different approach.
The book is written for leaders in a new role. But I've found the model just as valuable when you're not new. Applied honestly, it gives more structure to a really important question:
How much disruption can this organization and its stakeholders actually tolerate right now?
In a turnaround, the answer is "a lot." Something is on fire, everyone knows it, and bold, fast moves are expected. Waiting is the risk.
But most central team initiatives aren't turnarounds. They're realignments. The organization is functioning. Services are running. People are busy delivering. The problem is real, but it's slow and structural, not an emergency.
In that situation, the urgency is usually self-imposed. A planning cycle. A headcount window. An HR deadline.
And when there's no crisis, there's no reason to behave as though there is one.
When you have the luxury of time, a methodical approach isn't timid. It's the higher-leverage choice.
The Temptation of the Big Bang
There's a real appeal to standing up a large central team all at once.
It signals commitment.
It feels decisive.
It looks great on a slide.
But here's the thing: a big team doesn't start with a big impact. It starts with a big backlog.
Every team that was promised help shows up with requests. Every expectation lands at the same time. And the new team has no track record to prioritize against, no proven tools, and no established relationships.
The bigger the team at launch, the higher the expectations, and the less room it has to assemble, figure out its priorities, and get something meaningful done.
We learned a long time ago not to ship software this way. We stopped doing big-bang releases because they're risky, hard to roll back, and teach you nothing until it's too late.
Then we reorganize hundreds of people in a single cutover.
Change Capacity Is a Budget
In SRE, we think in error budgets. There's only so much risk a system can absorb before reliability suffers.
Organizations work the same way.
People can only absorb so much change at once: a new manager, new processes, new tools, new expectations about what their job is. Every one of those draws on the same finite budget of attention and trust.
When you move everyone at once, you force everyone to learn at once. Teams are relearning how to prioritize, who to escalate to, and who owns what, all while still being expected to keep the lights on.
That's usually where reliability quietly slips. Not in the design, but in the transition.
Spend the change budget deliberately. Don't burn it all in one quarter.
Start Lean, Start With Value
If I'm building a central team, I start small.
A small, senior team.
Two or three problems that hurt visibly.
Something real delivered before asking for anything more.
Watkins talks about securing early wins, and this is where they matter most. Not wins that look good in a status report, but wins the teams you serve actually feel. A tool they use without being told to. A painful process that just disappears.
Focus is the advantage of a small team. It can say no. It can go deep. It can ship.
Pull, Not Push
The real test of a central team isn't whether it has a mandate. It's whether the teams it serves would fight to keep it.
Adoption that has to be mandated is a signal, not a success. If you have to force people onto your platform, the platform isn't good enough yet.
Build something teams want, and they'll come. Build something they're told to use, and they'll comply. Then they'll quietly build their own thing on the side.
Don't Drain the Domains
One of the most common mistakes in standing up a central team is staffing it by pulling experts out of the teams it's meant to help.
On paper, it makes sense. The expertise already exists, so just move it.
In practice, it weakens the very teams you're trying to elevate. The subject matter expertise leaves the place where the context lives. And the teams that gave up their best people now wait in a central backlog for work that used to get done locally.
I've seen many teams carry real scar tissue from exactly this. They sent their people to a central org, never got their priorities met, and lost the capacity they had before.
Seed the central team with a few people if you need to. But leave the experts where the context is.
Enable, Don't Own
As I wrote in my post on over-centralized incident response, SRE engineers shouldn't be on call instead of system owners. They should be on call with them, or building the systems that make on call less necessary.
The same principle applies to central teams more broadly.
A central team raises the bar. It builds leverage, sets standards, and provides the paved road. But the teams that own the services stay accountable for their reliability and for their automation.
The moment a central team claims ownership of reliability or automation on everyone's behalf, everyone else gets permission to treat it as someone else's problem.
Accountability doesn't scale through an org chart. It scales by lifting the bench.
Treat the Org Change Like a Release
If you must restructure, borrow from how we ship software.
- Canary first. Pick one team or domain and run the model properly there.
- Keep the blast radius small. If something doesn't work, only part of the organization pays for it.
- Define the contracts. Who decides what, who sets priorities, who escalates where. Write it down before people move, not after.
- Have a rollback plan. If you couldn't reverse it, you shouldn't ship it all at once.
- Measure outcomes, not org charts. A new structure isn't a result. Adoption, reliability, and team health are.
- Publish the release notes. Be transparent about what worked and what didn't before expanding.
Then iterate. Expand to the next team. Adjust. Repeat.
Earn Your Scale
The best central teams I've seen didn't start big. They grew because demand outpaced them.
Teams started asking to work with them.
Their tools spread without being mandated.
The "central team versus us" language faded.
That's when you add headcount. When the value is proven and the demand is real, not before.
Let headcount follow impact.
Why This Matters
I've been on both sides of this. I've seen central teams launched at scale that spent their first year explaining why they existed. And I've seen small, focused teams earn their way into becoming the backbone of an organization.
One big difference was sequencing.
Every company has a different profile, and the right level of centralization will vary. Sometimes the situation genuinely calls for a fast, sweeping change.
But when it doesn't, when there's time to be methodical, use it.
Start small.
Deliver value.
Earn the mandate.
Then scale. post on over-centralized incident response
Comments
Post a Comment