Never Be the Risk Absorber

Moving past the vendor-client relationship in engineering

You know this meeting. The founder, the VP of Sales, or a product manager with a roadmap to defend asks how long something will take. The room goes quiet and everyone turns to you. You say a number — “six weeks, maybe eight” — and people write it down. And right there, between your mouth and their notebooks, six weeks stops being an estimate. It becomes a promise.

That is the moment you become the risk absorber. You did it in a second, quietly, without noticing.

An interesting thing is that there was no good answer for you in that room. Give an honest number and it usually fails. Because honest estimates only cover what you know, and you cannot account for what you don’t know yet. A spike or a PoC can reduce the unknown, but they almost never remove it. So you miss, and you are the one to blame.

Now try the opposite. Pad the estimate to stay safe. What happens? Your proposal looks expensive, you look like you are hedging. And you do. Hedging does not make you look good. It makes you look like you are trying to protect yourself at others’ expense.

Both options are a trap, and both of them close on the same person — you.

Before we continue. I am Roman, CTO at a startup, and I write High-Impact Engineering — a weekly newsletter for engineering managers, directors, and CTOs.

This week’s issue is about building a partnership with stakeholders.

The real trap

The trap is that you are carrying a decision alone that was never yours to carry alone.

Take a few examples. You agree to one more parallel initiative, so the team spreads thin, switches context all day, and slows down, but you absorbed that trade instead of naming it.

You cut a corner to hit a date, so the tech debt piles up and next quarter runs slower, but you ate that too.

You promise a feature will be ready by a certain date, and now you must deliver it whatever the odds. Same move every time: someone asks, you feel the risk in your gut, and you swallow it because you think it is your job to make it happen.

It feels like being helpful. It is actually a setup. You made yourself the vendor, deliver or take the blame, and you turn your colleagues into clients. Clients don’t want to share the loss. They expect the order to be at their door on time.

And here is why both versions of the estimate trap close on you: you are trying to solve a shared problem on your own. The choice between committing and buffering is impossible as long as you are the only one in the room holding the risk. You are guessing at a risk appetite that is not yours to set.

Turn the table

So what do you do? You stop deciding alone. You turn to the person asking and you make the decision with them.

This is not saying no. It is changing who is in the room when the risk gets priced. It sounds something like this:

“I am happy to try this.” Open with a yes. Nothing loses the room faster than sounding like you are blocking it.

“But there is a real risk we won’t deliver this in the agreed scope and timeline, and I am not comfortable committing to it as a promise.” Name the risk honestly. As yourself, not as a policy.

“If we still want to do it, I want us all on board with that, and I want us to agree on a mitigation plan.” Switch from I to we. That one word is the whole move. The risk stops being mine and becomes ours.

“And here is my side of it: I will deliver the best I can, I will keep you posted, and I will raise a flag the second I see us slipping.” Offer your own commitment back.

That last line is the one everyone skips, and it is the one that matters most. Skip it and “turning the table” is just passing the buck — your risk, your problem, good luck. Keep it and you have made a deal: I will share the decision, and I will do my part to keep us out of the ditch. You reposition yourself from a vendor to a partner.

Look at what just happened. You did not refuse. You did not hedge to protect yourself. You took the impossible solo choice, commit or buffer, and invited the people who own the business outcome to become partners on the decision. You handed them the one input only they can give: how much risk they are willing to take on this bet.

Speak their language

One catch. The consequence only lands if you say it in a currency the other person actually feels. “We will accumulate technical debt” means nothing to a CEO. So translate.

To the CEO, risk is money and runway — if this slips a month, we burn X and miss our window. To the CPO, risk is the customer — ship this half-built and we churn the segment we just won. To another engineering leader, risk is velocity — take this on now and everything else moves right by a sprint.

You are making the cost visible to the person who has to weigh it. That is the whole difference between “engineering is being difficult again” and “ah, now I see the trade-off.” You don’t need a flowchart for this. Just talk to the person in front of you about the thing they actually care about.

“But what if it fails anyway?”

Here is the honest objection. You turn the table, they say take the risk, and you miss anyway. Now what? Don’t you still get the blame?

In my experience, no — not the way you fear. Because we flagged the risk the whole way and kept everyone updated, we are far less likely to be the one holding the blame, and the damage to the business will be manageable, since we already agreed on the mitigation plan.

The conversation is not “engineering dropped the ball.” It is “we knew this could happen, here is where we are, here is what we do next.” We share the loss the same way we shared the decision. And strangely, that is often when trust gets stronger, because we proved we would tell the truth even if it is inconvenient.

The risk never disappears. What disappears is the surprise. And the bad surprise is what actually breaks relationships.

The rule

So here is the whole thing in five words: never be the risk absorber.

Next time you hear yourself about to say “we’ll figure it out,” treat it as an alarm. That sentence is the sound of the trap closing. Stop, and turn the table instead.

Do this enough and something changes. The people who used to treat you like a feature vendor start weighing the trade-offs next to you. The wall between business, product, and engineering gets thinner, because decisions that used to happen to engineering start happening with it.

You stop being the vendor who delivers or gets blamed. You become what you needed to be from the start: a partner in crime, working a different angle toward the same goal.

If this was useful, subscribe to get one practical post on engineering leadership every week.