Your Engineers Can’t Negotiate — And It’s Your Fault

I’m sitting in a conference room at a startup in Australia, and I’ve just finished what I think is the presentation of my career. Half a million dollars of blade chassis gleaming on the PowerPoint behind me. State-of-the-art switches. A database server that could handle anything we threw at it for the next five years. My dev team is nodding. The accounts guy is taking notes. We’re about to transform this company.

Then one of the founders says, “Can we have the room?”

Here’s what you learn about startup founders: they’ve already done the math before you walk in. They know exactly how much runway they have. Down to the day.

The founder — let’s call him Dave — leans forward. He’s got that look. The one that says he’s about to explain reality to someone who’s been living in a fantasy.

“Profits haven’t been what we projected,” he says. Translation: we’re bleeding cash. “The peak sales season — that’s what gets us through the year.” Translation: miss this, we’re dead. “If we can’t get through this with 100k, we’re in trouble. Big trouble.”, we start sending people home.

My beautiful half-million-dollar plan just became a hundred-thousand-dollar problem. That 400,000 dollar gap was the moment most engineers’ careers quietly stall — not because of the money, but because of what they say next.

As the former FBI hostage negotiator Chris Voss observed, “Negotiation is not an act of battle; it’s a process of discovery.” He was talking about kidnappings and crisis standoffs, but he might as well have been describing every sprint planning meeting you’ve ever sat through where the ask didn’t match the capacity, the timeline didn’t match the scope, and everyone in the room knew it but nobody said it out loud.

The Two Ways Engineers Kill the Conversation

You’ve been in that room. We all have. The budget doesn’t work. The timeline is fantasy. The scope would require a team twice the size you have. And in that moment, almost every engineer on the planet defaults to one of two responses, both of which are career poison.

The Hero. This is the engineer who absorbs the impossible. “Sure, we can do that.” They say yes to the half-million-dollar infrastructure on a hundred-thousand-dollar budget. They’ll work nights. They’ll find a way. They always find a way — until they don’t, and the failure is spectacular and public and somehow still their fault. The hero complex feels noble in the moment. It feels like commitment. What it actually is, is a lie that delays the consequences of reality until the stakes are maximum.

The Wall. This is the engineer who tells the truth without giving the business anything to work with. “We can’t do that for 100k.” Conversation over. Technically accurate, communicatively useless. The business hears “I don’t want to help you.” The engineer thinks they were being honest. They were — but honesty without options is just complaint dressed in professional clothes.

Here’s what both responses have in common: they end the conversation. The hero ends it by removing the need for one — “I’ve got it, don’t worry.” The wall ends it by removing the possibility of one — “It can’t be done.” Neither response creates a sensible path forward. Neither response makes the engineer a partner in solving the problem. And critically, neither response teaches the business anything about how engineering actually works.

If you’re an engineering leader and your teams default to hero mode or wall mode in every planning conversation, that’s not a hiring problem. That’s a teaching problem. And it’s yours.

The Third Language

Back in that conference room in Australia, with Dave’s words still hanging in the air and my beautiful PowerPoint suddenly looking very expensive, something different happened. Not hero mode. Not wall mode. A conversation.

“Here’s what 100k buys us.”

That was the opening. Not “we can’t.” Not “leave it with me.” Just: here is what’s real.

This was years before public cloud existed. No AWS. No elastic scaling. No pay-as-you-go. You bought hardware or you didn’t scale. Period. And the core problem was brutal in its simplicity: the company had a peak sales season — two months of summer traffic spikes that could hit 50–100 times normal load. Miss that window and the business was dead. The peak season was the product.

I’d spec’d infrastructure that could handle those spikes for the next five years. Half a million dollars — blade chassis, enterprise database servers, redundant everything. Hardware built to handle peak load and sit idle most of the time.

For 100k, we couldn’t buy any of that. We couldn’t even buy two of the blade chassis I’d spec’d. But here’s the thing about constraints — sometimes they force you to see what’s been there all along.

That’s when I discovered eBay had a section for decommissioned government servers.

Let me explain what buying enterprise hardware on eBay meant back then: it meant you were either desperate or insane. These servers came with no warranty. No support contract.

Bruce, our infrastructure guy, called me from the pickup location — some guy’s storage unit in an industrial park. “They’re wrapped up in bubble wrap like… like big sausage rolls,” he said.

“Do they look… functional?”

“They look like servers that have, seen things.”

