« Phase 16 · Warmup · Track Overview
Principal Deep Dive — The Trade-offs You Own
The deep dive covered how the mechanisms work. This covers the decisions where there is no correct answer, only a defended one.
Table of Contents
- 1. The central tension: mechanism against judgment
- 2. Establishing two-in-a-box when the other person did not ask for it
- 3. When two-in-a-box is the wrong model
- 4. Setting the SLO you will actually hold
- 5. Calibrating the ORR
- 6. Where to spend your credibility
- 7. The autonomy conversation
- 8. Building the team you need
- 9. What to say to a regulator
- 10. Setting the numbers
- 11. The first ninety days
- 12. What I would not do
1. The central tension: mechanism against judgment
Every instrument in this phase replaces a judgment with a rule.
JUDGMENT MECHANISM
│ │
"we'll + a checklist + a gate + a scoring + a pipeline
decide" function that refuses
│ │ │ │ │
fast, and consistent enforceable auditable nobody can
inconsistent override
│ │
depends on cannot handle
who is in the case nobody
the room anticipated
Both ends fail, and they fail differently.
Pure judgment produces decisions that depend on who was in the room, cannot be explained to a regulator, and do not survive either owner leaving. It also produces the specific failure this phase exists to prevent: a disagreement resolved by seniority.
Pure mechanism produces a gate that blocks the case nobody anticipated, and a team that learns to route around it — which is worse than no gate, because it is also invisible.
The position I would defend:
Mechanize the decisions you have already made. Leave judgment for the ones you have not.
The error-budget policy mechanizes a decision the pair already made about risk appetite. The ORR mechanizes a definition of "ready" already agreed. Neither is deciding something new — they are remembering a decision under conditions where memory is unreliable.
Which gives the test for whether a new mechanism is a good idea: have we made this decision already, more than once, the same way? If yes, mechanize it. If it is a new question every time, a rule will be wrong.
2. Establishing two-in-a-box when the other person did not ask for it
The realistic starting position: you arrive, the product owner has been running the platform, and "two-in-a-box" is a phrase in a job description that neither of you has operated.
They may reasonably hear it as a takeover.
Four moves, in order, and the order matters:
One — take the pager first, and visibly. Before asking them to. It signals that the shared surface is real and that you are taking on their burden rather than their authority.
Two — bring an instrument, not a reorganization. The error-budget policy is a good first one: it constrains you as much as them, it is concrete, and agreeing it is a small collaborative artifact. Do not open with an org chart.
Three — ask for their pager explicitly, and later. Once there is a shared instrument and a quarter of shared context. And frame it accurately: not "you should suffer too" but "the roadmap decisions you make change when you have seen the 3 a.m. failure modes, and I cannot transmit that second-hand."
Four — use the decision router immediately. The first time something is reversible-internal, say so and decide it alone, then tell them. That establishes that the model is not "everything now needs two people", which is the thing they are actually worried about.
And the thing that earns it faster than any of the above: make their job easier in the first month. A capacity forecast they can take to a stakeholder, a cost-per-action number they did not have, a clear answer to a question they had been fudging. Two-in-a-box is a relationship before it is a model.
3. When two-in-a-box is the wrong model
It is not universally correct, and being able to say when it is not is a stronger signal than advocating for it everywhere.
When the surface is genuinely partitionable. A platform where product decisions do not carry engineering risk works fine with an EM/PM split, and the overhead of shared accountability buys nothing.
When one owner cannot carry the pager. If the product owner genuinely cannot triage — no access, no context, no capacity — then shared on-call is theatre, and the model degrades into a partition with extra meetings. Better to name it and run a partition well.
When the escalation point does not exist. The protocol depends on somebody owning the trade-off above the pair. If disagreements have nowhere to go, the model produces stalemates rather than decisions.
When the pair is unstable. Two-in-a-box takes a quarter to establish. If either role is expected to turn over inside six months, the artifacts are worth building and the model is not.
When the two people cannot disagree with each other. This is the uncomfortable one. The model requires both to state a position and hold it, and a pair where one defers by habit — for seniority, tenure or temperament — produces one owner with a witness. The failure is silent, and the tell is that no disagreement has ever been escalated.
4. Setting the SLO you will actually hold
The error-budget policy is only as good as the SLO, and the SLO is the pair's most consequential shared number.
Three failure modes, all common:
| Failure | Consequence |
|---|---|
| Set too high | permanently breached; the policy never applies; the apparatus is decorative |
| Set too low | never breached; the budget governs nothing; ditto |
| Set by engineering alone | it is a target, not a commitment; the PO does not defend it |
The process that works:
Measure first, for a month. No target. Then you know what the platform actually delivers, which is the only defensible starting point (Phase 14).
Set it slightly below measured performance. So the budget is real but not immediately exhausted. An SLO above current performance means the policy is in permanent freeze on day one, and everyone learns to ignore it.
Derive it from user consequence, jointly. "What does the user do when it fails — retry in thirty seconds, or call the branch?" is a product question with an engineering answer, which is precisely the kind of question the model exists for.
Check the dependency ceiling. You cannot promise more than your dependencies allow (Phase 00), and doing that arithmetic in the room ends most over-ambitious targets.
Review it quarterly. And the review question is the honest one: did we hold it, and did the policy bind? An SLO never breached in a year is too loose; one breached every month is too tight. Both are signals to change the number rather than the behaviour.
5. Calibrating the ORR
An ORR that never fails is a form. One that fails everything is a bottleneck teams route around.
The target: a 60–70% first-pass rate. Which means most services need one round of fixes, and that is the point — the ORR's value is the fixing, not the passing.
Three calibration decisions:
Which criteria are mandatory. The test I would apply: would I be comfortable explaining to a regulator that this service went live without it? Alerts untested, runbook unrehearsed, rollback untested, eval suite unrun — none of those survive that question. A load test at 2× peak does, so it is advisory.
The advisory threshold. 70% is a reasonable default. What it is for is signalling that a service passing every gate with the bare minimum of everything else is worth a conversation.
Who reviews. Not the building team — the same independence argument as Phase 15. A rota across senior engineers, and the reviewer opens at least one piece of evidence.
And the calibration to revisit: which criteria never fail? A criterion that has passed on every service for a year is either universally satisfied — in which case it is a control somewhere else already, and the ORR row is redundant — or nobody is checking it. Both are worth knowing, and the review that finds them is annual.
6. Where to spend your credibility
You arrive with a finite amount, and every mechanism you introduce spends some. The sequencing matters more than the content.
Spend it on:
| Item | Why |
|---|---|
| The error-budget policy | it binds you too, so it costs less than it looks |
| The ORR | it is the gate that prevents the incident that would cost you more |
| The pins (Phase 15) | free at runtime, irreversible if deferred |
| The join key | same |
| One quality bar, enforced consistently | the first "no" is expensive; the tenth is free |
Do not spend it on:
| Item | Why |
|---|---|
| Style and tooling preferences | high friction, low value, and it reads as taste |
| Rewriting something that works | the credibility cost exceeds the technical gain |
| Every review comment | separate blockers from opinions and let the opinions go |
| Being right in a forum | winning an argument with Cyber costs more than it gains |
And the sequencing insight: the first mechanism you introduce should constrain you visibly. An error-budget policy that freezes your feature work is a much better first artifact than a code standard that constrains everyone else, because it establishes that the mechanisms are not a way of getting your preferences enforced.
7. The autonomy conversation
The recurring two-in-a-box conversation on an AI platform, and it recurs because it is genuinely hard.
The product owner wants the agent to act autonomously — better experience, less friction, and it is the point of the platform. You see an irreversible action with a residual risk.
What does not work: "it is too risky". It is not a position they can engage with, and it makes the risk sound like a preference.
What works — three moves:
One — make it a band, not a binary. The autonomy ladder (Phase 10) converts "yes or no" into "which rung, and what does the next one require?" That reframes an argument as a plan.
Two — attach an evidence contract to each rung. "Autonomous release under 10,000 AED requires thirty days at the assisted band with zero reversals and a passing safety suite." Now the product owner has a route, and the route is one they can drive.
Three — make demotion automatic. An incident drops the band, mechanically, no meeting. Which is what makes promotion palatable: the downside is bounded and pre-agreed, so agreeing to a promotion is not agreeing to an open-ended risk.
And the honest thing to concede: the risk appetite is not yours alone. If the product owner and the business are prepared to accept a residual risk that you would not, and the tier and validation say it is permissible, that is a values disagreement that escalates — it is not one you win by holding the gate. Recognizing which of the two it is, quickly, is most of the skill.
8. Building the team you need
The JD says mentorship, and the specific challenge for an AI platform is that the skill set does not exist as a hiring pool.
What the team needs, and where it comes from:
| Capability | Realistic source |
|---|---|
| Distributed systems | hire; it is the hardest to teach |
| Identity and security | hire, or partner with Cyber |
| SRE | hire, or grow from strong backend engineers |
| Model behaviour and evaluation | grow — the pool is thin and the domain is new |
| Bank domain | grow, or borrow from the business |
| Regulated-industry instincts | grow; it takes a year |
The two "grow" rows are the real work, and they suggest the shape: hire for distributed systems and teach the AI parts, rather than the reverse. An engineer who understands idempotency, blast radius and error budgets learns evaluation in a quarter. An ML engineer who has never operated a side-effecting system takes considerably longer to learn why the action gateway exists.
Three mentorship practices with the most leverage:
Pair on the first artifact of each kind. The first ADR, the first ORR, the first design review. Then review the second rather than writing it.
Rotate the reviewer role. A design review run by a different senior engineer each time, against the standing checklist, is how you remove yourself from the critical path and raise the floor simultaneously.
Teach one counter-intuitive thing explicitly: the model is not the system. Engineers arriving from ML think in terms of model quality; the platform's work is almost entirely the layers around it. A mentee who internalizes the model proposes, the platform disposes has understood the architecture, and it takes one conversation.
9. What to say to a regulator
The conversation the JD names, and the one where the temptation to overstate is strongest.
Three principles:
Never claim more than you can demonstrate. Every claim invites "show me". A claim you cannot support costs you the credibility of the claims you can — including the true ones, which is the expensive part.
Bring the limitation before they find it. "Residency is proved two ways — the topology analysis and the per-record check — and here is what the topology model does not cover" is a much stronger position than being asked. It signals you know your own system, which is the thing actually being assessed.
Show, do not describe. "We have dual control" is a claim. An evidence pack showing two approvers on 12 March is evidence (Phase 15).
The three sentences worth having ready, because each is a question that will come:
On injection: "Prompt injection cannot be prevented — no vendor has solved it. We bound the consequence: an injected instruction can cause a read and cannot cause a payment or an egress without a human who sees where the instruction came from."
On reproducibility: "We reproduce the decision context, not the exact output. Given the pinned configuration and the recorded inputs we can show what the agent was working from and what it was permitted to do."
On concentration: "Our alternative provider carries five percent of production traffic today. On the alternative, quality drops eight percent on our evaluation suite and latency rises forty percent. That is the measured cost of an exit, not an estimate."
Each is honest, each is more useful than a reassurance, and each demonstrates the thing being tested: that you know where your own limits are.
10. Setting the numbers
The SLO. §4 — measured, then slightly below, jointly derived, dependency-capped, reviewed quarterly.
Budget state thresholds. 50 / 20 / 0 is a reasonable default. The one to think about is elevated: it is the state where you want behaviour to change before it is urgent, and 50% with two weeks left in the window is roughly the right feel.
Exception TTL. Seven days. Long enough to ship, short enough that it cannot become standing.
Exception rate limit. Two per quarter. Above that, renegotiate the SLO — and say so in the refusal.
ORR advisory threshold. 70%.
ORR first-pass target. 60–70%. Calibrate the criteria against it annually.
ADRs per quarter. 5–10 for a platform. Below that the architecture is in two heads; above it they are meeting notes.
Pages per owner per week. Under two. Above that, fix the alerting before fixing anything else — including before asking the product owner to share the rota.
Post-mortem review within. Five working days of resolution, while it is remembered.
Action-item due dates. Two weeks default. A six-week action is a project and should be in the backlog rather than the tracker.
11. The first ninety days
The sequencing that works, and the ordering is the content.
Days 1–15 — take the pager, and listen. Do not change anything. Learn the failure modes, the existing decisions, and where the bodies are. Meet each of the five forums once, with no agenda.
Days 15–30 — measure. SLIs, cost per action, the current ORR-equivalent (probably nothing). Produce one number the product owner did not have and wanted.
Days 30–45 — the first shared instrument. The error-budget policy, agreed and signed. It constrains you as much as them, which is why it is first.
Days 45–60 — the decision router and the first ADR. Written together, about a decision you are actually making. The artifact matters less than the practice of making one.
Days 60–75 — the ORR, agreed with the product owner and with whoever else must sign off. Apply it first to something you are shipping.
Days 75–90 — ask for the shared pager, with a quarter of context behind the request. And run the first design review with the standing checklist.
Two things to resist:
Do not introduce a mechanism in week one. It reads as importing a process from your last job, and you have not yet earned the assumption that it fits this one.
Do not fix the architecture first. Whatever is wrong with it, it is running, and the operating model is what determines whether the fix lands. Mechanisms compound; a refactor does not.
12. What I would not do
Introduce every mechanism at once. Six new processes in a quarter is a reorganization, and it will be experienced as one. One per month, each with a visible reason.
Mechanize a decision made once. A rule derived from a single case is a rule that will be wrong the second time. Wait for the pattern.
Use the error-budget policy as leverage. The moment it is a stick rather than a shared instrument, the product owner starts disputing the measurement, and the number stops being trusted by either of you.
Escalate a factual disagreement. It reads as an inability to work together and it is unnecessary — measure it instead.
Win in a forum. Being right at Cyber's expense costs more than the point is worth. The relationship is the asset.
Take the pager away from the product owner after a bad week. It is protective and it removes the mechanism that makes the model work. Fix the alerting instead.
Write an ADR to justify a decision already made. It is recognizable — one option, no negatives — and it is worse than no ADR, because it looks like a record and is a rationalization.
Run an ORR I would exempt myself from. The first service through the gate should be one of mine, and it should fail the first time if the gate is calibrated correctly.