Executives Don't Fund Technology. They Fund What Changes Because of It.

Fifteen years building technical systems, and the thing I got wrong for most of the first ten was this: I described what we built instead of what changed.

Those are not the same sentence, and only one of them survives the meeting.

🔁 Four rewrites I have actually had to make

"We reduced response latency and eliminated timeout failures under load." → "It no longer breaks in front of a client." An executive will defend that in a budget review. Nobody has ever defended latency.

"We scoped credentials per tool and separated read access from write access." → "Two people asking the same question get the same answer, and we can show who was allowed to see what." A security task becomes a governance question, which is what leadership already worries about.

"We integrated an external research source and routed it into four sections of the output." → "People walk into meetings already knowing what the market says about the account in front of them." The value becomes a behaviour someone can picture, so it gets repeated when you are not in the room.

"We automated the document generation pipeline end to end." → "Work that took two days now takes an afternoon." It borrows a unit they already track. Time, not throughput.

In every pair, the first version is more accurate. The second is the one that gets funded.

The objection is that the second loses precision, and the audience should meet us halfway. They will not. They are not evaluating your work. They are deciding where to put money and attention, against six other things asking for the same. Precision they cannot act on is noise, however correct it is.

⚖️ The decision that changed how I think

Two organisations coming together, each with an incompatible way of categorising the same information.

The technically correct answer was obvious. Design one clean structure, migrate everything, retire the old one, do it properly.

The position that won: keep both, run them side by side, accept the mess, get people using it now. The framing that ended the argument was one line. This is an adoption exercise, not a design exercise.

Every technical objection to that approach was valid. None of them mattered. The risk was never an imperfect structure. It was that nobody would use the thing at all, and a beautifully designed system nobody touches is worth nothing.

🤖 Why this is harder in AI than elsewhere

The work is invisible. Something that makes a few hundred people slightly better at their jobs leaves no artifact to point at.

The vocabulary misleads. Our words carry precise meaning for us and something vaguer for everyone else. Used accurately with a non-technical audience, they transfer an impression of complexity, which gets mistaken for risk.

🔤 On acronyms

Every acronym moves work to the listener. If they know it, you gained nothing. If they do not, they either decide not to ask or spend the next half sentence working it out and miss what followed. You never find out which, because senior people rarely ask.

The test: if you would have to explain it outside your own function, do not use it. Expanding it once and using it anyway does not help — you are still asking someone to carry a new term through the whole conversation.

🔄 The part I had backwards

I thought this was packaging, applied at the end. It runs the other way. It shapes what gets built, because you can no longer hide an unclear purpose behind an interesting problem.

Half the features I cut in the last two years were cut not because they were hard, but because I could not finish the sentence explaining who would be better off.

That is not communication. That is design.

Take the last thing your team was proud of. Write the one sentence an executive would repeat to their own board.

If that sentence does not come easily, the problem is rarely the work.

What would yours say?