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.
At a glance
- What
- A private, half-day service ownership and criticality workshop, run for one engineering team on its own services.
- Who it’s for
- Directors and VPs of engineering, and heads of platform, at organizations with roughly 100 to 1,000 engineers.
- What you leave with
- A tier map of your actual services, a classification method your team can keep running, and the first thing to fix.
- Format
- About four hours, remote, up to 25 people. You pick the date.
- Price
- $6,000 for the session. One fee, not per seat.
- How to start
- Book a 20-minute call, or ask by email.
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.
Questions people ask
- What is a service tiering workshop?
A working session where your team decides how critical each of your services actually is, and writes it down. Not a lecture. You classify your own system, against evidence, and leave with a tier map.
- How do you decide which services are Tier 1?
From what happens when the service fails, not from who built it or how important it feels. A tier is a set of commitments: an availability target, an on-call obligation, a review burden, a spend level. If a service doesn’t need those commitments, it isn’t Tier 1.
- Why didn't our service catalog fix this?
A catalog records decisions. It doesn’t make them. If nobody decided what matters most and who owns it, the catalog fills up with metadata nobody trusts. I wrote about this in When Everything Is Critical, Nothing Is.
- How does this relate to STOSA?
STOSA is the ownership model: every service has exactly one owning team. This workshop is the criticality half. Which services matter most, so ownership and reliability spend go where they count.
- Who should be in the room?
The people who can decide. Engineering leadership, the platform team, and the owners of your most argued-about services. The session is worth less with a room that has to go ask someone.
- How much does it cost?
$6,000 for the session, up to 25 people. One fee, not per seat, so there’s no reason to leave anyone out.
- Is it remote? Can you come on site?
It runs remote by default. On-site is possible. Ask, and I’ll quote it for your location.
- What do we need to prepare?
A list of what you run, if you have one. If you don’t, that’s fine. Building the inventory is the first part of the work, and it’s where most teams find out what they didn’t know.
- What does it not cover?
Availability targets, error budgets, ownership assignment, blast radius and the incident path. Those come after you have tiers. I’ll tell you which to tackle next.
- Who runs it?
I do. Lee Atchison. Seven years at Amazon and AWS, eight at New Relic, and the author of Architecting for Scale (O’Reilly), which covers this problem in depth. More at leeatchison.com.
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.