How to Talk to Executives: Price It Before You Argue

0.15 versus 0.47. Those two numbers were my whole answer to Daniel.

Daniel is an engineering manager I mentor. He owns an SDK at a B2B company in a regulated market, and this autumn he asked me how to tell top management that a custom deal for one customer will cost them for years, without saying no to the deal.

Daniel was right about the SDK. He was right in the wrong currency. Talking to executives as an engineer means putting each technical argument in money: the value you earn or the risk you avoid, as an approximation you can defend.

I’ve run 3,662 one-on-one leadership sessions, and Daniel’s question comes from engineers with the better technical case who still lose the room.

My position, and the one Daniel pushed back on: an 80% number you can defend beats a 100% model you can’t explain.

”Great engineer, not there yet” is a label you hand them

Daniel described his problem like this. He sits in meetings with higher management where he holds context the others don’t. Things that are obvious to him aren’t obvious to them, and the discussion turns into a confrontation. Part of his job is risk management, he’s analytical, and he sees long-term issues the others at the table miss.

So I played a CTO for a minute, any CTO. What a CTO hears from an engineer in that kind of meeting is that he’s using excuses why things cannot go this way.

And then comes the label. A really great person, but not there yet, doesn’t understand how business works. It isn’t true, but it’s how top management tends to perceive engineers who argue this way, and I told Daniel straight that if it happens, it’s his fault, 100%.

Look at it from the other side of the table. Your yearly bonus comes from the same revenue you’re arguing against when you ask for clean code instead of the deal. Basically, you demote yourself.

The calmer you are, the more power you have in the room

Before the money, the temperature. It took me years to learn this one and I still have to remind myself of it.

I used to think being very vocal about everything I saw was passion. I was shooting for the right thing, loudly. Then I imagined having that person in my own team, and I could see him as toxic.

Every argument I won by raising my voice, I lost, because other people would stop or be more reluctant at communicating with me. The dog who’s afraid the most barks all the time.

Daniel is further along than he gives himself credit for. He hasn’t raised his voice in 2 to 3 years. When a meeting heats up, he lets it cool, sleeps on it, and picks it up in a one-on-one the next day. That habit has saved me too.

His worry is the other side of it. If he doesn’t stop an argument in front of his own team, he feels undermined. One sentence does stop it, without dropping the point: “Let me come back tomorrow with the numbers.” More on that move at the end.

Before you argue, check the difference is worth a meeting

When I disagree with someone, I turn it into a talk about value. Two options on the table and one question: which one brings more?

When engineers and managers fight, I see two root causes. The first is emotional, two people who don’t like each other. The second is two options of nearly the same value, defended as if the company depended on the outcome.

It’s a technical detail, or one week of difference in a sprint. We spend half an hour of discussion and confrontation about shit, because the difference isn’t big enough to talk about. Sometimes you find out neither option brings value and it’s just egos flying.

So ask it out loud: “What’s the difference in value between these two?” If the honest answer is small, pick one and move on. If it’s big, you’ve found something worth pricing.

Executives buy two things: value and less risk

A manager’s job is to reduce risk. The risk of building the wrong product, of being fined, of delivering too late, of missing the skills or the budget. So every time I speak with someone on the executive level, I turn the talk into money, in one of two directions.

Value

“If we build this, it costs us one sprint and it can open a market worth $2 million in ARR.” That’s the right conversation to have.

Risk

“If we don’t build this, we’re not compliant, and here’s the level of the fine. If we go ahead partly compliant, I need your approval for that.” The risk gets a number, and the decision goes to the person who owns it.

Now the counter-example, from my own kitchen. When one of my engineering managers starts talking to me about Kubernetes, the new version, how great the new tool is, it doesn’t stick, and I’m technical. My questions are simple: has it raised our availability, what does the customer feel, does it earn money or save costs? Without those answers I have no reason to care.

Will Larson’s Present to executives is the best guide I know on structure: “give the summarizing idea before you give the individual ideas being summarized.” It doesn’t put a price on the decision, and a well-structured summary without a price is still an opinion.

If you’re one level lower and trying to get your own manager to listen, I wrote that ladder up separately, from naming the problem to ROI, in six levels of influence.

Two lines on a chart: Daniel’s custom SDK, priced

