Speak Their Language

Engineers are very good at describing solutions. We are often quite bad at describing problems. We tend to skip straight to the fix - “the architecture doesn’t scale”, “we need a shared component”, “this should be a service” - and then wonder why the room full of people who decide what gets funded just stares blankly back at us.

We’re just as bad at the other end. Every performance cycle I read self-assessments or promotion cases that go something like this:

“Delivered 4 features. Migrated 3 services. Shipped the new ingestion pipeline. Resolved 120 tickets.”

And every cycle I have the same reaction: ok, and?

It’s the same mistake at both ends of the work. Before, we describe our problem instead of theirs. After, we describe our effort instead of their outcome. Either way, we’re speaking engineering to people who don’t speak it - and asking them to do the translation themselves. Most of them can’t, and many of them won’t.

So: learn to speak their language.

Before: Three Sentences

Here is the single most useful tool I’ve found for describing a problem, and I’ve watched it turn vague complaints into funded projects. It’s three sentences.

Sentence One: What’s Working

Start with the thing that is going well. Not the problem - the success.

“Personalised recommendations are driving a 20% lift in engagement everywhere we’ve launched them.”

This feels backwards to engineers. Why would I open a problem statement with good news? Because it establishes the stakes. Nobody cares about a limitation in something that doesn’t matter. Your first sentence tells the reader this matters, and it tells them in their language - users, growth, revenue, whatever it is your business actually counts.

Sentence Two: But

Now the limitation - in just one sentence. And here’s the hard rule: no technical language.

This is where most of us struggle. I’ve sat with very capable engineers who physically could not get through this sentence without saying “architecture”. It takes practice. The conversation goes something like:

“But the architecture forces us to…” “No. Why can’t you do the thing?” “Because the way the code is structured…” “No. Why does it matter?”

Eventually they land on it: “But every new placement has to be hand-built by one team, so we can only launch a few each quarter.” Ok! Now we’re getting somewhere.

That’s the problem. The architecture is a cause of the problem, and it belongs in your proposed solution later on. The problem is that the business has a proven opportunity, and the machine we built to capture it can’t keep up.

A useful trick if you get stuck: describe what the solution would enable, then invert it. “We want any team to be able to add a placement” becomes “only one team can add a placement”. There’s your problem, or part of it.

Sentence Three: So What

Finally, the stakes - in real terms, for users or for the business.

“Most of our users never see them, and we’re leaving roughly Y in engagement on the table.”

You may not have the number yet, and that’s ok. Leave a placeholder and fill it in later - or find someone to help you fill it in. But even a rough, clearly-labelled estimate transforms this sentence from a complaint into a business case - and, just as importantly, it forces you to think about the scale of what you’re proposing.

Put Them Together

Personalised recommendations are driving a 20% lift in engagement everywhere we’ve launched them. But every new placement has to be hand-built by one team, so we can only launch a few each quarter. Most of our users never see them, and we’re leaving roughly Y in engagement on the table.

Hand that to a decision maker and the response is not “hmm, interesting”, it’s “where do I sign?” Ok, perhaps there’s a little more to it than that. But that’s your hook, and it’s your frame.

The hook works because you haven’t asked them to understand your codebase - you’ve shown them an opportunity, a blocker, and a cost, and left the technical detail for the section where it belongs: the solution.

The frame works because if the solution you then propose doesn’t clearly address the problem described by those three sentences, you know you need to rethink your approach before you propose anything.

After: Finish the Sentence

For connoisseurs of Greek legend: was your effort Herculean, or was it Sisyphean? Both involve pushing very hard, but only one of them achieves anything.

That’s what’s missing from the self-assessment above. Not because the work wasn’t hard - it always is. But hard isn’t the question. The question is whether it mattered, and effort tells me nothing about that.

Engineers are trained to think in engineering units: lines of code, services, endpoints, features, PRs, story points. These are the things we can see and count, so they’re often the things we report. The business does not (or at least should not) think in these units. It thinks in time-to-market, in users, in conversions, in revenue, in risk.

Performance calibration and promotion cases commonly involve people from entirely different parts of the organisation, who have no idea what your features mean. To them, “shipped the new pipeline” is indistinguishable from “did a thing”. “Shipped the new pipeline, which cut time-to-publish from two weeks to one day” is much harder to shrug at.

So never write “delivered X” or “shipped Y” on its own. Always finish the sentence:

• “Delivered X, so that content teams can publish without waiting on an engineer.”
• “Shipped Y, and it moved signups by 4%.”

Every engineering output gets translated into a business outcome, and every engineering cost into a business cost:

• Not “built a shared component library” - how many days does that save on every new feature?
• Not “migrated our services to the new framework” - what does that make faster, safer, or possible that wasn’t before?
• Not “launched a feature” - who uses it, and what did it change for them?

If you can’t finish the sentence, you’ve learned something important about the work - and that’s probably that it wasn’t very important. And sometimes you’ll translate a cost and discover it’s small. Both are a win - you’ve just saved yourself from advertising the wrong thing.

Put a Number On It

The single thing that makes any claim better is a number - even for work that sounds mundane. “Cleaned up our tracking data” sounds like housekeeping. “Fixed a tracking gap that meant 60 million sessions a year weren’t attributed to anything - so we’ve been under-crediting the features that actually drive them” sounds like something leadership needs to know about.

You won’t always have the number. Sometimes the lack of a number is the problem - in that tracking example, nobody could have told you the value before the fix, because the data didn’t exist. Say so, and give an illustrative estimate anyway, clearly labelled. The point isn’t precision. The point is scale: is this a ten-dollar problem, or a hundred-million-dollar problem?

There’s a second benefit. Once you get into the habit of sizing your work in business terms, you start to understand how the business prioritises. When your project gets shelved for something else, you can see why - that thing is worth twelve million, and yours is worth five not-million. That doesn’t make shelving work feel good, but it makes it make sense. It stops feeling so personal.

Where to Use It

Everywhere. I aim to use the same patterns for:

• The opening of a design document or proposal
• The description on a pull request
• The first message in a Slack thread asking for help
• The first thirty seconds of a meeting
• Every case in performance assessment or promotion cases

If you’re using an LLM to help you write, give it this structure and rant at it. “Here’s what’s working, here’s what’s broken, here’s what I think it costs - help me tighten it.” It’s remarkably good at the tightening. It’s remarkably bad at knowing what the problem is - that part is still your job.

The Reflex Takes a While

Be warned: this is a reflex you’re changing, and reflexes don’t change overnight. You’ll catch yourself opening with “the architecture” for months. You’ll write “delivered X” and forget the rest. That’s fine. Every time you catch it, you get a little faster.

If I had to name the single biggest shift between a senior / staff engineer and a principal, this is it. Senior and staff engineers (often) still think in effort and output. Principals (should) think in stakes and outcomes. It’s not that they work harder or write better code - they quite often don’t. It’s that they can look at a piece of work and tell you what it’s for: who benefits, by how much, and why that matters more than the other thing they could have done.

If you find this hard, that’s normal. It’s a muscle, and most engineering education never asks you to use it. Ask your lead for help. Ask your PM. Ask a finance person what they’d want to know.

The day you can lay out a problem in three sentences that a non-engineer immediately cares about - and finish every “delivered X” with a “so that” - is the day you’ve stopped executing, and started leading.