Teaching Engineers to Speak in Constraints

It was 2:15 on a Wednesday afternoon, and Bruce had just killed the room. The business lead from the Australian side was mid-sentence — something about a new ticketing integration, a partnership that could double our event throughput — when Bruce leaned back in his chair, arms crossed, and said the two words that make stakeholders’ eyes glaze over: “Can’t be done.” The pedestal fan in the corner of our Phaya Thai office hummed into the silence. On the other end of the video call, you could hear someone in Melbourne quietly exhale. The conversation was over before it started.

Except it wasn’t. Because the thing Bruce was trying to say — the thing he meant — was right. We couldn’t do what they were asking, the way they were asking for it, in the time they wanted it. He had the instinct. He just didn’t have the sentence.

I leaned forward. “It can be done — but here’s what you’d need to give us, and it’ll be a little slower than you want. Only a little slower.” The room shifted. The Melbourne exhale turned into a question. Options appeared where a wall had been. We left that meeting with a plan that actually worked.

Bruce didn’t need more courage that day. He needed better language. And that distinction — between the instinct to push back and the skill of pushing back well — is what separates engineering teams that get steamrolled from engineering teams that shape their own commitments.

I’ve written before about the constraints-and-leverage framework — the sentence that changes the conversation in the room. “With [current reality], we can deliver [option A]. To deliver [option B], we’d need [specific ask]. Which would you prefer?” That post was about the skill. This one is about what happens after: how you get an entire team speaking that language, not just the one person who stumbled into it through enough scar tissue.

When the Map Doesn’t Exist Yet

Before we go further, let’s name something important: you don’t need to turn every standup into a negotiation exercise.

Core product work — the features your team has built variations of before, in a domain they know, with estimation patterns they trust — doesn’t require the same intensity of constraint-talk. A two-week sprint on familiar ground has predictable scope. You estimate, you commit, you deliver. Constraint negotiation is useful there, but it’s not life-or-death.

Where this skill becomes non-negotiable is when the territory is new. Strategic projects. Experimental scope. The kind of work where the estimate is a guess, nobody knows what the thing will cost until they’ve started building it, and the gap between “what we promised” and “what’s actually possible” can swallow a quarter whole.

That’s the context where the Lamborghini story lives — low budget, uncharted territory, massive upside if it works. That’s where “sure, no problem” is a death sentence disguised as cooperation, and “can’t be done” is a missed opportunity dressed up as honesty.

As the UCLA basketball coach John Wooden put it, “It’s what you learn after you know it all that counts.” Most engineers know their technical domain. What they haven’t learned is how to translate that knowledge into a conversation that gives the business real options instead of binary outcomes.

The distinction matters because it calibrates the reader’s expectations. If you’re leading a team doing routine feature work in a stable domain, you don’t need a teaching programme. You need good estimation practices and a healthy relationship with your product counterpart. But when you’re staring at a quarter of unknowns — a new market, a platform migration, a technology bet that could reshape your architecture — that’s when the team that can negotiate the gap honestly will outperform the team that says yes and prays.

The Skill That Disappears as You Grow

Here’s something nobody talks about: in startups, constraint-talk happens naturally.

When you’re five engineers in a room with no PM layer, you’re talking directly to the business. There’s no intermediary to absorb the translation. You say “we can’t do X for that budget, but here’s what we can do,” because there’s literally nobody else to say it for you. The founder asks for something impossible, you explain why it’s impossible, you offer what is possible, and you move on. It’s not a skill. It’s survival.

The skill atrophies as organisations grow. PM layers appear. Product managers absorb the constraint conversation. Engineers stop being in the room where commitments are shaped. And eventually, nobody remembers that engineers were ever supposed to be in that conversation at all.

As the management theorist Peter Drucker observed, “The most important thing in communication is hearing what isn’t said.” When your engineers stop speaking in constraints, what’s not being said is every technical reality that should be shaping the commitment. The PM filters it. The estimate absorbs it. And the team delivers something that was never honestly scoped in the first place.

This post is about reversing that atrophy — not by removing intermediaries, but by teaching engineers at any level that the platform for constraint negotiation already exists and they’re allowed to use it.

The Teaching Playbook

Most engineering organisations have the same experience with constraint literacy: one senior engineer figures it out through trial and error, becomes the person stakeholders love working with, and everybody else continues defaulting to hero mode or wall mode. The skill doesn’t propagate. It stays locked in one person’s head.

That’s not a talent gap. It’s a coaching gap. And closing it doesn’t require a workshop, a training deck, or a Confluence page that nobody reads. It requires a specific, repeatable pattern — one that works the same way engineers learn any complex behaviour: by watching it, practising it with support, then doing it independently.

