Bernice McCarthy's four-question model for teaching and presenting anything without losing the room: why it beats a straight how-to, how the wheel cycles Why, What, How, and What If, and how to use it for RFCs, tech talks, and onboarding docs.
Picture a design review. An engineer opens with a system architecture diagram, walks through three services and a message queue, then spends ten minutes on configuration flags. By slide six, half the room is on their laptop. Nobody asked what problem this solves, or why the current setup was worth replacing in the first place. The engineer did nothing wrong technically. They just started at "how" and never went back for "why."
This is the exact failure mode Bernice McCarthy set out to fix, thirty years before anyone called it a "tech talk."
McCarthy was a classroom teacher in the late 1970s who noticed something teachers still notice today: the same lesson lands for some students and loses others, and it isn't about intelligence. Some students needed to know why a topic mattered before they'd engage with it. Others wanted the facts first. Others wanted to get their hands on the material immediately. A few only cared once they could bend the idea into something new.
Rather than picking one style and hoping it worked for everyone, McCarthy built a model that moves through all of them in sequence, every time: 4MAT. The name is short for the four questions that structure it: Why, What, How, and What If. Cycle through all four, in order, and you engage every kind of listener instead of just the ones who think like you.
Why is the meaning quadrant. Before anyone absorbs a fact, they need a reason to spend attention on it. This is where you connect the topic to something the audience already feels: a cost they're paying, a risk they're carrying, a frustration they recognize. Skip this step and you're asking people to care about a solution to a problem they don't yet believe they have.
What is the concept quadrant. This is the part most technical communicators are best at and reach for first: the definitions, the architecture, the expert knowledge, the "here is what this actually is." It's necessary, but it only lands once Why has bought you the audience's attention.
How is the application quadrant. Facts that never get used evaporate within a day. This is where the audience gets their hands on the thing directly: a walkthrough they follow along with, a sandbox they poke at, a quickstart they run themselves rather than watch you run.
What If is the extension quadrant. This is the step most talks and docs skip entirely, and it's the one that decides whether the idea survives contact with the real world. What happens at the edges? When does this break? How would someone adapt it, combine it with something else, or teach it to a teammate? Skipping this step is why so many onboarding docs produce people who can follow the happy path and nothing else.
The listener who needs a reason before they'll listen.
The listener who wants the facts and the model, precisely stated.
The listener who learns by doing, not by watching.
The listener who wants to know where this breaks and where they can take it next.
4MAT was built for classrooms, but the questions map cleanly onto anything you're trying to get a team to adopt: an RFC, a design review, a tech talk, an onboarding doc, a demo. The content in each quadrant just shifts to match a technical audience.
curl command they can paste right now.A few ways this fails in practice, all avoidable:
Go back to that design review. The engineer wasn't wrong about the architecture, the config, or the API. They were wrong about the order. Twenty seconds spent on why the current queue keeps falling over would have earned them the room's attention for everything that came after. That's the entire claim behind 4MAT: it isn't a theory of what to say, it's a theory of what order to say it in, and getting the order right is the difference between a room that checks out by slide four and one that's still with you at slide forty.