Tech Leadership Standards

Technical leadership standards

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

Covers the decisions taken by whoever leads technically and the artifacts in which they are written down: career tracks and the real scope of each level, staff+ role archetypes, who decides what and how fast, the decision record, the design document and the design review, technical debt as a budget line, the individual conversation and performance evaluation, team sizing and its dependencies, and the resolution of technical disagreements.

Triggers: "career ladder", "level ladder", "senior/staff/principal", "IC vs. management", "staff archetype", "tech lead", "ADR", "decision record", "one-way door", "reversible", "design document", "design doc", "design review", "technical RFC", "technical debt", "refactor budget", "blameless postmortem", "1:1", "feedback", "performance review", "individual productivity metrics", "lines of code", "commits per person", "DORA per engineer", "SPACE", "cognitive load", "Team Topologies", "team size", "inter-team dependencies", "technical disagreement", "disagree and commit", "responsibility without authority".

Guiding principle: technical leadership is a set of decisions and artifacts, not a character trait. It is not evaluated by how the person is perceived, but by what exists in writing and by what the team achieves: decisions recorded with their reversibility, designs reviewed before building, interfaces between teams defined, debt with an assigned budget and people with specific, dated feedback. A falsifiable test applicable to any claim about leadership: name the artifact it produces, who reads it and which decision it changes. If it cannot be named, the claim is motivational and does not get written here.

Hard corollary: "lead by example", "foster trust" and phrases of the same genre fix nothing. They are not criteria, they are decoration. Their actionable equivalent always exists and is the only thing this document accepts: "every architecture decision lives in an ADR with declared reversibility", "the postmortem names no people and the leader defends it to management in writing".

Not applicable:

• technical-hiring-standards: reciprocal and strict. Here you decide what profile is needed, why, and which gap in the team it fills (§3.7); there how a candidate is measured — rubric, exercise format, method validity, bias, legal regime and onboarding. One-sentence boundary: leadership defines the role; the selection process is the measuring instrument.
• project-management-standards (already written): delivery, the plan, the commitment, the estimate, the risk and the stakeholders are theirs, including the record of management decisions. Here the technical decision and team development. Boundary: if the question is "when will it be ready and with what risk?", it is theirs; if it is "how is it built and who decides it?", it is ours. The decision record format is the same in both (§3.3) so as not to fork the repository.
• product-discovery-standards: what gets built and why — problem, user, hypothesis, prioritisation by value and the decision to kill an idea. Here the what is not decided.
• enterprise-architecture-standards: architecture governance for the organisation, capability roadmap and application portfolio. Here the scope is the team and its immediate neighbourhood, not the company. Reciprocal declared in their §1.
• software-architecture-patterns-standards and refactoring-tech-debt-standards (already written): the technical criteria are theirs — which pattern applies, when a module is refactored and with which technique. Here only the decision to invest in it, its budget and how it is defended (§3.5). Both already declare the reciprocal in their §1.
• microservices-architecture-standards: service boundaries and concrete contracts. Here, the organisational reflection of those boundaries (§3.6).
• code-review-standards (already written): the review criteria are theirs — what blocks, how the comment is written, what a high-risk change requires. Here only the rule that review is not used as an instrument of power (§3.8) and who arbitrates the disagreement that review does not close.
• testing-qa-standards: test strategy and gates. Here, the decision to fund it.
• sre-practice-standards: SLOs, error budget, on-call, capacity and the DORA metrics are theirs. Here, solely, that DORA is a system measure and its individual use is forbidden (§3.9, §7).
• incident-management-standards: the incident process and the blameless postmortem are theirs — roles, timeline, actions. Here what corresponds to leadership and only that: protecting the blameless postmortem when there is pressure from above to name a culprit (§3.10).
• platform-engineering-standards (already written): the platform as an internal product, its paved road, its SLOs and its adoption. Here, the decision to create the team and what load is transferred to it.
• itsm-itil-standards: service, catalogue and continuous operation.
• grc-compliance-standards: regulatory framework, formal evidence, segregation of duties.
• ai-agent-workflow-standards (already written): the team policy on coding agents is theirs — which task is delegated, instruction files, permissions, review of the diff, attribution. Here only the decision to adopt it, who pays its organisational cost and which metrics are NOT used to justify it (§3.11).
• knowledge-management-standards: where documentation lives and how it is kept alive. Here, the obligation that the decision be written down.

2. Default decisions

Verify on the web the status of the cited sources before relying on them (§8).