Step 1: The 1:1 Critique

It starts after a meeting. Not during — after. The meeting where an engineer stayed silent when they should have spoken up, or said “sure, no problem” when the honest answer was “sure, but not all of it.”

In the 1:1, one question: “Why didn’t you say that?”

Not punitive. Curious. The answer is almost always one of two things: “I didn’t realise I was supposed to” or “I didn’t feel like it was my place.” Both reveal the same gap — nobody ever told them this was part of their job. Nobody ever said: when you see a constraint that will affect the commitment, it’s your responsibility to name it. Not the PM’s. Not the tech lead’s. Yours.

The 1:1 is where you set that expectation explicitly. You’re not teaching them what to say yet. You’re teaching them that saying something is expected.

Step 2: Modelling in the Meeting

Next time the situation arises, you don’t do it for the engineer. You do it with them.

The technique is specific. You bring the engineer into the conversation with a framing that makes it easy for them to own the response.

“Look, we can’t agree to that — Somchai, wouldn’t you agree?” Then you pause. That pause is the key. You’re not answering for Somchai. You’re creating space for him to wake up and enter the discussion. The framing gives him the answer shape — all he has to do is confirm and elaborate.

Or: “Namfon, that’s the most we could get done for this, right? Like you were saying — anything more is beyond the team’s current capacity.” Pause again.

The engineer owns the response and the commitment, but the manager has demonstrated how to frame it. The constraint is stated. The language is modelled. And the engineer has just experienced what it feels like to say it out loud in a room with stakeholders — and survived.

This is where the design-engineering dynamic comes alive too. The Namfon story from the design handoff post — “What’s the hardest part about building this?” — is constraint-talk in action. The question surfaced a real structural constraint that transformed the estimate. That question only gets asked when someone has been taught it’s their job to surface what’s hard, not just absorb it.

Step 3: The Follow-Up

After the meeting, one more conversation: “Next time, I want you to be the one to say it. You saw how it landed. You don’t need me to set it up.”

This is the deliberate handoff from modelling to ownership. The engineer has seen the sentence. They’ve spoken a version of it with scaffolding. Now the expectation is clear: next time, it’s theirs.

Step 4: Watch for the Unprompted Moment

The shift has happened when the engineer states a constraint in a meeting without being prompted. No setup. No leading question. Just: “With our current capacity, we can deliver X but not Y — what would you prefer?”

The first time Somchai says that without anyone teeing it up — that’s the signal. Recognise it. Name it. Make it visible to the team. This is recognition as a safety signal — what gets praised publicly defines what gets repeated.

Why This Works

It’s not training. It’s apprenticeship. The same way an engineer learns to debug a distributed system or review an architecture proposal — by watching someone do it, doing it with support, then doing it alone.

The 1:1 sets the expectation. The meeting provides the model. The follow-up creates accountability. And the recognition of the unprompted moment makes it stick.

What Kills Constraint-Talk

You can teach this skill perfectly and still watch it die. Organisational behaviour is more powerful than individual coaching, and there are five patterns that destroy constraint literacy faster than you can build it.

The disappointed sigh. The VP who exhales audibly when told “we can’t do all of this” teaches every engineer in the room that honest constraint-setting has a social cost. It doesn’t need to be a reprimand. Body language is enough. One sigh undoes a month of coaching.

“Can’t you just…?” This phrase reframes a structural reality as an individual failing. It implies the constraints aren’t real — that the engineer is just not trying hard enough. The correct response — “I can explain what that would require, and we can decide together if it’s the right trade-off” — takes courage that most engineers haven’t been trained to have.

Rewarding heroes. If the engineer who worked weekends to deliver the impossible gets a public shout-out while the engineer who set realistic constraints and delivered on time goes unrecognised, you’ve just trained every person in the room to be a hero. Hero culture is the enemy of sustainable engineering. It optimises for the dramatic at the expense of the reliable.

Ambiguous commitments. When nobody explicitly commits to a scope and the meeting ends with “let’s do our best” — that’s hero-mode breeding ground. Ambiguity creates the implicit expectation of “everything,” and engineers absorb the impossible because nobody told them not to. As the economist Thomas Sowell wrote, “There are no solutions, only trade-offs.” Every commitment is a trade-off. If the trade-off isn’t named, it still exists — it just gets made by whoever runs out of hours first.

