Technical credibility and intervention

v1.0 had two competencies here, staying technically credible and judging when to intervene. 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 what it costs because of the decisions it lets you make well. Once a manager stops coding daily, breadth fades slowly and depth fades fast. Systems understanding, which is the knowledge that matters for leading, persists if it is deliberately maintained. Credibility does not mean being the strongest coder. It means understanding the system well enough to ask sharp questions, to tell real risk from hypothetical risk, 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 not have taken them. Stepping in too readily robs people of ownership and learning, and failing to step in on a dangerous call is abdication. It matters because both failures are silent. The manager who has drifted away from the system does not know it, and the manager who overrides on preference ends up with a team that has stopped deciding. The examinations test it through a new manager who is still doing the coding, a team about to make a call its manager believes is wrong, an executive who has become the chief architect, and a strategic decision left to whoever felt strongly.

1. Maintain systems understanding, not currency. Depth in the code fades, and you cannot keep it without doing the job you left. Your understanding of the system's shape, risks and dependencies will last 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. At every scope, honest deference ("you know this better than I do; walk me through the trade-off") builds more trust than pretending.
3. Intervene when the cost of being wrong is high and hard to reverse. That means one-way doors, safety, security, data integrity and customer impact in flight. Stay out when the decision is reversible and owning the outcome will teach the team more than your answer would.
4. Intervene by raising what was missed, not by overriding with authority. The intervention adds considerations. The decision stays where it was.
5. Above team scope, install a decision process before issuing an opinion. Set the criteria, the evidence, a named decider and a date. A manager of managers who personally approves every architectural decision is a bottleneck, however diligent it looks, and teaches their 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 a matter of policy instead of mood.

There is little empirical literature on this competency and a great deal of practitioner consensus. The unit grades its models as practice, and borrows two of them from elsewhere in the standard.

Systems understanding over currency practice

This is the distinction the unit rests on, though it is not a named model. The knowledge that matters for leadership is the map: how the system is shaped, where its risks lie, what depends on what, and who understands each part. A manager can maintain it 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 means doing both jobs badly. The argument is experiential. The failure it describes, expertise frozen at the manager's last hands-on year, is common enough to recognise.

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 with the technology in front of them decays, and an honest manager calibrates their confidence to match. A manager whose understanding of the current system is in fact familiarity with the old one has low maturity and high confidence. That combination produces the nostalgia-driven intervention in a stack that has moved on.

The intervention threshold practice

This is the rule the unit adopts and the one the examinations test most directly, though again it is not a named model. Step in when the cost of being wrong is high and hard to reverse. Stay out when the decision is reversible and owning it will teach more than the correction is worth. The rule has no author. It is Jeff Bezos, 2015 Letter to Shareholders (Amazon.com, Inc.) (2016)'s one-way and two-way doors put to practical use on the question of whose decision it is. Its two failures mirror each other: overriding on preference, and avoiding a dangerous call to dodge conflict. A team that suffers the first cannot make any decision, and a team that suffers the second makes a fatal one.

Installing a decision process practice

Intervention takes this form at organisational scope. A cross-team decision may be deadlocked, may be irreversible at department scale, or may quietly commit the whole department. The manager of managers then usually intervenes by installing the process that will produce the answer (the criteria, the evidence required, who decides and by when) instead of supplying the answer. The intervention becomes a capability the organisation keeps.

The executive docket practice

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

Reading without gatekeeping

The manager reads design documents, and some code, to keep the map current, and is not a required approver of either. The reading turns into questions in the design room. It never turns into approvals in the pipeline.

The quarterly deep dive

Each quarter the manager picks one system or domain and goes deliberately deep into it: the design, the risks, the people who understand it, and what breaks first under load. Being shallow everywhere is not understanding. Going deep somewhere, and rotating, keeps the map honest in the places that matter.

The threshold, stated

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

Intervening as questions

When the manager does step in, they bring what was missed. "What happens to in-flight orders during the cutover?" is an intervention; "do it this way" is an override. If the question does not change the decision, the team owns the outcome and the manager owns the restraint.

The decision process, installed

When a cross-team decision is stuck or dangerous, the manager of managers sets out the process before offering any opinion: the criteria for judging the options, the evidence required, the person who will decide, and the date. Opinions come after the evidence.

The docket, written

The executive keeps a short written list of the technical decisions they own and reviews it twice a year. Everything not on it is delegated with real authority. When a docket decision is about to be made somewhere else (a differentiating capability about to be bought because one team preferred to buy it, say), the executive takes it back explicitly.