Sources: what is cited and with what caveat

• ✅ One-way / two-way doors. Primary source: Jeff Bezos, 2015 letter to Amazon shareholders (ir.aboutamazon.com, PDF). Verbatim (extracted from the official PDF, not from a summary): "Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don't like what you see on the other side, you can't get back to where you were before. We can call these Type 1 decisions. But most decisions aren't like that – they are changeable, reversible – they're two-way doors. If you've made a suboptimal Type 2 decision, you don't have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups." And the diagnosis that matters here: "As organizations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention." Declared discrepancy: numerous secondary sources place the framework in the 2016 letter; that is incorrect — the Type 1 / Type 2 terminology appears in the 2015 one. The 2016 one contains related material (disagree and commit), which is a different thing.
• ✅ ADR. Primary source: Michael Nygard, "Documenting Architecture Decisions", 15-Nov-2011, originally published on the Relevance/ThinkRelevance blog and today at cognitect.com. A five-section template: Title (a short noun phrase with a sequential number that is never reused), Status (proposed / accepted / deprecated / superseded by ADR-NNNN), Context (the forces at play, in neutral language), Decision, Consequences (positive and negative). Derived rule: an accepted ADR is not edited; if the conclusion changes, a new one is written that supersedes the previous one and updates its status.
• ⚠️ Staff+ archetypes. A published reference taxonomy does exist: Will Larson, Staff Engineer: Leadership beyond the management track (2021) and its origin in the open (lethain.com/staff-engineer-archetypes/, staffeng.com/guides/staff-archetypes/). Four archetypes: tech lead, architect, solver, right hand. Explicit caveat: it is a descriptive taxonomy observed in fast-growing technology companies, not a research result, and it has published criticism from practitioners (Sean Goedecke: the archetypes exist but are bad advice as a career target, because solver and right hand depend on accumulated trust and cannot be pursued directly; Alex Ewerlöf: they should not be used as job titles). Permitted use: vocabulary for distributing work and clarifying expectations. Forbidden use: turning them into levels, titles or boxes on a ladder.
• ⚠️ Team cognitive load. Original source John Sweller, "Cognitive load during problem solving: Effects on learning", Cognitive Science 12(2):257-285 (1988) — a theory of individual learning and instructional design. Its transfer to teams is from Matthew Skelton and Manuel Pais, Team Topologies (2019). Treat it as a useful analogy, not as a validated measurement, exactly as in platform-engineering-standards §6.4: team cognitive load has no measurable unit, the sum of individual loads is not a construct defined in the original theory, and DevOps academic literature points out that the book provides no scientific evidence and rests on experience and cases. It is useful for deciding how systems are distributed between teams; it is not useful as a number on a slide.
• ✅ SPACE. Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler, "The SPACE of Developer Productivity: There's more to it than you think", ACM Queue 19(1):20-48 (2021), DOI 10.1145/3454122.3454124 (also in CACM). Five dimensions: satisfaction and well-being, performance, activity, communication and collaboration, efficiency and flow. The operational rule taken from it: measure at least three dimensions at once, combining objective metrics and a survey; activity never in isolation to reward or penalise. Declared discrepancy and usage warning: the claim circulates that "SPACE measures the individual and DORA the team" — that is a misreading: one of the myths the article itself dismantles is that productivity is only individual performance, and its central thesis is that it is not captured by a single metric nor by activity data. It has not been possible to retrieve the full text verbatim (ACM Queue and CACM return 403 to automated download): the formulations above come from consistent secondary sources and must be checked against the original article before quoting them literally (§8).
• ✅ DORA as a system measure. The four metrics measure team and system delivery, not people. Report 2025: State of AI-assisted Software Development (dora.dev/dora-report-2025/, ~5,000 professionals); report 2026: The ROI of AI-Assisted Software Development (InfoQ coverage, May-2026). Caveat about the 2026 one: there is published criticism that, compared with the research rigour of previous editions, it is largely a set of speculative recommendations. Cite the edition and the year; never a bare "DORA says".

Famous figures: what is NOT used as data

This domain is saturated with numbers that circulate with no locatable primary study or with dismantled methodology. These are expressly discarded:

