how the four-r loop turns good engineers into fearless communicators
TDD for humans interaction
Think back to the last meeting that left you uneasy. Perhaps it was a sprint-planning session where you nodded along even though the estimates felt wildly optimistic, or a code-review discussion in which you clicked “LGTM” while silently muttering, “This will page us at 2 a.m.” In that gap between what was said and what was thought, live most of the problems that slow teams down and fray relationships.
Douglas Squirrel and Jeffrey Fredrick, in Agile Conversations, propose a simple routine for closing this gap: Record → Reflect → Revise → Role-play. The routine builds on two tools we have already explored: Chris Argyris’s Left-/Right-Column (for capturing speech versus thought) and the Ladder of Inference (for exposing how quickly we jump from raw data to belief).
Today, we will walk through the Four-R loop step by step and explain why the last two steps, Revise and Role-play, are the difference between knowing the theory and changing real-world outcomes.
RECORD - freeze the moment
Imagine you have just finished a backlog-grooming call. You felt rushed but said nothing. Before the details fade, open a blank page and draw the classic vertical line. On the right, reconstruct the literal dialogue. On the left, put the thoughts you never voiced.
Nothing fancy: three exchanges, thirty seconds of memory, and brutal honesty about what passed through your head. That is all the raw material you need. If you don’t have a fresh one, use one that sits in your mind and you can’t let it go for some reason.
REFLECT - watch yourself climbing the ladder
Now, reread the page as if you were holding a debugger against your mind. Notice how, the moment you heard “three points,” you sprinted up the Ladder of Inference: interpreted meaning (“scope pressure”), made an assumption (“they're ignoring database migration”), and drew a conclusion (“they’ll blame us”). You can also see that your spoken words never carried your hidden concern about the migration risk.
A helpful prompt while reflecting is to ask, “What did I need the other person to understand that never made it out of my mouth?” In the fragment above, the answer is obvious: “This story hides an invisible database migration and therefore a serious schedule risk.”
REVISE - write the dialogue you wish you had
Take another paper or open another note in your note-taking app of choice. Keep the same setting, but let yourself speak plainly. The goal is alignment: your right-column words must finally reveal your left-column concerns.
You have not attacked anyone. You have surfaced data, named the risk, and invited the PM into the evidence. In other words, you refactored the interface to match intent and behaviour.
Why is revision crucial? Knowing you are held back does not teach your nervous system what to do next time. Writing alternative sentences gives your brain a concrete path to follow under pressure, precisely what TDD does for code.
ROLE-PLAY - put your words under load
A script that looks perfect on paper/laptop can still misfire in real time. Tone, tempo, even a raised eyebrow, changes the message. Stand up, read your new lines aloud, and feel for friction. Better yet, enlist a teammate: you play the PM while they read your part, then swap roles. Notice how you react to words you suppose to say… do they feel right?
You might discover that “I want to flag” sounds confrontational during the first read-through. You tweak it to “There’s a piece of work we haven’t estimated yet.” On the second pass, you notice you speak too quickly when nervous; a deliberate breath before “If we include that…” calms the delivery. After three or four iterations, the conversation travels smoothly from page to voice, and you are ready to use it in the real world.
Role-play is to dialogue what a staging environment is to software: the cheapest, safest place to expose defects before deployment. Skip it and you risk shipping untested behaviour into production - the behaviour, in this case, being your own mouth.
why the loop matters
If this looks like preparing a conference talk, that is because the mechanics are the same. Great presenters do not wing it; they iterate on slides (Revise) and rehearse onstage until every pause and emphasis lands (Role-play). Conversations deserve equal craftsmanship because they steer architecture, culture and ultimately the success of the people who build our systems.
Another quick example: the 1-on-1 raise request
• Record: Right column: “I’ve enjoyed the last year.” Left column: “If I don’t ask for a raise soon, I’ll resent this place.”
Reflect: You implied satisfaction but hid urgency and assumed your manager should know market rates.
Revise: “I’ve enjoyed the last year, and I’d like to discuss aligning my compensation with current staff-engineer benchmarks. Here’s the data I’ve gathered - can we review it together?”
Role-play: Practice with a friend. You discover your voice shakes on “compensation”; you slow down, add a sip of water there, and the sentence comes out steady.
Different setting, same mechanics.
working this into a busy engineer’s week
Yes, we are all busy, but practice makes perfect…
Pick only one conversation per week; a 30-minute calendar block.
Keep templates in your note-taking tool.
Pair up with another staff member or principal; five-minute role-play at the tail of a 1-on-1.
Review every quarter: Which conversations still slip? Adjust
summary
The Four-R loop is essentially a unit test for conversations. You capture reality (Record), inspect the failing test (Reflect), patch the code (Revise), and run the suite in a harness (Role-play) before pushing to prod.
Like with every tool, don’t get caught up in common pitfalls:
Perfectionism – aim for “better,” not Oscar-winning prose.
Skipping role-play – reading silently ≠ , experiencing real-time stress.
Treating it as post-mortem only, the loop also shines before high-stakes meetings.
Before we finish, choose one interaction from the past seven days that still bothers you. Spend ten minutes writing the Left-/Right-Column, another ten revising it, and five reading it aloud - ideally with a peer. When you finish, tell us what happened:
Which hidden assumption surfaced?
How did the words change once they left the page?
Drop a comment; your insight may be the real-world example that helps the next reader.
If this exercise moves even one conversation from tension to clarity, forward the post to a teammate who thinks “soft skills” are fluff. Invite them to run the loop with you; the experiment might transform not just your next meeting but every technical decision that follows.
Next time, we’ll zoom in on Reflect and start building a set of tools that will help us create even better conversations. Until then, grab a sheet of paper and start writing - your future conversations are waiting.