At team scope the question is when to step into a design or a fix and when not to. The manager stays close through reading and presence and owns the restraint. At organisational scope the manager stays credible at one level up. They review designs instead of code, rotate deep dives, use architecture forums and principal engineers as standing tutorials, and maintain a map of systems, risks and experts. They intervene by installing a decision process when scope, irreversibility, deadlock or a department-level commitment calls for it, and they act through their managers instead of around them. At executive scope credibility becomes structured sensing: architecture and operations reviews with evidence, principal engineers who tell the truth, and sampled raw signal that keeps the aggregates honest. Intervention becomes decision architecture, meaning the short docket and real delegation of everything else. How Judgment Scales sets out the pattern; the economics of the docket's build-versus-buy decisions are in SV-4 Engineering economics.

• Reads code and designs to stay close to how the system is evolving, without becoming a required approver. team
• Stays in the room for hard technical decisions. team
• Goes deliberately deep in one area each quarter instead of staying 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 instead of 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 can no longer reason about it. team
• Failure mode: overriding on preference. team
• Failure mode: avoiding a dangerous call to dodge conflict. team
• Failure mode: being the permanent final approver. team
• Stays credible at one remove, with design reviews standing in for code reading, rotating deep dives, architecture forums and principal engineers used as tutorials, and a maintained map of systems, risks and experts. org
• Asks the questions that expose reasoning, such as what breaks first under ten times the load, and earns a principal engineer's respect for the questions instead of 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 that of deciding, or quietly commits the whole department. org
• Installs a decision process (criteria, evidence, decider, date) before issuing an opinion. org
• Intervenes through the manager, and never 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: finding out about 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 that carry the most strategic risk, and external calibration. exec
• Keeps aggregate signals honest with sampled raw material, such as an incident review attended, a design document read or 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 during 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 resolves it. Once reading turns into gatekeeping, the closeness costs more than it buys.

Ownership versus outcome. Letting a team own a decision the manager thinks is wrong puts the outcome at risk. Overriding it puts the team's ability to decide at risk. The threshold of reversibility and cost decides which risk to take, and the failure is applying it according to mood.

Honesty versus authority. Saying "you know this better than I do" can feel like giving up standing, and pretending to understand loses it faster. Credibility at scope is built on 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 more valuable intervention. In a real emergency, the answer is.

Delegation versus strategy. Most architecture should be delegated to senior engineers, and that is mostly what the executive should do. Yet a handful of technical decisions are inseparable from company strategy and cannot be delegated without being made by default. The docket marks 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 a team is about to commit to a new event-streaming platform for a service three other teams consume. The manager supports the choice, and the team's lead engineer is enthusiastic. The platform is capable. Even so, the senior manager, who ran a similar migration on a different technology years ago, believes it is the wrong call. The operational burden will land on a team that has never run stateful infrastructure, and nobody has consulted the consumers.

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

The senior manager applies the threshold first. Is the decision reversible? Not cheaply. A streaming platform underneath a service that 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, and the consumers have not been asked. The threshold is met on scope and irreversibility, so the senior manager is right to be involved. The judgment lies in the form that involvement takes.

They do not overrule. Working through the manager, they install a decision process. The choice will be made against criteria the senior manager names: operational burden and who carries it, impact on the consumers and their consent, reversibility, and total cost including on-call. The evidence will come from a bounded two-week evaluation, reviewed at the architecture forum. The manager and the lead engineer will decide, with the leads of the consuming teams present. The senior manager is also honest about their own concern and where it comes from, including that their experience was with a different technology.

The evaluation changes the decision. The consumers raise a constraint nobody had considered, and running the platform turns out to need a platform team that does not exist. The manager chooses a managed service instead. The decision is still theirs, and a better one, and the department now has a process it will use again.

The senior manager avoids both of the comfortable options: saying nothing because it was the team's call, and saying no because they once knew this area.

• PL-1 Delegation, ownership, and decision rights: the intervention threshold as decision rights, and not taking delegated work back.
• PL-6 Leading through leaders: intervening through a manager instead of 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, in which questions develop judgment and answers do not 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, and who knows what. It is 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

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

   By raising what was missed, with a question that adds a consideration, and without overriding by 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

   The triggers are scope across team boundaries with material consequences, irreversibility at department scale, a deadlock that costs more than a decision would, 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. The manager understands every system's shape, risks and dependencies well enough 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; it is not a claim to 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, vendor lock-in on a core capability, infrastructure the product will increasingly stand on, and the security and reliability posture. Delegating them fully 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 is checked through direct exposure on a sampling basis (an incident review attended, a design document read, a skip-level with a staff engineer), and principal engineers know the executive wants the truth instead of 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.