Overview

The job changes from personally solving problems to building a team that solves them -- the new scarce resource is other people's judgment, not the manager's own output. It's hard to unlearn because the exact IC behaviors (personally shipping, personally fixing) were rewarded for years and don't disappear automatically just because a title changed.

The report's items are listed and worked through first; any manager item is explicitly added only after the report's own agenda is exhausted -- not a status update the manager runs top-to-bottom.

Situation, Behavior, and Impact -- a specific event, an observed (not inferred) action, and its stated effect. It must avoid trait or character language ("you're careless") in favor of behavior language ("in this situation, this specific thing happened").

A coaching response supplies only questions, no answer; scan it for any sentence stating what the report should do -- if one exists, it's directing, not coaching.

An observable behavior tied to a competency-ladder rung -- not a vague trait like "needs more leadership presence."

It cites the ladder's own stated behavior text verbatim as the standard being checked against, not a manager's subjective paraphrase of what that behavior means.

Every comparative claim cites ladder-level evidence for each person, not a relative popularity impression like "I like both, X edges out Y."

It must contain the what and the why (including the real constraints); it must omit the how. A reader unfamiliar with the manager's own private reasoning should still be able to reach the same decision from the brief alone.

Every blocked item has a named owner -- the manager personally, a delegate, or an escalation target -- and a one-sentence reason for that specific ownership choice.

The options considered, the trade-off made, the decision, and the communication plan (who gets told what, and when).

Originally four keys (deployment frequency, lead time, change-failure rate, time-to-restore), now formalized by Google Cloud's DORA program as a five-metric throughput/instability model. A recommendation should tie directly to the specific metric that's weak, not a generic "let's move faster" applied regardless of which number is actually the problem.

A stated product or business outcome, with its trade-off stated explicitly -- not presented as obviously, uncontroversially correct.

It states the specific cost, risk, or dependency being represented, not a vague, unquantified technical objection like "this is risky."

A reader who wasn't in the room can state, in their own words, what was gained and what was given up.