Constraint-washing. When the organisation says it values honest estimation and constraint-setting but acts as if it expects everything delivered on time regardless — the say/do gap destroys trust. Engineers learn to perform constraint-setting for the optics while absorbing the impossible for survival. This is worse than no constraint-setting at all, because it adds cynicism to exhaustion. It’s the prototype that became production of organisational culture — something temporary and performative that somehow became permanent.

You Don’t Need Authority — You Need a Platform

If you’re reading this thinking “great advice for a Director, but I’m a mid-level engineer” — this section is for you.

You don’t need to be a VP to have this conversation with product. You need a platform. And the platform already exists.

Sprint planning. Backlog refinement. Quarterly planning. Design reviews. These are all moments where an engineer at any level can say:

“You want X. With the resources we have now, I can give you Y. If you want X in full, it’ll cost an extra engineer in the team for a quarter, can we trade of some value in another team for this? and move an engineer”

That sentence works whether you’re a tech lead or a first-year engineer. The content changes — a senior engineer quantifies the cost more precisely, frames the trade-off more strategically — but the structure is available to anyone. It also puts the ball back in the court of the person that is responsible for “business value”, the PO, for looking at head count moves. you could go one step further and do this yourself, but that’s the difference betwen good and amazing.

The ownership gradient maps directly here. Station 1 engineers — the ones still waiting for instructions — don’t speak in constraints because they don’t know it’s expected. Station 2 engineers flag constraints but don’t frame them as options. Station 3 and above do constraint-talk naturally, because they’ve learned that shaping commitments is part of their job, not a privilege granted by title.

The coaching mechanism above is how you move people up that gradient. The 1:1 makes the expectation explicit. The modelling shows what it looks like. The follow-up transfers ownership. And the recognition makes it stick.

Beyond the Planning Meeting

Constraint-talk doesn’t stop at sprint planning. Once engineers have the language, it applies everywhere the scope can shift.

Scope creep mid-sprint. “We can add this, but something else needs to come out. What would you like to trade?” This isn’t pushback. It’s a question that assumes the stakeholder is a rational adult who can make trade-off decisions if given real options.

Cross-team dependencies. “Our team can support your request, but our current sprint has us committed through the 15th. We can start on the 16th, or we can discuss pulling someone off [specific item] to start sooner. Which works better for your timeline?” This is the anti-silo language — negotiating across team boundaries requires shared objectives and honest constraints. Without both, cross-team requests either get stonewalled or silently absorbed.

Architecture decisions. “What’s the simplest way we could do this?” is itself a constraint question — it forces the team to name what can be removed rather than added. Every feature request is implicitly a constraint negotiation between what’s desired, what’s feasible, and what’s sustainable.

The estimation conversation. This is where constraint-talk connects to the question that changes everything. “How can we do this in a more simple way?” isn’t a simplification request — it’s a constraint-reframing exercise. It asks the engineer to identify what’s essential versus what’s assumed, and to surface the trade-offs that make the thing actually buildable.

The Skill That Scales

Let’s go back to Bruce. He had the instinct to push back. He’d been around long enough to know when something wasn’t going to work. But he opened with a wall — “can’t be done” — because nobody had ever shown him what the alternative looked like. Nobody had modelled the “it can be done, but” sentence in front of him and then handed it to him to try.

Once he had it — once he saw what options opened up in that room when the wall became a door with conditions — he used it for the rest of his career. Not because he attended a workshop or read a book about negotiation. Because he experienced, in a specific moment, the difference between shutting a conversation down and reshaping it. And someone was there to name what had just happened.

The question for engineering leaders is this: how many people on your team right now have the right instinct but the wrong sentence? People who can see the constraint, who know the commitment is unrealistic, who feel the gap between what’s being asked and what’s possible — but stay quiet because nobody ever told them that speaking up was part of the job?

The coaching pattern works. Set the expectation in the 1:1. Model the language in the meeting. Create the pause that lets someone own it. Follow up and hand it off. Watch for the unprompted moment — and when it comes, recognise it loudly, because that’s the moment the skill stops being yours and starts being theirs.

As Daniel Kahneman wrote in Thinking, Fast and Slow, we systematically underestimate the time, cost, and risk of everything we plan. That’s not a bug in human cognition — it’s the default setting. Constraint-talk is how you override the default. Not once, in a planning meeting. Continuously, as a team capability, embedded in how your engineers think and speak.

The org chart won’t teach them this. The process won’t teach them this. The Confluence page definitely won’t teach them this. You will — one meeting, one pause, one follow-up at a time.

Now, if you’ll excuse me, I have a 1:1 in ten minutes with an engineer who said “sure, no problem” in yesterday’s planning session. We need to talk about what “no problem” actually meant — and what they should have said instead.