• ❌ The "10x programmer". Origin: Sackman, Erikson and Grant, "Exploratory Experimental Studies Comparing Online and Offline Programming Performance", CACM 11(1):3-11, Jan-1968. Methodological refutation: Lutz Prechelt, "The 28:1 Grant/Sackman legend is misleading, or: How large is interpersonal variation really?", Technical Report 1999-18, Universität Karlsruhe, Dec-1999 (page.mi.fu-berlin.de/prechelt/Biblio/varianceTR.pdf). Flaws in the original: 12 subjects, trivial tasks of a mathematical nature, and a mix of low-level and high-level language programmers in the same group, which inflates the best/worst ratio. Prechelt reanalyses a much larger dataset and argues that comparing the best with the worst is the wrong comparison: against the median of the worst quartile versus that of the best, the ratio rarely exceeds 4, and the standard deviation/mean ratio is around 0.5. Permitted use: "there is substantial interpersonal variation, of the order of 2-4x depending on the task, with overlapping distributions". Forbidden use: "10x", and above all using it to justify pay, staffing or redundancies.
• ❌ "An interruption costs 23 minutes and 15 seconds". The paper that backs it does not exist. The paper that gets cited, Mark, González and Harris, "No Task Left Behind? Examining the Nature of Fragmented Work", CHI '05, measures the probability of resuming a task on the same day and does not contain that figure. The other one usually cited, "The Cost of Interrupted Work: More Speed and Stress", finds that interrupted subjects completed the tasks faster, with more stress. The figure comes from a 2006 interview with Gloria Mark, not from a peer-reviewed article. It is not written, not even with caveats. What is defensible without a figure: fragmentation has a cost and the argument for protecting blocks of work does not need an invented number.
• ❌ "70 % of the variance in team engagement is determined by the manager" (Gallup, State of the American Manager, 2015). Proprietary analysis, not peer reviewed, with no raw data published, and with two interpretation problems that its diffusion ignores: it refers to variance between teams (it is not an individual-level claim), and the "manager effect" absorbs everything that clusters at team level (function, location, load, staffing). It is not used as data to justify a decision.
• ❌ "People leave managers, not companies" (First, Break All the Rules, Gallup). There is a published refutation from Culture Amp (2017) over 175 teams: people do leave bad managers, but it is not the first reason, and in bad organisations having a good or bad manager barely changes the decision to leave. The weak version holds ("the manager's quality is one of the factors, conditional on the organisation being decent"); the slogan does not.
• ❌ Turnover percentages attributed to a "bad manager" and the cost of a bad hire expressed as a multiple of salary (§ technical-hiring-standards): discarded for the same reason, there in detail.

General rule: a figure with no primary study, year, sample and method does not go into a document, a slide or a budget request. If the argument only stands with the figure, the argument was bad.

3. Structure and conventions

3.1 Career tracks: what actually changes

What changes when you move up a level is not "the level": it is three observable variables.

Hard rules:

1. The ladder is published. A ladder only the manager knows is not a ladder, it is a retroactive excuse. Public references exist so as not to start from zero — Rent the Runway (2015, with Camille Fournier as CTO), Dropbox, CircleCI, Square, Kickstarter, aggregated at progression.fyi and github.com/bmoeskau/engineering-ladders. They are adapted, not copied: someone else's ladder describes someone else's organisation.
2. Real parity between tracks. The individual contributor track and the management one have the same level ceiling, the same salary band and the same presence in decision-making forums. Without those three, the technical track is decorative and everyone knows it within six months.
3. Managing is not a promotion, it is a change of job. The work, the measure and the skill are different. Operational corollary: there is a declared way back, and using it is not a failure recordable in the evaluation.
4. The level is assigned on written evidence, not on seniority and not on likeability. If the evidence cannot be written down with dated facts, there is no level.
5. No level is defined by a technology. "Kubernetes senior" is not a level, it is a dependency on a tool with an expiry date.

3.2 Staff+ archetypes: what they are really for

They serve one purpose, and that is why they are here: avoiding assigning work the person cannot do from where they are. Taxonomy and caveats in §2.

Rules:

• The archetype is agreed in writing with the person and is reviewed (by default, every six months or when the project changes). A solver who gets handed the maintenance of everything they touched stops being a solver within a quarter.
• Architect and right hand only appear at a certain scale. Larson observes them emerging around ~100 and ~1,000 engineers respectively. Creating them earlier manufactures a decision layer with no problem to solve.
• FORBIDDEN to use them as titles or as levels on the ladder (§7).

3.3 Decisions: what is decided, who decides and how fast

Who decides, by default:

The ADR is an obligation, not a courtesy. Minimum rule: if a technical decision is going to condition the work of someone who was not in the conversation, it gets written. Nygard format (§2), in the affected repository, numbered and not editable once accepted.