Back to Daniel. A customer wants to use the SDK in a different way, which means opening functionality in an SDK every customer shares, then testing and maintaining a custom path for as long as that customer stays. He didn’t want to say no. He wanted the key stakeholders to know what they were buying.

So I drew him two lines, with illustrative numbers, because Daniel’s real ones don’t exist yet. In my made-up version, sales wants three custom SDKs a year, and the deal on the table is worth €300,000.

One line is the upkeep of a standard SDK: say each one costs 0.15 of a full-time engineer to keep healthy. The other line is the upkeep of a custom one: 0.47 FTE each, because each custom path adds tests, backward compatibility and code you can’t change without checking the custom cases first.

€6,000 a month is roughly what a mid-to-senior engineer costs a company in Prague: a gross salary inside the Platy.cz band for software engineers plus the employer’s social and health insurance. Put in your own market’s number.

It’s a very simple game

€72,000 a year against €300,000. Take the deal, and say out loud that it comes with one more hire.

Ask how long the contract runs

If the €300,000 is paid once and the hire stays, the upkeep catches up with the deal in about 4 years: 4 × €72,000 = €288,000. The contract length belongs in the same conversation.

Count the slowdown too

Each custom SDK makes the next change to the standard SDK slower, because you have to check you didn’t break the custom scenarios. Don Reinertsen’s rule from The Principles of Product Development Flow fits here: “If you only quantify one thing, quantify the cost of delay.”

When the answer is no

Change one input and the same chart gives the opposite answer. A small customer with no potential, a product manager and a sales guy asking for something highly custom that nobody believes in: you have the full privilege to say that’s not a good deal.

If you’ve never built a money case before, the four-line formula in how to convince your manager to pay for coaching works for other spend too.

An 80% number beats a 100% model

Daniel’s pushback was honest: “Always I have the challenge on how to create these magic numbers.” Where does 0.15 come from, and how does he defend 0.47 in front of management?

Everybody on the top management level knows these numbers are approximations. It’s your privilege and duty to come with them anyway.

Where the number comes from

Go through the last 2 or 3 years of your history: cycle time, incidents, hours spent on custom paths. Or write a best case and a worst case for each option and use the value in between. That’s your educated guess, based on data.

For Daniel, that means pulling five changes from the last year that touched a custom path and noting the hours each one took. Douglas Hubbard’s Rule of Five gives a 93.75% chance that the real median sits between the smallest and the largest of those five. Five tickets, and 0.47 has a source.

How good it has to be

If your approximation is 80 to 85% correct, that’s great. You need to keep the messaging very simple.

Never shoot for 95 or 100%, because you end up with a formula nobody will understand, including yourself. And then nobody trusts you.

What happens when someone challenges it

I guarantee you that once per quarter somebody will jump on you: why the hell is it 0.15? Your answer is one sentence. “It’s my educated guess from 2 years of our SDK history, here’s the sheet.”

Nobody will open that sheet. It’s some sort of pre-agreed magic that works on top management.

When I challenge my own managers on a number, all I want to understand is that they put some thought behind it.

Engineers resist this because a guess feels dishonest. It’s honest as long as you call it a guess.

Don’t win it in the room. Come back tomorrow with a recommendation.

In the room

When the discussion goes sideways, the move is one sentence: “Let me come back with the analysis on what’s the impact on value, cost or risk.”

That’s where Daniel landed by the end of our session, in his own words: “I should say, okay, I will look at the proposal, at the estimation, and then come back.” He walked in asking how to warn management. He walked out with a sentence for the room and a sheet to build.

The alternative is what I see when an engineer stays and fights: but I think, and I think, and I think. It doesn’t help anyone. As the CTO in that room I’m lost after 15 minutes, and what I hear is excuses.

The next morning

Two options, a number for each, with the best and the worst case. Then your recommendation, said plainly, as opposed to hidden in the last slide: “My recommendation is the custom SDK, plus one hire. What do you think?” Ask, because the decision is theirs and the analysis is yours.

What it buys you

Technology is a means to something. For me it’s the means to run the company, build the business and make profit. If you get this right, it invites you into the world of top managers. Without approximations, without talking value and risk, they won’t invite you in.

Daniel’s homework is the five tickets and the two lines with his real numbers, plus one conversation from his week he’d like to replay. We’ll rework it in money at our next session, and I’ll add here what happened next. If you have a story like that yourself, that’s what a mentoring session is for.

[Writing time: 2h]