A junior on your team has been shipping screens straight out of Figma's First Draft button, lightly retouched, and nobody caught it until one of them reached a stakeholder review with a destructive action sitting in the wrong place and an empty state full of placeholder copy. This is the moment that tests whether you are a senior IC or just a fast one. The wrong move is to take the work away, fix it yourself, and let the junior infer they failed - which protects this one deliverable and quietly ends their growth. The right move is harder: intervene firmly enough that the unchecked work stops today, gently enough that the junior's confidence survives, and structurally enough that they leave the conversation with a verification rubric they can run themselves so the intervention never has to happen twice. This lesson plays out that coaching scenario and gives you two artifacts: a one-on-one coaching memo that conducts the intervention without breaking the person, and a junior verification rubric they can run on their own AI output so the standard becomes theirs, not yours.

Why This Is an Escalation, Not Just a Correction

A correction is "this button is in the wrong place." An escalation is "the way you are working will keep producing buttons in the wrong place, and we have to change the way you are working." The First Draft problem is the second kind, and treating it as the first is the most common mistake a senior makes. If you only fix the destructive action, you have corrected one screen and left intact the workflow that generated it - shipping First Draft output without a verification pass - which means next week there is another misplaced action, another placeholder empty state, another conversation. The defect is not in the screen. The defect is in the workflow, and an escalation is the recognition that a workflow problem cannot be solved at the artifact level.

This is also why it has to be you, the senior IC, and not a process document or a Slack reminder. A junior shipping unchecked First Draft output is not being lazy; they are usually doing exactly what they think the job is - the button generates a screen, the screen looks finished, they retouch it and ship it, and at no point did anyone show them the gap between "looks finished" and "is finished." That gap is the entire content of L1 of this program, and the junior may simply never have been taught it. The escalation is where a senior transfers that understanding, which is a human act of teaching, not a policy enforcement. Pulling someone off a workflow is one of the most delicate things a senior IC does, because done badly it reads as "you are bad at your job" and done well it reads as "I am going to make you better at your job," and the difference is almost entirely in how you conduct it.

The First Mistake: Fixing It Yourself in Silence

The strongest pull in this moment is to just fix it. You can see the three errors instantly, the review is in an hour, and correcting them yourself is faster than explaining them. So you quietly redo the screen, ship it, and say nothing or say "no worries, I cleaned it up." This feels kind and efficient. It is neither. It is the single most damaging thing you can do, for three compounding reasons.

First, it teaches the junior nothing, because they never see what was wrong - the screen just got better by magic, and the lesson they learn is "a senior will catch my mistakes," which is the opposite of the self-sufficiency you are trying to build. Second, it does not scale: you have now signed up to personally inspect every piece of AI output the junior ever ships, forever, which is unsustainable the moment the team is larger than two people. Third, and most corrosively, "I cleaned it up" with no further conversation often lands worse than a direct critique, because the junior knows something was wrong, does not know what, and now feels both incompetent and confused - the confidence damage happens anyway, minus the learning that would have justified it. Silent fixing gets you the worst of both worlds: the junior's confidence takes the hit and they get none of the growth. The escalation exists precisely to invert that trade.

If you only fix the screen, you have corrected one artifact and left the workflow that produced it fully intact. The defect was never in the button placement. It was in shipping generated output without a verification pass - and you cannot fix a workflow at the artifact level.

The One-on-One Coaching Memo

The coaching memo is the structured form of the intervention, and the reason to write it rather than wing it is that an improvised hard conversation under time pressure almost always tilts toward one of the two failure modes - too soft to change the behavior, or too blunt to preserve the person. A memo forces you to plan both. It is not a document you necessarily hand over verbatim; it is the structure you walk through in a real conversation, written down so you do not lose the thread when the moment gets emotionally charged, as it will.

Lead With the Work, and With What Is Working

The memo opens by separating the person from the workflow, explicitly and early, because the junior's first fear is "am I about to be told I am bad at this." Defuse it immediately: name something real that is working ("your visual instincts are strong - the type and color choices on these were genuinely good"), then locate the problem in the workflow, not the talent ("the issue is not your design eye, it is that the workflow skipped a step"). This is not flattery and it is not a compliment sandwich, which juniors see through instantly. It is an accurate statement that the problem is fixable and located in a process, not in them - which is true, and which is the thing that lets them hear everything that follows without their defenses up. A junior whose confidence is intact can learn; a junior who thinks they are being told they are untalented goes into self-protection and learns nothing.