The specific safety failure (why the information didn't surface sooner) and one concrete, recurring mechanism that would change it -- not a one-time announcement or exhortation.

Specific observed evidence from the interview loop -- not an unstructured overall impression like "I really liked them."

A shared incentive the other party already holds -- not an appeal to the requester's own authority or urgency.

Conway's Law, and the predicted resulting system-boundary shift -- not merely the org-chart shift.

The specific mechanism (not just a stated intention) that keeps the ritual running once its original owner leaves -- for example, a rotation tied to an existing shared calendar.

The specific bottleneck the manager's own hands-on work created, and one concrete habit change to correct it.

A report-owned recurring channel (co-02). An open-ended, ambiguous invitation puts the entire burden of initiating on the report; a dedicated, recurring, report-owned 1:1 removes that ambiguity by existing on the calendar regardless.

No situation or specific behavior is named (co-03) -- the report can't tell which exact action to repeat. "You handled the multi-currency edge case cleanly last sprint" tells the report something concrete; "you're doing great" doesn't.

Always directing, never coaching (co-04) -- the engineer never practiced the underlying reasoning, so nothing about diagnosing this class of problem actually transferred.

Replace the vague trait with an observable behavior cited from the competency ladder's own text (co-05, co-06) -- for example, "proposes a design approach before coding and defends a trade-off in it."

A shared competency ladder with quoted behavior text (co-06), cited as evidence in a calibration note (co-07) -- without it, the debate has no shared standard to resolve against.

The manager's (co-08) -- the brief lacked the what, the why, and the real constraints, so the engineer had no way to reach a decision compatible with reasoning they were never given.

A stewardship/triage habit (co-09) that surfaces cross-person blockers as they happen, rather than only discovering the pattern in retrospect.

An explicit, communicated prioritization record (co-10) -- the options, the trade-off, the decision, and who was told what, written down instead of decided silently.

Don't recommend "deploy more often" (co-11) -- a 25% change-failure rate means the team's real problem is shipping safety, not throughput; pushing frequency without fixing safety would make the weak metric worse, not better.

A stated technical strategy (co-12) naming a small number of deliberate bets tied to outcomes -- without it, the system's shape is still being decided, just through a hundred unexamined defaults.

Name the specific cost, risk, or dependency in comparable terms (co-13) -- a vague, unquantified objection gives product nothing concrete to weigh against their own priorities.

A legible trade-off communication made upfront (co-14) -- stakeholders who don't understand what a decision cost tend to assume it cost nothing.

Some earlier moment (often small, often unnoticed by the person who caused it) where raising a similar concern was met with dismissal (co-15) -- setting an unspoken norm that speaking up again wouldn't be welcome.

The risk: the evaluation is dominated by whichever interviewer's gut impression is loudest or speaks last, and by similarity bias (co-16). The fix: a structured scorecard where every score cites specific observed evidence from the loop.

A named shared incentive (co-17) -- the peer team has no reporting obligation and no stated reason of their own to prioritize the ask; naming what they already gain from it would give them one.

A Conway's Law prediction (co-18) made before committing to the reorg -- naming, in advance, which system boundary the new team-communication structure would harden, so the coupling would have been a deliberate, accepted choice instead of a surprise.

After: "1. Anything blocking you right now? 2. Anything on your mind about the work or your own growth? 3. Anything you want feedback on? [Manager's items, added only after the above is covered]: 4. One thing I want to flag this week."

Root cause: co-02 requires the report's items to lead the agenda; the "before" version starts with the manager's own status check, quietly training the report that this meeting belongs to the manager, not to them.

After: "Situation: Tuesday's currency-service deploy. Behavior: you paused the rollout and traced a rounding discrepancy before it shipped. Impact: that prevented a customer-facing invoice bug."

Root cause: co-03 requires a specific situation, behavior, and impact. "Nice work" gives the report nothing to consciously repeat next time something similar comes up.

After: "Gap: doesn't yet propose the technical approach before starting work -- waits to be told the design. Next-level behavior (per the ladder): 'proposes a design approach for a multi-day task before writing code, and can defend a trade-off in it.'"

Root cause: co-05 and co-06 require every gap to map to an observable, ladder-quoted behavior. "Show more ownership" gives the report nothing concrete to start doing differently.

After: state the what (stop the round trip), the why (the latency budget and where it's being spent), and the real constraints (staleness tolerance, no new infra dependency) -- leave the specific caching mechanism for the engineer to choose.

Root cause: co-08 requires the how to stay deliberately unspecified. The "before" version dictates the exact mechanism, which defeats the point of delegating the decision at all.

After: add the options considered, the specific trade-off made, and a stated communication plan -- who (product, the team) gets told what, and when.

Root cause: co-10 requires all four elements. A bare decision with no stated options or communication plan gets re-litigated the first time someone asks why, because nothing explains the reasoning or who was supposed to already know.

After: identify which specific metric is weak (for example, lead time, driven by a 4-day PR review turnaround) and recommend a fix targeted at that specific bottleneck (a same-day review SLA).

Root cause: co-11 requires the recommendation to tie to the specific weak metric. A blanket "move faster" risks re-optimizing metrics that were already healthy while leaving the real bottleneck untouched.

After: score each role-specific signal separately, citing specific observed evidence from the loop for each -- for example, "systems-design judgment: 4, caught a hot-partition risk unprompted in the design round."

Root cause: co-16 requires every score to cite specific observed evidence. An unstructured "I really liked them" is dominated by whichever interviewer speaks first or most confidently in the debrief.

After: name Conway's Law explicitly and state the predicted system-boundary shift -- for example, the currently informal internal event format will harden into a versioned, contract-tested API within two quarters, because two separate teams can no longer coordinate an informal change with a same-day message.

Root cause: co-18 requires the memo to name Conway's Law and predict the resulting system boundary. A headcount-only justification misses the technical consequence the reorg will actually have.

A team's capacity is always finite, and every competing demand (Worked Scenario 10's dashboard feature, ETL rewrite, and on-call load are all genuinely real) can't be fully addressed simultaneously. Leadership here means making the trade-off explicit and chosen -- naming exactly what's being deferred and why -- rather than pretending all three can be done at once. Calling that a "failure" mistakes the existence of a trade-off for evidence of a bad decision; the actual failure would be making the same trade-off silently, with no stated reasoning.

Waiting for certainty before deciding isn't more rigorous -- it's a different, often more expensive way of avoiding the decision. Rigor here means anchoring the judgment to the best available evidence (a ladder's stated behavior text, an interview loop's specific observed evidence, a DORA metric's actual weak point) and stating it explicitly, not achieving certainty that leadership decisions never actually have available. The discipline is honest, evidence-anchored judgment under uncertainty, not false confidence dressed up as certainty.

The pull toward hands-on work never fully disappears, because it's the exact reflex that made the manager a strong engineer in the first place, and every high-pressure incident re-creates the temptation to just fix it personally rather than coach through it. Treating it as "solved" after one good habit-change memo (Worked Scenario 8) ignores that the next Thursday-morning incident applies the same pressure again -- the discipline is catching the slip each time it recurs (Worked Scenario 9), not assuming one memo makes the reflex permanently go away.

Fully directing the how wastes the report's own judgment and keeps the manager as the bottleneck on every decision of that class; stepping back with no context at all leaves the report unable to make a decision compatible with reasoning they were never given, and produces either paralysis or a confidently wrong call. Retaining the what and why while delegating the how is the specific split that lets someone else make the same call the manager would -- policy (the goal, the constraints that matter) stays set centrally; mechanism (the specific implementation) is where local judgment adds the most value.

A reorg is, on its surface, a policy-level decision about who reports to whom and how teams are grouped. Conway's Law states that this policy choice mechanically determines how the system itself ends up structured, because a system's architecture tends to mirror the communication structure of the organization that built it (Worked Scenario 21's predicted Ingestion/Serving boundary hardening). Treating org design as purely a headcount or reporting-line exercise ignores that it is simultaneously making a technical architecture decision, whether or not anyone intended it to.

A manager has no mechanism-level control over a peer team -- no reporting line, no ability to assign their work. The only lever available is policy-level: showing the peer team that their own already-existing goals (Worked Scenario 18's Data Science team already wants fewer pages) align with the requested change. Naming the shared incentive works because it doesn't require any authority at all -- it simply makes visible an alignment that was already there, which is the only kind of influence available when mechanism-level control is absent by design.