The first time someone said "Awareness, Pause, Reframe" out loud, I almost laughed.
It was in McKinsey's Forward Program, in the Adaptability & Resilience session, and APR was presented as the module's big takeaway: notice your reaction, interrupt it, pick a better story. Three words on a slide. It smelled like the kind of thing that works for people with corner offices and does not work for someone whose production deploy broke at 11pm.
I took the workshop seriously enough to finish it. I did not take APR seriously enough to use it. For a few weeks it lived next to the other good advice I ignore.
Then it got tested three times, by my own work, without me noticing I was running it.
The code review I wanted to answer in four minutes
I had an open-source PR up, tests green, and a maintainer came back with a review that essentially said: your title says you're preferring one option, but your code excludes everything the detector doesn't recognize. When the detector has a gap, users get nothing at all.
My first reaction was instant and physical: a hot, defensive "but it passes, and here's why I did it that way." I had the rebuttal half-written. That was Awareness, except I only recognized it afterward: jaw tight, already composing, treating his comment as an attack on the work rather than information about it.
The Pause was not zen. It was just not hitting reply, because it was late and I was annoyed, and nothing good comes from going through review feedback while angry.
The Reframe happened the next day, when I actually read his argument instead of my defense of it. He wasn't saying my code was bad. He was saying my gate could take away a dev command from a project whose framework we don't recognize yet, and silence is worse than a slightly wrong answer. Correct framing, terrible first reaction. I rewrote the fix as a ranking with a fallback, added the test he asked for, and wrote back agreeing with him.
The uncomfortable part: if APR had been on the slide and nothing else, my four-minute reply would have been public, wrong, and the kind of thing that makes an OSS contributor memorable for the wrong reason.
The 2am version: when the model is confidently, elaborately wrong
The second test is the one that actually changed how I build.
Every agent project I've shipped eventually hits the same wall. The model produces a diff that looks right. The failure message looks right. It explains what it did with total confidence. And it's wrong, not in some exotic way, but in a way a human reviewer would catch in ten seconds.
My old reaction to that was frustration aimed at the model: it's dumb, it hallucinated, prompt harder, add more context. That reaction is Awareness without Reframe. You're just re-describing the trigger with extra vocabulary.
The reframe that mattered: the model isn't the failure here, my harness is. If the only verification is a model saying it worked, then confident and correct are indistinguishable, and no amount of prompting fixes that. So I stopped treating the model's self-assessment as evidence and started gating on things that can't be talked into passing: tests, types, lint, and for code that runs in Docker, the container's exit code. My sandboxing agent terminates its debug loop on an exit code for exactly this reason.
That's Reframe doing real work. The facts didn't change. The reading changed from "the model failed" to "my system has no ground truth," and only one of those is fixable by me that night.
Where APR showed up before I had the words for it
The third one isn't dramatic. My most-downloaded package exists because of a bad reaction I didn't have.
My own agent kept choking on attachments: PDFs, notebooks, DOCX, images, archives. It would guess at content it couldn't read, and guess confidently, which is the worst combination. The reaction I felt was pure irritation at the tool. The reframe I apparently made without labeling it: this isn't an annoying bug, it's an unwritten package. Someone should turn those formats into clean text an agent can actually read. I built it, it shipped, and people download it.
Looking back, that's the same three moves as the PR review. Notice the heat, don't act at the peak of it, then find a reading of the situation that ends in something I control. APR just gave me a name for a sequence I was already running badly and inconsistently.
What I'd change about how they teach it
Since the workshop I went and read around the topic properly, because I've always been suspicious of frameworks that only exist on the slide where they were taught. Two things I'd push on:
They teach it as reflection. Engineers need it as a loop. Reflection is something you do at the end of the day about something that already happened. The failures I care about happen in the next four minutes: the reply, the commit, the rollback decision. APR only pays at the moment of trigger, which means it needs a forcing function, not a reminder. Mine is that any reactive message or commit gets written, then sits for ten minutes. Drafting is free. Sending isn't.
Reframe is the step people quietly skip. Pausing feels productive, so you pause. Reframing feels like work, so you spin instead. The test I use: if my "reframe" doesn't produce a different next action, I didn't reframe anything, I just calmed down. In the PR case the different action was rewriting the fix. In the harness case it was adding a deterministic gate. Calm without a new action is just a nicer version of the original reaction.
What I actually took away
APR is Awareness, Pause, Reframe: catch the reaction while it's still a reaction, insert a gap mechanical enough that you can't skip it, and pick an interpretation that ends in an action you control rather than a story you rehearse.
It's still three words on a slide. The difference is I've now watched it fail in the exact situations it was designed for, which is the only endorsement I trust. My defensiveness on that PR review didn't disappear. It just got a ten-minute delay and a better ending.
If you've done the McKinsey Forward Program, I'd genuinely like to know whether APR landed for you the same way, or whether it took your own version of a code review to make it stick.
Thanks for reading. If this resonated, you can find me on GitHub and on my site. I write about agents, open source, and the parts of engineering that don't show up in a diff.
Top comments (1)
Applying a framework to concrete habits makes it more credible than a generic productivity recap. The follow-up I would want is one measurable before/after loop: a trigger, a replacement behavior, and a weekly metric. Otherwise reflection can feel useful without changing the work.