Everything is Critical. So nothing is.
Your team leaves with a tier map, and a plan. In one afternoon.
A private half-day working session on service ownership and criticality, run for your team, on your services.
Something broke at 3am. The page went out.
How long between that page firing and it reaching the person who could actually fix the thing? Not the person on call. The person who knew.
That gap is what this session closes.
Most engineering organizations never made two decisions they think they made. What services matter most, and who is accountable for keeping the services up and operational. A service catalog does not make either one. It records decisions you already made, which is why catalog rollouts stall out with metadata nobody trusts.
So everything ends up critical. And when everything is critical, your reliability budget gets spread flat across services that do not deserve it equally, while the incident load never moves.
What happens in the room
This is not a talk. Your team does the work, on your own systems, and I adjudicate.
We start with the premise and a live scoring exercise, so the room sees its own gap before anyone argues about it. Then we install the model. A tier is a commitment, and you derive it from what happens when the thing fails rather than from the org chart.
Then the real work. We inventory what you run, which is where most teams discover what they do not know. We classify it against evidence.
Databases, pipelines, third-party dependencies, and the internal tool that pages you at 3am all get a tier assignment. Everything does.
And then, we have the argument about what “Tier 1” really means, and why everything can’t be the most critical service in your system.
The argument is the valuable part. It is usually the first time the organization has priced its own assumptions out loud, with the right people in the room to settle it.
What you leave with
- A tier map of your actual services, argued through and written down.
- A classification method your team can keep running without me.
- One thing to fix first, with a reason attached, and a plan you can follow from there.
Who it is for
Directors and VPs of engineering, and heads of platform, running somewhere between 100 and 1,000 engineers. It lands hardest if you are a year or two past a microservices migration, or partway into a service catalog rollout that stopped.
Bring the people who can actually decide. The session is worth less with a room that has to go ask someone.
Format and price
Half a day, about four hours, remote. Up to 25 people.
$6,000 for the session. One fee, not per seat. Bring everyone who should be there.
You pick the date.
Two ways to start. Pick whichever you would rather do.
Both come straight to me. Same attention either way.
A short call, and I will tell you whether this is worth your afternoon or whether you already have the parts that matter.
Send your questions and I will answer them properly, in writing.
Lee Atchison spent seven years at Amazon and AWS and eight at New Relic, building and running systems at scale. He wrote Architecting for Scale (O’Reilly) on exactly this problem. He works with engineering organizations on risk, availability, and what it costs when nobody owns the thing that broke.