BANT tells you which conversations are worth having. The Grid from Command of the Message tells you how to structure them. This post is about what happens when the conversation stops following the plan.
That happens constantly. A developer you thought was a practitioner turns out to own the budget. The conversation you expected to be thirty minutes becomes ninety because their VP joined. The question you were ready for doesn’t get asked, and the one you weren’t does.
Being audible-ready is the third skill in this series, and it’s the one that makes the other two useful under pressure. It comes from American football: a quarterback who can call an audible at the line of scrimmage has internalized the playbook well enough to change the play in real time based on what they’re seeing, without losing the team. That’s preparation, not improvisation. In DevRel, it means being fluent enough in your frameworks that you can run them live, without a checklist, and adjust mid-conversation when the situation shifts.
You get delegated to who you sound like
Here’s the thing that took me a while to name: the language you use determines where the developer places you in their mental org chart. Not consciously. But when you leave a conversation, the developer is already deciding who to introduce you to next, whose name to put on the follow-up email, which room to invite you into. That decision is based almost entirely on how you sounded.
If you sound like someone who deeply understands technical pain — authentication flows, retry logic, dependency management — you get routed to other developers. That’s the right instinct for most of DevRel, and it’s genuinely useful. But it caps you there.
If you sound like someone who understands business outcomes — what a failed deploy costs in lost integration velocity, what it means for an engineer’s quarter to own an incident — you stay in a different kind of conversation. You get introduced upward rather than laterally. You get copied on the email to the tech lead. You get pulled into the follow-up that wasn’t on your calendar.
You get delegated to who you sound like.
Being fluent in more than one register isn’t about performing authority or dropping business jargon. It’s about being genuinely useful to whoever is in the room, and knowing which language the moment is calling for.
The three registers
Any meaningful developer conversation moves across three modes, sometimes in the same sentence.
The first is technical. Architecture, tradeoffs, implementation specifics. This is where most DevRel practitioners are comfortable, and it’s where you earn credibility before you can say anything else. You can’t skip it.
The second is strategic. Outcomes, timelines, business impact. What does this project actually represent inside their organization? What happens to the team if it ships late, or what opens up if it ships well? This is where conversations move from useful to important.
The third is personal. What is this particular developer trying to prove at work? The one who ships a reliable integration by end of quarter has a story for their next performance review. The one who retires a system the team has been quietly embarrassed about for two years gets a different kind of credit. Understanding what success looks like for them specifically — not for their company, not for the project in the abstract — is where actual trust comes from.
The audible is recognizing which register the conversation has moved into, and following it there. Most DevRel conversations stay technical because that’s where practitioners feel solid. That’s not a flaw in the discipline. It becomes one when the conversation needs to move and you can’t move with it.
What an audible looks like
You’re at a conference, twenty minutes deep into a technical conversation with a backend engineer about webhook reliability. They’ve told you about the retry logic they’ve been hand-rolling for six months. You have a good picture of their situation.
Then their VP of Engineering walks over and gets introduced.
You have ten seconds, maybe less.
The wrong move is to restart the conversation for the VP’s benefit, or to go quiet while the developer recaps. The right move is to translate: “We were just talking through how they’re handling event delivery at scale right now — there’s an interesting architecture question sitting underneath it, and it connects to something we see a lot at companies in similar growth stages.”
That reframed the conversation in terms the VP finds interesting: scale, architecture, pattern recognition. It positioned the engineer as someone working on something substantive rather than just a technical problem. And it moved you from a vendor at a conference booth to someone worth bringing into a different kind of conversation.
You were able to call that audible because you had the Grid filled in already. You knew the before scenario, the consequences, the ideal outcome. The VP’s arrival didn’t require new information. It required translating what you already had into a different register.
Why preparation is the point
Being audible-ready gets confused with being quick on your feet. It’s not the same thing.
The quarterback who calls a great audible isn’t improvising. They’ve run every play in practice enough times that they recognize what the defense is showing and know immediately what to call. The decision happens fast because the thinking happened earlier.
For DevRel, the practical version of this is knowing your value proposition in a sentence for each register. What the product does and how it fits their stack. What outcome it produces and what the cost of the alternative is. What a developer gets to say about themselves after shipping something with it. If you can’t move between those without pausing, you haven’t done the reps yet.
It also means knowing the Grid well enough to know where you are in a conversation at any given point. When a VP joins, you’re not starting over. You’re reading from the quadrant you already filled in, in the language that VP speaks.
And it means knowing when the conversation has outgrown what DevRel owns. That handoff has its own audible: “I want to make sure [name on the sales team] gets a chance to talk with you directly, because what you’re describing is exactly the kind of thing they’ve seen on the other side.” Knowing when to say that, and actually saying it, is part of the job.
What changes when you can do all three
When you can qualify, map, and adjust in real time, something shifts in how the business sees you.
DevRel is often asked to prove its value against metrics that don’t quite fit. Developer satisfaction surveys, content views, Discord activity. Those things matter, but they’re hard to connect to a deal.
A practitioner who shows up to a handoff with a filled-in Grid, having called the right audibles mid-conversation, produces something the sales team can actually use. The developer is warm. The situation is understood. The right follow-up is clear.
That’s DevRel operating at the register the business actually needs. Not every conversation gets there. But the ones that do are the ones worth pointing to when someone asks what the function is for.
The point was never to sound like sales. It was to be useful enough, in enough registers, that the business trusts you with conversations that matter.
A note to close the series: none of these frameworks require you to be less of a DevRel practitioner. BANT, the Grid, being audible-ready — they’re tools for being more genuinely useful to the developers you spend time with. The person who understands your situation, can articulate it back with precision, and can translate it for whoever else needs to understand it is helping you. The sales instinct and the DevRel instinct were never really in conflict. They were always pointing at the same problem.