Show the Specific Gap, Concretely

Then you show them the actual errors, specifically, on the actual screens, because vague feedback ("be more careful") teaches nothing and specific feedback teaches everything. Walk through the three errors: "This is a destructive action in the position users expect a safe one - here is why that is dangerous. This empty state still has placeholder copy, which means the generated output was shipped without a content pass. This focus ring is missing, which is a First Draft default it does not add." Naming each error and its category does two things: it makes the problem concrete and fixable rather than a vague sense of failure, and it begins teaching the vocabulary the junior will need to catch these themselves. You are not just listing what is wrong; you are showing them how to see, which is the actual deliverable of the conversation.

Name the Workflow Change, Not Just the Fixes

Crucially, the memo does not stop at the three fixes. It names the workflow change: "Going forward, nothing generated goes to review without running a verification pass first - and I am going to give you the exact rubric to run, so this is a thirty-second checklist, not a vague instruction to be careful." This is the line that converts a correction into an escalation. It tells the junior that the expectation is not "make fewer mistakes" (impossible to act on) but "run this specific check every time" (entirely actionable), and it pairs the new expectation with the tool to meet it, so the junior leaves with a path forward rather than just a verdict. A memo that names the problem without providing the rubric is a complaint; a memo that provides the rubric is coaching.

The Junior Verification Rubric

The rubric is the artifact that makes the whole intervention self-terminating, because its entire purpose is to externalize your judgment into a checklist the junior can run without you. The day the junior can catch their own First Draft errors is the day you never have to have this conversation again, and the rubric is how you get there. It has to be short enough to actually run every time - a rubric nobody runs because it takes twenty minutes is worse than no rubric - and specific enough that running it reliably catches the errors that triggered the escalation.

The rubric is a small set of checkable questions the junior runs on any AI-generated screen before it leaves their hands. Drawn from the failure modes First Draft and similar tools reliably produce: One primary? Is there exactly one primary-weight action, and is it the most important one? Destructive actions safe? Does every data-changing or destructive action look and sit like its consequence, never in the reflex position of a safe one? Real content, real states? Is the placeholder copy replaced, and do the empty, error, and loading states exist? Tokens, not hardcodes? Are the colors, spacing, and type pulled from the design system rather than the generator's defaults? Focus and target size? Does every interactive element have a visible focus ring and a 24-by-24 minimum target? Survives the phone? Does the layout hold at a mobile breakpoint? Six questions, ninety seconds, every screen. The junior runs it, and the screens that used to need your intervention now pass before they reach you.

The rubric does something subtler than catch errors, too: it transfers ownership of the standard. When the junior runs the rubric themselves, the verification becomes their discipline rather than your surveillance, and that shift - from "the senior checks my work" to "I check my work" - is the entire developmental goal. A junior who runs the rubric is not a junior being watched; they are a junior who has internalized the standard, which is exactly the person who becomes a senior. The rubric is a teaching instrument disguised as a checklist.

Conducting the Conversation Without Breaking the Person

The memo and rubric are the content; the conduct is what determines whether the intervention lands as support or as a blow. A few principles separate a coaching conversation from a dressing-down. Hold it privately and promptly - privately because critique in front of peers turns a learning moment into a humiliation, and promptly because letting unchecked work pile up before you address it makes the eventual conversation about a pattern rather than a teachable instance, which is harder for the junior to absorb. Frame the whole thing as an investment, not a verdict: the subtext the junior should hear is "I am spending this time on you because I think you are worth developing," which is both true and the thing that makes the hard parts survivable.

Be honest about the trap they fell into, because it is not their fault in the way they fear. The tools are explicitly designed to make generated output look finished - that is the product - and the gap between looks-finished and is-finished is invisible until someone teaches you to see it. Telling the junior "you fell into a trap the tool is built to create, and almost everyone does the first time" is both accurate and disarming; it relocates the failure from their character to a predictable, nearly universal mistake, which is exactly where it belongs. And end the conversation forward-facing: not "don't let this happen again," which is a threat, but "run the rubric, come to me when something on it is ambiguous, and in a month you will be catching things I miss" - which is a promise of growth and an open door. The junior should leave the room more confident than they entered, not less, because they now have a concrete tool and a clear standard where before they had only a vague sense that they had failed.