But here’s what Dell, IBM and HP won’t tell you about their blade chassis: they’re overengineered. They’re built to run in defence contractors’ data centres for a decade. When the Department of Defence sells them after four years, they’ve got another four years in them. We were paying $8,000 for what would have cost us $80,000 new.

Then the leverage: “If we can stretch to 120k, we can handle the peak season with headroom to spare. That’s the difference between ‘we probably survive’ and ‘we definitely survive.’”

That sentence changed the shape of the room. Suddenly Dave had something he didn’t have thirty seconds before: a decision to make. Not a problem to absorb, not a rejection to swallow — a choice. Accept the tighter constraint and pray, or find another 20k knowing exactly what it would unlock.

We delivered for 120k. Could have done it for 110k, but we bought some insurance — extra garbage servers from eBay. The first weekend of peak season, we watched the metrics climb. Traffic spiking 50 times normal. The janky eBay servers handled it. They weren’t just handling it — they were cruising. We had 40% capacity to spare.

Dave pulled me aside afterward. “How much did we spend total?”

“One-twenty. Could have done it for one-ten, but we bought some insurance.”

“Insurance?”

“Extra garbage servers from eBay.”

He looked at me like I’d just explained how we turned lead into gold. The half-million-dollar quote had felt like an immovable wall. Turns out, it was just the first offer in a negotiation nobody had started yet.

Constraints: Saying What’s Real Without Saying No

The foundation of this third language is constraints — stating your reality as fact, not complaint. There’s a critical difference between “we don’t have enough engineers” and “with our current team of three engineers, we can deliver features A and B by Q2; feature C would push the timeline to Q3.”

The first version is the hallway voice. It’s what engineers say to each other over coffee, and it’s emotionally honest, but it gives the business absolutely nothing to act on. No one can prioritise against a feeling. No one can make a trade-off with a complaint.

The second version is the same truth, repackaged as information. It doesn’t say no. It says “here is what yes looks like given reality.” And that distinction matters enormously, because business stakeholders can work with options. They can’t work with surrender.

Phil Jackson, the legendary NBA coach who won eleven championships, said something that applies to engineering rooms as much as locker rooms: “The most we can hope for is to create the best possible conditions for success, then let go of the outcome.” That’s what constraint-setting does. You’re not controlling the decision. You’re creating the conditions for a good one by making reality visible to everyone in the room.

Most engineers skip this step entirely. They either absorb the constraint silently (hero mode) or state it as a blocker (wall mode). The skill is stating it as a foundation — the ground truth from which options can be explored.

Leverage: The Unlock

If constraints are the foundation, leverage is where engineers become strategic. Leverage is “if you give me X, I’ll give you Y.” It’s not wishing. It’s not “if I only had more budget.” It’s a business case, stated in terms the other side can evaluate and act on.

That 100k-to-120k conversation was leverage in its purest form. The constraint was the budget. The leverage was: here’s the specific capability gap between what you have and what you want, and here’s what it costs to close it. The business didn’t have to guess. They didn’t have to trust that “more money would help somehow.” They could see the exact return on the incremental investment.

Ferruccio Lamborghini understood this instinctively. In post-war Italy, he started building tractors from decommissioned military vehicle parts — engines from surplus Morris trucks, augmented with fuel atomisers of his own design that let them switch from expensive petrol to cheap diesel. He didn’t have the budget for new components. He didn’t complain about the constraint. He reframed what was possible within it, and built an empire that eventually led him from tractors to some of the most iconic sports cars ever made. When he was later dissatisfied with his Ferrari and was famously told to stick to making tractors, he didn’t accept someone else’s definition of what was impossible — he negotiated with reality until reality gave him a Miura.

The parallel to engineering teams is direct. Every planning meeting has a version of the half-million-dollar conversation. The budget doesn’t match the ask. The timeline doesn’t match the scope. Engineers who can articulate “here’s what we can do with what we have, and here’s what we’d need to do more” transform from order-takers into partners. That’s not a soft skill. That’s the skill.

Why This Is a Leadership Problem

Here’s the uncomfortable part for engineering leaders: if your engineers can’t do this, it’s almost certainly because they’ve never seen it done.

Communication patterns in engineering teams are learned behaviour. If the engineering manager is the one who always says yes in the planning meeting and then scrambles privately, the team learns that’s how it works. Hero mode becomes the culture. If the manager is the one who pushes back with “that’s hard” or “we don’t have capacity” without offering alternatives, the team learns that engineering is a department that says no. Wall mode becomes the identity.

But if the manager walks into every planning conversation and says “with our current capacity, here are our options” — states the constraint, then offers the leverage — the team learns that this language is safe. More than safe: effective. They see their manager being treated as a partner instead of a subordinate or a blocker, and they internalise that this is how engineering earns its seat at the table.

