Technical credibility and intervention

v1.0 had two competencies here — staying technically credible, and judging when to intervene — and v3.0 merges them because they are one judgment. You can only decide when to step into a technical decision if you are close enough to see it clearly, and staying close is only worth the cost because of the decisions it lets you make well. When a manager stops coding daily, breadth fades slowly and depth fades fast, but systems understanding — the knowledge that actually matters for leading — persists if it is maintained deliberately. Credibility is not being the strongest coder; it is understanding the system well enough to ask sharp questions, to tell real risk from hypothetical, and to know whom to trust on what. Intervention is the hardest technical judgment because its default is restraint: at every scope a manager will see decisions heading somewhere they would go differently, and stepping in too readily robs people of ownership and learning, while not stepping in on the dangerous call is abdication. It matters because both failures are silent — the manager who has drifted from the system does not know it, and the manager who overrides on preference has a team that has stopped deciding. The examinations test it through the new manager still doing the coding, the team about to make the call the manager believes is wrong, the executive who has become the chief architect, and the strategic decision that was deferred to whoever felt strongly.

1. Maintain systems understanding, not currency. Depth in the code fades and cannot be kept without doing the job you left; understanding of the system's shape, risks and dependencies persists if you read designs, stay in the hard rooms and go deliberately deep in one area at a time.
2. Credibility is the quality of your questions, not the competition with the answers. Honest deference — "you know this better than I do; walk me through the trade-off" — builds more trust than pretence, at every scope.
3. Intervene when the cost of being wrong is high and hard to reverse. One-way doors, safety, security, data integrity, customer impact in flight. Stay out when the decision is reversible and owning the outcome will teach more than your answer would.
4. Intervene by raising what was missed, not by overriding with authority. The intervention adds considerations; it does not replace the decision.
5. Above team scope, install a decision process before issuing an opinion. Criteria, evidence, a named decider, a date. The manager of managers who personally approves every architectural decision is not diligent; they are a bottleneck who teaches managers not to decide.
6. Keep an explicit, short docket of the decisions that are yours. At executive scope a handful of technical decisions are inseparable from company strategy and are never fully delegated; everything else is delegated with real authority, and restraint is policy, not mood.

This competency has little empirical literature and a great deal of practitioner consensus; the unit grades its models as practice and borrows two from elsewhere in the standard.

Systems understanding over currency practice

Not a named model but the distinction this unit rests on: the knowledge that matters for leadership is the map — how the system is shaped, where its risks are, what depends on what, who understands each part — and it can be maintained by reading designs and code without becoming an approver, by staying in the room for hard decisions, and by rotating deep dives. Depth in the code is a different thing, and trying to keep it while managing usually fails both jobs. The argument is experiential, and the failure it describes — expertise frozen at the manager's last hands-on year — is common enough to be recognisable.

Task-relevant maturity practice

Grove's concept from Andrew S. Grove, High Output Management (1983), applied here in reverse: the manager's own task-relevant maturity at the technology in front of them decays, and the honest manager calibrates their confidence to it. A manager whose understanding of the current system is really familiarity with the old one has low maturity and high confidence, which is the combination that produces the nostalgia-driven intervention in a stack that has moved on.

The intervention threshold practice

Not a named model but the rule this unit adopts and the examinations test most directly: step in when the cost of being wrong is high and hard to reverse; stay out when the decision is reversible and the learning from owning it is worth more than the correction. It has no author; it is the practical form of Jeff Bezos, 2015 Letter to Shareholders (Amazon.com, Inc.) (2016)'s one-way and two-way doors applied to the question of whose decision it is. Its two failures are symmetrical — overriding on preference, and avoiding a genuinely dangerous call to dodge conflict — and a team that suffers the first cannot make any decision, while a team that suffers the second makes a fatal one.

Installing a decision process practice

The organisational-scope form of intervention: when a cross-team decision is deadlocked, irreversible at department scale, or quietly commits the whole department, the manager of managers usually intervenes not by supplying the answer but by installing the process that will produce it — the criteria, the evidence required, who decides, by when. It converts an intervention into a capability the organisation keeps.

The executive docket practice

Not a named model but the executive-scope practice this unit treats as decision architecture: an explicit, short list of the technical decisions the executive personally owns because they are inseparable from company strategy — bet-the-company technology choices, build-versus-buy for the capability that most differentiates the product, core-capability vendor lock-in, infrastructure the product will increasingly stand on, the organisation's security and reliability posture — with everything else delegated to senior engineers with real authority. The docket that is too long is micromanagement with a title; the docket that does not exist means the strategic decisions get made by default.

Reading without gatekeeping

The manager reads design documents and, selectively, code, to keep the map current — and is not a required approver of either. The reading produces questions in the design room, not approvals in the pipeline.

The quarterly deep dive

Each quarter, one system or domain is chosen and the manager goes deliberately deep: the design, the risks, the people who understand it, what breaks first under load. Shallow everywhere is not understanding; deep somewhere, rotating, maintains a map that is honest in the places that matter.