Speed is set by reversibility, not by perceived importance (Bezos 2015, verbatim in §2):

• Every ADR carries a reversibilidad field with an explicit value. Without it, the organisation treats everything as Type 1 and grinds to a halt — the failure the 2015 letter itself describes.
• The classification can be challenged, but in writing and with an argument. "This is irreversible" is a falsifiable claim: you ask for the estimated cost of reverting it.
• A Type 2 decision that has been under discussion for three weeks already cost more than being wrong. Rule: a time box, and if it expires, the person with the responsibility decides and it is recorded.

3.4 Design document and design review

The design review is the point in the cycle where a mistake is still cheap. Afterwards there is code, dependencies, migrated data and people who have already defended it in public.

When a design document is mandatory (any one is enough):

• The decision crosses a team boundary or creates/changes an interface between teams.
• It is a one-way door (§3.3).
• It touches personal data, authentication, authorisation, cryptography or money.
• The estimated effort exceeds a threshold the team publishes (by default: two person-weeks).
• A technology the organisation does not yet operate is introduced.

Minimum template. A document without sections 5, 6 and 8 is sent back unreviewed.

# Diseño: <nombre>            Autor: <persona>   Estado: borrador|en revisión|aceptado|sustituido
1. Problema            # qué falla hoy, con evidencia observable (dato, incidente, ticket)
2. Restricciones       # plazo, presupuesto, normativa, compatibilidad, equipo disponible
3. No objetivos        # lo que este diseño explícitamente NO resuelve
4. Propuesta           # la solución, con el diagrama mínimo que la explique
5. Alternativas descartadas   # >=2, con el motivo del descarte. Sin esto no hay diseño, hay preferencia
6. Criterios de aceptación    # falsables y medibles: cómo se sabrá que funcionó, y cuándo se mira
7. Impacto             # migración, compatibilidad hacia atrás, coste recurrente, operabilidad, seguridad
8. Reversibilidad      # Tipo 1 o Tipo 2, y coste estimado de revertir
9. Riesgos abiertos    # con dueño

Review rules:

• The problem is reviewed before the solution. If the reviewers do not agree on the problem, discussing the solution is wasted time and it always ends in aesthetics.
• Mandatory pre-reading, with a deadline (48 h by default). A meeting where the document is read live is a reading meeting, not a review.
• Comments are labelled as blocking or non-blocking, just as in code review (code-review-standards). A reviewer who marks nothing as blocking has approved.
• The review ends with a decision and a date, not with "let's keep talking". The valid states are: accepted, accepted with listed conditions, rejected with a reason, or postponed with a date and with what remains to be found out.
• The accepted document becomes an ADR or links to one. A design that leaves no trace of a decision gets discussed again in six months.
• Acceptance criteria with a check date. They are revisited when due: if they were not met, that is information about how the team designs, and it is the cheapest input there is for improving.

3.5 Technical debt: a business decision with a budget

The technical criteria —what to refactor, with which technique and with which test net— belong to refactoring-tech-debt-standards (already written). Here only the decision to invest and how it is defended.

1. Debt is recorded like any other work, in the same backlog, with an owner and with the cost it imposes today — not with adjectives. Admissible formulation: "every change in the billing module requires touching four places and last quarter it generated 3 of the 7 incidents". Inadmissible formulation: "the code is bad".
2. Distinguish deliberate debt from degradation. Deliberate debt was incurred with a recorded decision and a review date (if it does not have one, it was not a decision: it was an oversight). Degradation is silent accumulation and is detected by symptom, not by opinion.
3. An explicit and recurring budget. A percentage of capacity per cycle is declared, published and protected the way a committed date is protected. A percentage that gets cancelled in the first quarter under pressure was not a budget: it was an intention.
4. How it is defended to whoever pays — and this is what always fails. Technical debt is not defended as code quality: it is defended with the cost the business is already paying, in its vocabulary. Arguments that work because they are verifiable:
   • Lead time: the same change takes X in this module and Y in the rest.
   • Reliability: the proportion of incidents concentrated in the component (incident-management-standards provides the datum).
   • Direct cost: oversized infrastructure, licences, hours of manual operation (finops-standards).
   • Risk with a name: an unsupported dependency, a version with no security patches (vulnerability-management-standards), regulatory non-compliance (grc-compliance-standards).
   • The option that is lost: what will not be doable, and when, if it is not touched.
