Knowing Your Audience: The Skill That Keeps You Valuable When AI Writes the Code

As AI takes over more of the coding, the engineer who can make people understand is the one who stays valuable. This post is about how to get there.

The ground is shifting under engineers, early-career and established alike. A model in everyone's editor now turns a clear spec into correct code on demand, which means writing the code is no longer the thing that sets you apart. What increasingly decides your value is whether the people around you understand what you built and why it matters. That is a real skill, and it is one almost nobody teaches you.

You probably know the moment already. You explain something you understand well, you use the right terms and the accurate definition, and the faces in front of you go blank anyway. The work is sound, but the explanation does not land, so you fall back on the textbook version and slowly lose the room. That is not a gap in your knowledge, it is a gap in translation, and translation can be learned.

The skill has a name, knowing your audience, and as coding becomes something AI does alongside you, it has quietly become one of the most valuable things an engineer can be good at.

“An API is a contract of service between two applications”

I was in a meeting once where a team had to present their API, and the room had already lost them on the word “API.” Their tech lead did what most of us are trained to do and reached for the precise definition: “API stands for application programming interface. Interface can be thought of as a contract of service between two applications.”

It was accurate, and it was useless to anyone who did not already know what an API was. The definition was right, and the room understood less than before he started.

Then one of them, the person who is now my co-founder, stood up, pointed at the socket on the wall, and said it was pretty much the API for electricity. You bring a plug, that is your input. You plug it in and you get power every time, a defined input, a defined interface and a defined outcome. That is an API contract, and this time the principle was clear to everyone.

It was the same fact both times. The version built on a definition lost the room, and the version built on something the audience already understood reached them. The difference had nothing to do with knowledge and everything to do with who was listening.

The short version of this story: youtube.com/shorts/Xo3-HcbYv58

The other way to lose a room: prepare perfectly for the wrong one

There is a harder version of this mistake, and this one he tells about himself, which makes it more useful. Earlier in his career, at another company, he was asked to present to a group of potential customers. He prepared for days and built slides he was genuinely proud of, clear and self-explanatory. Then a few small things undid all of it. The slides were in German, and no one in the audience spoke German, only English. The audience was not technical, but he had built the presentation to show how capable he was, a kind of tech masterclass. And his business English was not strong enough yet to carry it live. The result was slides no one could read, content that missed the audience completely, and no real way to recover on the spot. Days of preparation, and almost none of it landed, because all of it was aimed at the wrong room.

The short version of this story: youtube.com/shorts/w34_YMVHfeM

The second mistake is the one worth sitting with. Building the impressive, technical showpiece to prove how capable you are feels like the ambitious and safe choice, but it is actually the trap, because it optimises for looking capable rather than for being useful to the people in front of you.

Watch the full talk

Both stories come from his full talk on knowing your audience in meetings, presentations and everyday conversations, an episode of our Skills Beyond Code course. If you want the whole video, it is here:

So here is the new reality

You are never really talking for yourself. You already know your story, your slides and your reasoning, but the people listening do not, and the whole job is getting it across to them rather than restating it in the way that makes sense to you.

For a long time, being understood was something you could pick up later in your career, if at all. That has changed. Now that producing code is no longer the scarce part, the scarce part is explaining what the code does, why it matters, and getting a non-technical person to act on it. The tech itself is still genuinely hard, but what it does can be explained to almost anyone, and being the person who can do that is what makes you hard to replace. Most people outside engineering have no reason to care about the internals, they care what it does for them, so the engineer who can translate ends up worth more than the one who is simply correct and misunderstood.

What to actually do about it, this week

You do not need to change your personality. You mostly need to aim before you speak.

Before you explain anything, take a moment to place who is actually in the room: technical or not, what they already know, and what they need to decide. Those few seconds change every word that follows.

Where you can, lead with an analogy they already own rather than the definition. The socket worked because everyone has plugged something in, so reach for something in their world first and attach the tech to it.

Try to state the outcome before the mechanism. “This lets a customer pay without leaving the page” tends to land, while “this exposes a REST endpoint” tends to disappear. Say what it does for them, then explain how it works if they want the detail.

And be willing to cut the showpiece. If you notice you are building something mainly to prove how capable you are, it is worth pausing to ask what the audience actually needs, because the version that serves them is usually simpler than the version that impresses you.

None of this replaces the engineering, it is what makes the engineering count. The people who tend to pull ahead are not necessarily the ones who know the most, but the ones the room actually understands.

Utterskills trains the skills beyond code that decide who gets kept: communication, ownership, and judgment. It is built for engineers, concrete, and usable in your next standup.