The threshold, stated

The manager writes down, for their team, the kinds of decision they will step into — the one-way doors, anything touching safety, security, data integrity or customers in flight — and says that everything else is the team's. The list is short, applied consistently, and the team can predict it.

Intervening as questions

When the manager does step in, it is with what was missed: "what happens to in-flight orders during the cutover?" rather than "do it this way". If the question does not change the decision, the team owns the outcome and the manager owns the restraint.

The decision process, installed

For a cross-team decision that is stuck or dangerous, the manager of managers issues the process before any opinion: the criteria the options will be judged on, the evidence required, the person who will decide, and the date. Opinions follow the evidence.

The docket, written

The executive keeps a short written list of the technical decisions they own, reviews it twice a year, and delegates everything not on it with real authority. When a decision on the docket is about to be made elsewhere — a differentiating capability about to be bought because a team preferred it — the executive takes it back explicitly.

At team scope the object is when to step into a design or a fix and when not to, and the manager stays close through reading and presence while owning the restraint. At organisational scope the manager stays credible one level up — reviewing designs rather than code, rotating deep dives, using architecture forums and principal engineers as standing tutorials, maintaining a map of systems, risks and experts — and intervenes by installing a decision process when scope, irreversibility, deadlock or department-level commitment triggers it, acting through managers rather than around them. At executive scope credibility is structured sensing — architecture and operations reviews with evidence, principal engineers who tell the truth, sampled raw signal that keeps the aggregates honest — and intervention is decision architecture: the short docket, and real delegation of the rest. The pattern is in How Judgment Scales; the economics of the docket's build-versus-buy decisions are SV-4 Engineering economics.

• Reads code and designs to stay close to how the system evolves, without becoming a required approver. team
• Stays in the room for hard technical decisions. team
• Goes deliberately deep in one area each quarter rather than shallow everywhere. team
• Defers honestly to engineers' depth: "you know this better than I do; walk me through the trade-off."
• Lets reversible decisions ride even when they would choose differently, and steps in on the irreversible and the dangerous. team
• Intervenes by raising what was missed, not by overriding with authority.
• Failure mode — clinging to best-coder status and becoming the bottleneck. team
• Failure mode — faking understanding. team
• Failure mode — drifting so far from the system that you cannot reason about it. team
• Failure mode — overriding on preference. team
• Failure mode — avoiding a genuinely dangerous call to dodge conflict. team
• Failure mode — being the permanent final approver. team
• Stays credible at one remove: design reviews as code reading, rotating deep dives, architecture forums and principal engineers as tutorials, a maintained map of systems, risks and experts. org
• Asks the questions that expose reasoning — what breaks first under ten times the load — and earns a principal engineer's respect for the questions rather than competing with the answers. org
• Gets directly involved when a decision crosses team boundaries with material consequences, is irreversible at department scale, is deadlocked at a cost greater than a decision, or quietly commits the whole department. org
• Installs a decision process — criteria, evidence, decider, date — before issuing an opinion. org
• Intervenes through the manager, not around them, when a team is about to make a decision the manager of managers believes is wrong. org
• Failure mode — technical currency by nostalgia, frozen at the last hands-on year. org
• Failure mode — skipping the technical rooms entirely. org
• Failure mode — the approval bottleneck. org
• Failure mode — picking sides in a deadlock instead of forcing a fair decision. org
• Failure mode — discovering a department-level commitment after the fact because "it was the team's call". org
• Maintains judgment through structured sensing: architecture and operations reviews with evidence, principal engineers who tell the truth, periodic deep dives into the systems carrying the most strategic risk, external calibration. exec
• Keeps aggregate signals honest with sampled raw material — an incident review attended, a design document read, a skip-level with a staff engineer. exec
• Keeps an explicit, short docket of executive-owned technical decisions and delegates everything else with real authority. exec
• Takes back a docket decision — the differentiating capability, the strategic dependency — that is about to be made by whoever felt strongly. exec
• Failure mode — the executive as chief architect. exec
• Failure mode — technical judgment outsourced entirely to whoever presented last. exec
• Failure mode — dashboards with no contact with reality. exec
• Failure mode — discovering strategic lock-in in a renewal negotiation. exec
• Failure mode — a docket so long it is micromanagement with a title. exec

Closeness versus bottleneck. The closer a manager stays to the code, the better their judgment and the more the team waits on them. Reading without approving is the resolution; the moment reading becomes gatekeeping, the closeness costs more than it buys.

Ownership versus outcome. Letting a team own a decision the manager thinks is wrong risks the outcome; overriding it risks the team's ability to decide. The threshold — reversibility and cost — is what decides which risk to take, and the failure is applying it by mood.

Honesty versus authority. Saying "you know this better than I do" can feel like giving up standing, and pretending to understand is the faster way to lose it. Credibility at scope is built on the questions, and the questions are better when the manager is honest about what they do not know.