The shift from implicit to explicit matters more than most leaders realise. Implicit constraint management is reactive — you absorb pressure, find shortcuts, stay late, and hope nobody notices the gap between what was promised and what was possible. Explicit constraint management is proactive — you name the trade-offs before they become emergencies, and you give the business the information they need to make decisions that account for engineering reality.

This connects directly to psychological safety. Engineers can only negotiate honestly about constraints when they feel safe being honest about constraints. If the culture punishes “we can’t do all of this” — even subtly, even through disappointed body language in a planning meeting — engineers will stop saying it. They’ll default to hero mode, absorb the impossible, and fail later at higher cost. Or they’ll default to wall mode, disengage, and let the business make uninformed decisions.

The teams that get this right are the ones where honest constraint-setting is recognised and rewarded. Not just tolerated — actively valued. When an engineer says “here are our options given reality” and the response is engagement rather than frustration, that engineer will keep doing it. When that behaviour is publicly recognised — “Somchai’s constraint analysis in last quarter’s planning saved us from committing to a timeline we couldn’t hit” — other engineers learn that this is what good looks like.

Making It Muscle Memory

This can’t be a one-time training session. A workshop on “negotiation skills for engineers” will generate some nodding, maybe a few good conversations, and approximately zero behaviour change. The skill has to become ritual.

If you make it table stakes at every sprint planning the team will get so much more effective its worth the effort.

Every sprint planning: constraints stated first. What do we have? What’s our capacity? What are the known blockers? This isn’t pessimism — it’s the starting position from which realistic commitments can be made.

Every scope discussion: leverage offered second. “With what we have, here’s what we can deliver. If you want more, here’s what we’d need.” This turns every negotiation from a confrontation into a collaboration. The business gets options. Engineering gets agency.

Every quarterly planning: decisions requested explicitly. Don’t leave the room with ambiguity. “Given these constraints and these options, which path do you want to take?” Force the decision. Not aggressively — respectfully. But force it, because ambiguity is where hero mode breeds. When nobody explicitly chooses a path, the implicit expectation becomes “do everything,” and the engineers absorb the impossible because nobody told them not to.

The communication template is deceptively simple:

“With [current reality], we can deliver [option A]. To deliver [option B], we would need [specific ask]. Which would you prefer?”

That’s it. That’s the whole framework. State the constraint. Offer the leverage. Request the decision. It works in sprint planning. It works in quarterly reviews. It works when a VP walks up to your desk at 4 PM with an “urgent request.” It works because it treats the business as a partner capable of making trade-offs, rather than an adversary to be managed or a parent to be obeyed.

The Shift That Actually Matters

The reason this matters isn’t efficiency or process improvement. It’s not even about better planning outcomes, though you’ll get those too.

The reason this matters is that engineers who can speak this language feel different in the room. They stop being passive recipients of requirements and start being active participants in shaping what gets built. That shift — from order-taker to negotiator — is what empowerment actually looks like in practice. Not a motivational poster. Not a values slide in the all-hands deck. A communication skill that changes your relationship with every stakeholder you interact with.

Every engineer has been in a room where the ask didn’t match the reality. Most were never taught what to say when it happens. They were taught algorithms and design patterns and system architecture, but nobody taught them the sentence that changes everything:

“Here’s what we can do. Here’s what we’d need to do more. What would you prefer?”

That’s not a soft skill. That’s the hardest skill in engineering. And if your team doesn’t have it, it’s time to ask yourself: who was supposed to teach them?

The Bottom Line

The half-million-dollar quote in that conference room wasn’t a constraint. It was a starting position that nobody had questioned. The 100k budget wasn’t a limitation. It was information — the foundation of a conversation that nobody had thought to start.

Your engineers are in those rooms every day. In sprint planning meetings where the scope doesn’t fit the sprint. In quarterly reviews where the roadmap doesn’t fit the headcount. In architecture discussions where the timeline doesn’t fit the complexity. And most of them are defaulting to hero mode or wall mode because those are the only two languages they know.

Teach them the third one. Model it yourself. Reward it when you see it. Make constraints visible and leverage explicit. Turn every planning conversation from a confrontation into a negotiation — and negotiation into a place where engineering earns its voice.

Now, if you’ll excuse me, I need to go prepare for tomorrow’s quarterly planning session. I’ve got three teams, two competing priorities, and a timeline that only works if we invent time travel. But at least I know what to say when I walk in the room.