« Track Overview · Warmup · Lab 01
Phase 16 — Two-in-a-Box: Engineering Leadership, Design Reviews, ORR & Regulator Conversations
Answers these JD lines: "Operate in genuine two-in-a-box with the existing Platform Product Owner, including shared on-call, shared roadmap ownership, and shared accountability for major architectural decisions, regulator conversations, and critical incidents" · "Drive engineering excellence across the platform team, including testing discipline (unit, integration, evaluation, red-teaming), documentation, infrastructure as code maturity, operational readiness reviews, and technical mentorship of platform engineers" · "Represent the platform in senior technical forums with Enterprise Architecture, Cyber, Model Risk, Internal Audit, and the Group CTTO's office."
Why this phase exists
Most candidates treat the leadership half of this JD as boilerplate. It is not: two-in-a-box is a named operating model with specific mechanics, and the interview will probe whether you have actually run one.
The distinguishing property is that accountability is undivided, not partitioned. A normal EM/PM split says "you own tech, I own product," and it fails exactly at the boundary where AI platforms fail — where a product decision (autonomy band, agent onboarding pace) is an engineering risk decision. Two-in-a-box says both owners are accountable for the same surface: availability, performance, cost, security posture, architectural evolution. Including the pager.
Shared accountability without shared instruments is two people blaming each other after an incident. The instruments are concrete and this phase builds them:
- an error-budget policy, signed before the first breach, so the freeze is a rule rather than an argument;
- a disagreement protocol, agreed in advance, so a genuine disagreement produces a decision rather than a stalemate or an averaged design;
- ADRs, so architectural memory survives both owners;
- an ORR gate, so "ready for production" is a checklist rather than a feeling;
- and a forum playbook for Enterprise Architecture, Cyber, Model Risk, Internal Audit and the CTTO's office — five audiences who ask different questions and reward different answers.
Concept map
- Two-in-a-box mechanics: undivided accountability; shared on-call; either owner can speak for the platform; everything material becomes an artifact because two people must stay synchronized.
- The error-budget policy: the four states (normal / elevated / reliability-focus / freeze), what each changes, and — critically — how exceptions are made expensive and visible so the policy does not quietly die after two of them.
- The disagreement protocol: classify the decision (reversible? externally visible?); separate facts from values; measure the factual half; for genuine value disagreements, escalate both written positions rather than averaging; disagree and commit, in writing.
- ADRs: one decision, immutable, with context / options / decision / consequences — including the negative ones.
- Design reviews: the five-question framework from Phase 00 (what does it deny · blast radius · can it degrade · what artifact does it emit · who operates it at 3 a.m.), plus the standing red-flag list assembled from every phase in this track.
- Operational readiness review: the gate — SLOs instrumented, alerts tested by injecting failure, runbook rehearsed, rollback tested, dependencies mapped with blast radius, capacity headroom verified, on-call trained — plus the agent-specific rows: eval suite passing, red-team suite passing, tool scopes reviewed, cost ceiling set, degradation behaviour defined, autonomy band assigned.
- Testing discipline as a platform standard: unit · integration · evaluation · red-team, and which of them gate a release.
- Incident command: roles, comms cadence, the difference between mitigation and fix, and blameless post-mortems whose action-item completion rate is itself tracked.
- The five forums: what Enterprise Architecture, Cyber, Model Risk, Internal Audit and the CTTO each actually want, and the artifact that satisfies each.
- Mentorship and standards: how a standard becomes a control (a rule in
publish()beats a rule in a wiki), and how to raise the floor without becoming the bottleneck.
The lab
| Lab | You build | Proves you understand |
|---|---|---|
| 01 — The Operating Model, as Code | an ORR scorer with weighted mandatory and advisory criteria that refuses promotion on any mandatory failure and explains why; an error-budget policy machine that maps budget state to permitted change classes, with an exception register that expires; an ADR store with immutability, supersession and a decision-class router (reversible → single owner, irreversible → both, unresolved → escalation with both positions recorded); a design-review checklist engine that runs the standing red flags against a structured design document; and an incident-review tracker measuring action-item completion | that an operating model is a set of mechanisms with states and transitions — and that writing them down is what makes shared accountability survive a real disagreement |
113 tests, all green. Test contract: an ORR with any mandatory criterion failing cannot pass at any score; an expired exception reverts the budget state automatically; an accepted ADR cannot be edited, only superseded; an irreversible decision recorded by one owner is rejected; and a design document missing a stated blast radius fails the checklist.
Documents
| Document | For |
|---|---|
| WARMUP.md | zero to principal on the operating model — first principles, then the interview answers |
| HITCHHIKERS-GUIDE.md | the fast orientation: what the pieces are and how they fit |
| DEEP-DIVE.md | the mechanisms, in detail, with the failure modes |
| PRINCIPAL-DEEP-DIVE.md | the trade-offs you own at principal level |
| CORE-CONTRIBUTOR.md | the literature and the open tooling behind these practices |
| STAFF-NOTES.md | judgment, review signal, war stories |
Deliverables checklist
- You can define two-in-a-box and distinguish it from an EM/PM split.
- You can state a four-state error-budget policy and how exceptions are controlled.
- You can describe the disagreement protocol, including what you do with a values disagreement.
- You can write an ADR for a real decision from this track, including negative consequences.
- You can run a design review with the five questions and the red-flag list.
- You can list the ORR gate, including the six agent-specific rows.
- You can say what each of the five forums wants and which artifact satisfies it.
Key takeaways
- Undivided accountability, shared pager. That is the definition; the rest is mechanism.
- Sign the error-budget policy before the first breach, and make exceptions expensive.
- Agree the disagreement protocol in advance. Averaged architectures are worse than either option.
- A standard in code is a control; a standard in a wiki is a suggestion.
- Test your alerts by injecting failure. An untested alert is a belief.
- Autonomy is granted in bands, each with a fixed evidence contract, so teams choose knowingly.
- Track action-item completion. It is the only honest measure of a post-mortem culture.