Process versus speed. Installing a decision process takes longer than giving the answer, and the answer teaches nothing. For decisions that recur, the process is the higher-leverage intervention; for a genuine emergency, the answer is.

Delegation versus strategy. Delegating all architecture to senior engineers is what the executive should mostly do, and a handful of technical decisions are inseparable from company strategy and cannot be delegated without being made by default. The docket is the line, and it is kept short on purpose.

A senior manager with four teams learns, in a weekly one-on-one with one of their managers, that the team is about to commit to a new event-streaming platform for a service that three other teams consume. The manager supports the choice; the team's lead engineer is enthusiastic; the platform is capable and the senior manager, who ran a similar migration years ago on a different technology, believes it is the wrong call — the operational burden will land on a team that has never run stateful infrastructure, and the consumers have not been consulted.

The pull is to say no. The senior manager knows the domain, has the authority, and the manager would comply. That would be the nostalgia-driven intervention the unit warns about — the senior manager's understanding is of a technology that has moved on — and it would teach the manager that decisions of this kind are not theirs.

The senior manager applies the threshold first. Is this reversible? Not cheaply: a streaming platform underneath a service three teams consume is a one-way door at department scale, and it quietly commits the whole department to operating it. Does it cross team boundaries with material consequences? Yes; the consumers have not been asked. The threshold is met on scope and irreversibility, and the senior manager is right to be involved — but the form of the involvement is the judgment.

They do not overrule. They install a decision process, through the manager: the choice will be made on criteria the senior manager names — operational burden and who carries it, consumer impact and consent, reversibility, and total cost including on-call — with evidence from a two-week bounded evaluation, reviewed at the architecture forum, and decided by the manager and the lead engineer with the consuming teams' leads present. The senior manager also says, honestly, what their own concern is and where it comes from, and that their experience is of a different technology.

The evaluation changes the decision: the consumers surface a constraint nobody had considered, and the operational burden turns out to need a platform team that does not exist. The manager chooses a managed service instead. The decision is theirs, made better, and the department has a process it will use again.

What the senior manager does not do is either of the comfortable things: say nothing because it was the team's call, or say no because they once knew this.

• PL-1 Delegation, ownership, and decision rights — the intervention threshold as decision rights; not taking delegated work back.
• PL-6 Leading through leaders — intervening through a manager rather than around them.
• TJ-1 Evaluating architectural decisions and their organisational consequences — the architectural decisions the docket keeps and the forum reviews.
• SV-4 Engineering economics — build-versus-buy for the differentiating capability, and strategic dependency as the executive's decision.
• CC-2 Coaching versus directing — the coaching form of intervention: questions that develop judgment rather than answers that replace it.

1. Which kind of technical knowledge persists after you stop coding, and how is it maintained?
   Answer

   Systems understanding — the shape of the system, its risks, its dependencies, who knows what. Maintained by reading designs and code without approving them, staying in the room for hard decisions, and going deliberately deep in one area each quarter.
2. What two factors most justify stepping into a technical decision?
   Answer

   High cost of being wrong, and difficulty of reversal — one-way doors, safety, security, data integrity, customer impact in flight. Reversible decisions where owning the outcome teaches more than the correction are left with the team.
3. When you do intervene, how?
   Answer

   By raising what was missed — a question that adds a consideration — not by overriding with authority. If the question does not change the decision, the team owns the outcome.
4. What triggers a manager of managers' direct involvement, and why is installing a process usually better than giving the answer? org
   Answer

   Scope across team boundaries with material consequences, irreversibility at department scale, deadlock costing more than a decision, or a decision that quietly commits the whole department. A process — criteria, evidence, decider, date — produces a better decision and leaves the organisation with a capability; an answer produces one decision and teaches managers not to decide.
5. What does "reviewing designs rather than code" preserve, and what map is being maintained? org
   Answer

   Credibility at one remove — enough understanding of every system's shape, risks and dependencies to know where to look harder and whom to believe — without competing with engineers' depth or becoming an approver. The map is of systems, risks and experts, not mastery.
6. Which technical decisions belong on an executive's personal docket, and what makes fully delegating them a strategy error? exec
   Answer

   Bet-the-company technology choices, build-versus-buy for the differentiating capability, core-capability vendor lock-in, infrastructure the product will increasingly stand on, and the security and reliability posture. Fully delegating them does not remove the decision; it means they get made by default, by whoever felt strongly.
7. How does an executive keep aggregate signals honest without becoming the organisation's most senior micromanager? exec
   Answer

   Structured sensing plus sampled raw signal: a small set of organisation-level trends, validated by direct exposure on a sampling basis — an incident review attended, a design document read, a skip-level with a staff engineer — and principal engineers who know the executive wants truth rather than reassurance.

• Andrew S. Grove, High Output Management (1983) — task-relevant maturity, applied to the manager's own decaying currency.
• Jeff Bezos, 2015 Letter to Shareholders (Amazon.com, Inc.) (2016) — one-way and two-way doors as the basis of the intervention threshold.