When the Junior Pushes Back, and When You Hold the Line

Sometimes the junior pushes back - "but the deadline was tight and the screen looked fine" - and how you handle this is a test of whether the escalation was real. The pushback is usually true and beside the point: yes, the deadline was tight, and yes, it looked fine, and that is precisely the problem, because looked-fine is the trap and tight-deadlines are exactly when the rubric matters most. Acknowledge the truth in their point ("you're right that it looked fine, and that is the whole danger - the tool is good at making things look fine") and then hold the line on the standard ("which is why the rubric is not optional even under deadline; ninety seconds is the cost of not shipping a misplaced delete button to a customer"). You are not winning an argument; you are teaching that the standard does not bend to deadline pressure, because the moment it does, it only ever gets skipped under exactly the pressure where it matters most.

The harder case is the junior who keeps shipping unchecked output after the conversation and the rubric. Then the escalation escalates: it stops being a coaching question and becomes a performance one, and a senior IC has to be honest about that boundary rather than coaching the same conversation in a loop. But that is the rare case. Far more often, a junior who is shown the gap, handed the rubric, and treated as worth developing closes the gap fast, because most juniors shipping unchecked AI output were never taught the verification step and are relieved to finally have it. The escalation, done well, is not a punishment that damages a career; it is the conversation that converts a junior who presses buttons into a designer who verifies - which is the whole point of having senior ICs on a team at all.

Why This Skill Defines the Senior IC

This is the last lesson of the level for a reason. Everything before it - the workflows, the provenance log, the disclosure scripts - was about operating yourself at senior quality without supervision. This lesson is about the thing that actually makes you senior, which is extending that quality to the people around you without a manager title and without breaking them. A senior IC is not just a person who does excellent work; they are a person whose presence raises the quality of everyone's work, and the escalation pattern is the most concentrated form of that. When you pull a junior off an unchecked workflow and hand them a rubric they can run themselves, you have not done their work for them and you have not let bad work ship; you have made them permanently more capable, which is the only intervention that scales.

The provenance log, the disclosure scripts, and the verification rubric are all the same kind of object, which is why they cluster at the end of this level: they are the internal safety systems a senior IC builds because there is no longer a supervisor to be the safety system. The difference with the rubric is that you are building it for someone else, and teaching them to run it, which is how the safety system propagates beyond you. That propagation - turning your individual discipline into a standard the whole team holds - is what a senior IC is for, and it is the capability this entire level has been building toward. The junior who learns to verify their own AI output from a rubric you handed them is your work too, and it is the most durable work you will do.

Key Takeaways

• This is an escalation, not a correction. Fixing the misplaced button corrects one screen and leaves the defective workflow - shipping First Draft output without a verification pass - fully intact. You cannot fix a workflow at the artifact level, so the intervention has to change how the junior works, not just what they shipped.
• The worst move is fixing it yourself in silence. It teaches the junior nothing (the screen improves by magic), does not scale (you now inspect everything they ship forever), and damages confidence anyway ("I cleaned it up" leaves them feeling incompetent and confused). Silent fixing gets the confidence hit with none of the growth.
• The coaching memo leads with what is working and locates the problem in the workflow, not the person (defusing the "am I bad at this" fear), shows the three errors specifically with their categories (teaching the junior to see), and names the workflow change paired with the rubric. A memo that names the problem without the rubric is a complaint; with the rubric it is coaching.
• The verification rubric makes the intervention self-terminating: six checkable questions (one primary, destructive actions safe, real content and states, tokens not hardcodes, focus and target size, survives the phone) the junior runs on every AI screen in ninety seconds. It transfers ownership of the standard from your surveillance to their discipline - the shift from "the senior checks my work" to "I check my work" is the developmental goal.
• Conduct it privately, promptly, and as an investment not a verdict. Be honest that the tool is built to make output look finished and almost everyone falls for it the first time, which relocates the failure from character to a near-universal trap. End forward-facing ("run the rubric, in a month you'll catch things I miss"), so the junior leaves more confident than they entered.
• When the junior says "it looked fine and the deadline was tight," acknowledge the truth and hold the line - looked-fine is the trap and tight deadlines are when the rubric matters most. The escalation done well converts a junior who presses buttons into a designer who verifies, which is the most durable and scalable work a senior IC does and the capability this entire level builds toward.