5. A refactor request with none of those five arguments is rejected, whoever makes it. And it is rejected here, inside engineering, before the business rejects it: credibility is spent once.
6. Never "a refactor release" that delivers nothing. Debt work is delivered in increments with an observable effect; if it cannot be split, the problem is the design of the intervention, not the calendar.

3.6 The team as a system

• A single owner per system. A system with no named owner is maintained by whoever had the bad luck of touching it last. Two owners is zero owners.
• Bounded load, in the analogical sense of cognitive load (§2, with its caveat): a team answers for as many systems as it can understand, operate and improve. An operational and falsifiable test that requires no invented metric: can the team deploy, diagnose in production and explain the data model of every system it answers for, without depending on one specific person? If not, the load exceeds the team — the scope is reduced or extraneous load is transferred to the platform (platform-engineering-standards).
• Stable teams. Reorganising teams resets system knowledge and trust relationships. Every reorganisation is justified in writing with the problem it solves and its expected cost, or it is not done.
• Size: small enough that everyone knows everyone's work, large enough to sustain an on-call rota without burning anyone (sre-practice-standards fixes the latter). Adding people to a saturated team adds coordination before it adds capacity (project-management-standards §6).
• Inter-team dependencies: they are managed by interface, not by meeting. Preference, in order: (1) eliminate the dependency, (2) decouple with an interface contract and a simulator, (3) sequence with a mutual commitment from the providing team, (4) escalate. Adding a recurring sync meeting is choosing (4) and calling it (3).
• The team's structure and the system's converge (Conway). Practical consequence: if you want a different architecture, you have to change the team boundaries, not just the diagram.

3.7 Technical conflict

A technical disagreement with no procedure gets resolved by hierarchy or by exhaustion, and both produce the worst decision available. Procedure, in this order and with a deadline:

1. Make the disagreement explicit: each side writes, in one paragraph, what they defend and what evidence would make them change their mind. Whoever cannot answer the second has no technical position, they have a preference — and preferences do not block.
2. Find the datum: prototype, measurement, load test, review of a past incident. With a fixed time box agreed beforehand.
3. If the datum does not discriminate (a real tie), whoever answers for the consequences decides — normally the owner of the affected system — and it is recorded in an ADR with the alternatives and the tie declared.
4. Disagree and commit, as an explicit team rule. Reference: Amazon's leadership principle "Have Backbone; Disagree and Commit" (amazon.jobs) — the obligation to challenge the decision respectfully even when it is uncomfortable, and full commitment once it is taken. The term is older than Amazon (Intel, constructive confrontation). The local rule, which is what applies: once the decision is closed, nobody passively sabotages it or reopens it in corridors; it is reopened only with new evidence and through the same channel.
5. When it is escalated: when the disagreement crosses the boundary of two teams and blocks work for more than a week, or when it involves a security, legal or personal-data risk. Escalating is not losing: escalating late is.
6. A disagreement that repeats is an organisational design problem, not a people problem: the boundaries of responsibility are badly drawn (§3.6).

3.8 The technical leader's work that is not writing code

Their value is measured in the team's result, not in their own output. Direct consequences: if the most productive person on the team is the leader, the team is underused; if the leader is on the critical path of every delivery, they are a SPOF with holidays.

Work that is theirs, and that produces leverage:

• Unblocking: identifying who is stuck and why, and getting it out of the way. It is the highest-return activity of the job and the first one sacrificed when the leader starts programming.
• Defining interfaces between teams before two teams build against different assumptions (§3.6).
• Reviewing other people's designs and decisions (§3.4) — not rewriting them.
• Writing what the organisation will need to remember: ADRs, context, criteria.
• Creating the conditions for someone else to take the decision, and accepting that they take it differently from how the leader would have taken it if the result is acceptable. A leader who only delegates the decisions that would have matched their own has delegated nothing.
• Developing people (§3.9): it is work with a calendar, not a by-product.

The opposite trap, and it is just as real: the leader who stops touching the code loses the ability to judge. With no contact with the system, other people's estimates become uncheckable, designs get approved out of trust in the person and not because of the content, and technical debt becomes a story with no evidence. Non-negotiable operational minimum:

• Review code properly and regularly (code-review-standards), including changes they do not fully understand, which is where you learn where the system is.
• Be in the on-call rotation if the team has one, or at least take part in incident response (incident-management-standards).
• Take real work, but never on the critical path: internal tooling, fixes, tests, the task nobody wants. FORBIDDEN to take the quarter's critical feature: it turns them into a bottleneck and leaves the team without the developmental part.
• Arbitration rule between the two traps: if the team delivers just as well when the leader is away for two weeks, the split is correct. It is the only test that matters, and it can be run literally.

Code review is not used as an instrument of power. Vetoed manifestations: blocking a PR out of aesthetic preference, demanding your own solution with no technical argument, withholding approval as leverage in a negotiation unrelated to the diff. The criteria for what blocks belong to code-review-standards; the obligation that the leader does not distort it belongs here.

3.9 1:1s, feedback and evaluation

The 1:1 belongs to the report. Concrete rules:

• The agenda is set by whoever reports, and it exists before the meeting. If there is no agenda, the default question is not "how is X going?" but "what is getting in your way most?".
• FORBIDDEN for it to be a status report: the state of the work is in the management system (project-management-standards) and consulting it is the leader's responsibility, not minutes of the person's time.
• A fixed and protected cadence (weekly or fortnightly by default). Cancelling it repeatedly communicates a priority more clearly than any speech.
• Shared notes and commitments with an owner and a date. A 1:1 with no trace repeats identically for a year.
• At least once a quarter, the 1:1 is about career: current level, missing evidence, archetype (§3.2), what work needs to be sought to get there. With the published ladder in front of you.

Feedback:

• Specific, dated and about observable behaviour, not about traits. "In the review of the payments design on 12 May you closed the discussion before Ana presented her alternative" is actionable. "You are not very collaborative" is not: what cannot be observed cannot be corrected.
• Close to the event. Feedback saved for six months for the annual review is not feedback: it is an ambush, and it destroys the credibility of the whole process.
• No surprises in the evaluation. Falsifiable rule: if something appears in the annual review and it is the first time the person hears it, the failure is the leader's, and it is recorded as such.
• Difficult feedback is given in private, in writing as well as verbally, and with what is expected differently and by when.

Why individual engineering productivity metrics are counterproductive — and this is the part you have to be able to defend to management with the source in hand:

1. The published position of the sector's reference research. DORA: the four metrics measure team and system delivery and must not be used to evaluate the performance of individual engineers; applying them to people creates perverse incentives. SPACE (Forsgren et al., 2021, §2) dismantles two directly applicable myths: that productivity is activity, and that it is only individual performance; and it establishes that activity metrics are never used in isolation to reward or penalise.
2. They are trivial to game and gaming them is rational: lines, commits, PRs and points are free to inflate and the cost of inflating them is paid by someone else (the reviewer, the maintainer).
3. They measure the visible and punish the valuable: reviewing, pairing, mentoring, being on call, deleting code and preventing the unnecessary from being built leave no trace in any counter.
4. Engineering work is interdependent: attributing the result to an individual within a system with queues, dependencies and review is an attribution error, not an imprecise measurement.
5. The alternative that is used: qualitative evaluation with written and dated evidence against the published ladder (§3.1) — designs, recorded decisions, incidents resolved, people developed, systems that work without their author. It is more work for the leader. That is the cost of the job.

3.10 Incidents: what corresponds to leadership

The full process belongs to incident-management-standards. Here only the part that only leadership can do, and which is where the blameless culture breaks in practice:

• Protecting the blameless postmortem when there is pressure from above to name someone. The pressure is real and arrives in the form of a reasonable question ("who deployed it?"). The standard answer, in the same language as whoever asks: the system allowed an individual error to reach production; that is the defect and that is what gets fixed, because it is the only one that will not recur. Replacing the person leaves the system identical for the next one.
• Verifiable drafting rule: the postmortem contains no proper names as a cause. If "X ran Y" appears, it is rewritten as "the procedure allowed Y to be run without confirmation".
• Honest contraindication: blameless does not mean without responsibility. Repeated negligence, knowingly bypassing controls or acting without authorisation are a conduct matter and are handled outside the postmortem, through another channel and with HR. Mixing them destroys both.
• The postmortem's actions get funded. A postmortem whose actions do not enter the next cycle's plan teaches the team that the exercise is theatre, and from then on postmortems are written to be filed.
• The leader publicly owns the team's failure and publicly attributes the success. It is a conduct rule with a verifiable effect: without it, nobody reports a problem early.

3.11 Coding agents: what leadership decides

The concrete policy —which task is delegated, instruction files, permissions, review of the diff, attribution— belongs to ai-agent-workflow-standards. **Here, three

…(truncated)