There's a kind of deadline that looks external but isn't. The date is in a contract, binding, with a counterparty ready to hold you to it — so it feels like the law of the land, something handed down that you simply have to meet. The team certainly experiences it that way: a fixed wall, no say in where it stands.
But someone put that date there. Someone on your side sat across a table and agreed to it. Which means it isn't an external constraint at all. It's a commitment you authored — and that changes everything about how to think about it, because a date you agreed to is not a planning problem. It's a strategy problem that has disguised itself as a planning problem for everyone downstream.
This one is for two readers at once. The CTO who inherits these dates and has to deliver against them. And the CEO or CPO who signs them — often without seeing that the signature is where the trouble starts.
The Date Is Set at the Moment of Least Knowledge
Here is the structural problem with the long, fixed-date contract, and it's worth stating baldly: you commit to a delivery date for six months of work at the one moment you understand that work the least — the beginning, before discovery, before any contact with the real problem.
Every argument we make about self-imposed deadlines applies here, only now it's load-bearing in a legal document. A date on a large, barely-scoped body of work is a guess. Putting it in a contract doesn't make it less of a guess; it makes the guess binding. You've taken all the uncertainty of half a year and converted it, at signing, into a fixed promise — and handed the other party the right to enforce it.
So when reality diverges from the guess, as it always does, you're not flexing scope quietly the way you could with your own deadline. You're either scrambling to honour a number set in the dark, or fighting through change requests and renegotiations while the relationship sours. The hostage situation didn't emerge during the project. It was created at the table, before a line of code was written.
Why It Feels Like Risk Management and Isn't
The fixed-scope, fixed-date, fixed-price contract is treated as the responsible, professional way to do business. The client knows exactly what they're getting and when. The provider knows exactly what they're committing to. It feels like risk has been managed — pinned down, made legible, signed for.
It hasn't been managed. It's been concentrated.
A contract like this forces both parties to commit maximally at the point of minimum knowledge. Every assumption about scope, complexity, integration, and pace is locked in before anyone has learned whether those assumptions hold. All the risk of the entire engagement is loaded onto a single prediction made at the start — and then the project becomes an exercise in defending that prediction against a reality that never read the contract.
This is the same error as staking a big internal initiative on a public date, with one difference: there are now two parties contractually invested in pretending the guess was sound. When it wasn't, the energy that should go into building goes into the adversarial machinery of change orders, scope disputes, and who-owes-whom. The contract that was supposed to protect the relationship becomes the thing that strains it.
The Alternative: Contract the Way You Should Work
The structure of the commercial relationship should mirror the structure of good work. And good work, we've argued throughout, fixes a short time, bounds the scope to fit, ships, reviews, and decides whether to continue.
Contract the same way.
Rather than selling six months against a delivery date, sell a short, bounded frame: a small, clear scope over a short horizon, with a real deliverable at the end. Then re-contract from what both sides have actually learned. Each cycle is a commitment small enough that the guess inside it is cheap and the knowledge behind it is real. You're not promising the whole journey at the trailhead. You're committing to the next stretch, walking it, and deciding the one after that with eyes open.
To the team, this means never inheriting a date that was set before anyone understood the work — every commitment is sized against something the people doing it have actually seen. To the client, it means they're never locked into a prediction made in the dark; they get a working deliverable on a short rhythm and a genuine decision point at each step, including the decision to stop. That is more control over outcome, not less — even though it offers less certainty about a far-off date that was never trustworthy anyway.
The Honest Tension
It would be dishonest to pretend this is an easy sell.
Clients often want the fixed date in the contract. It's concrete, it's comparable across bidders, it lets them tell their own stakeholders exactly what's coming and when. And a competitor promising a firm delivery date for the whole thing will, on paper, look more reassuring than you offering to "iterate and see." The fixed-date contract is seductive precisely because it sells the feeling of certainty — and feelings of certainty win deals.
So two honest things.
First, to the CEO or CPO: when you accept a long fixed-date contract, understand what you're actually buying. You're not buying certainty — the date is a guess, and you'll discover that mid-project like everyone else. You're buying the appearance of certainty now, in exchange for the scramble, the disputes, and the quality compromises later. Sometimes that trade is worth making — you need the deal, the client won't move, the market demands it. But make it as a commercial decision with the cost named, not as a planning decision you've mistaken for prudence. The bad version is signing the fixed date believing it's the safe choice. The defensible version is signing it knowing it's the expensive one, and pricing the risk in.
Second, to the CTO: the date in the contract is not physics, however much it feels like it. It was a negotiation, which means it's a thing your own organisation produced and could have produced differently. The most useful thing you can do is get into the room before the signature — because the cheapest place to fix a bad deadline is at the table, not in the final sprint. Once it's signed, you're managing a constraint someone created. Before it's signed, you can shape whether it's a constraint or a hostage situation.
Where the Whole Problem Often Starts
We've spent this run of pieces on deadlines you set yourself, deadlines the world hands you, and how to sequence work against either. This one sits upstream of all of them, because it's about the moment a deadline gets created — the negotiation, the signature, the commitment made before the knowledge exists to justify it.
A legal deadline you can only engineer within. A contractual deadline you can engineer out of existence — by structuring the commercial relationship so you never have to promise the far horizon in the dark. The discipline is the same one that runs through all of it: fix one variable and flex the other, and never stake everything on a guess. A contract is simply the place where that discipline is most often abandoned, and most expensive to abandon.
The deadline that takes you hostage is rarely the one imposed on you. It's the one you signed for — and the time to refuse it is before the ink, not after.
Thomas Riboulet is a Fractional VP of Engineering working with European tech companies. He writes about engineering leadership, team structure, and sustainable delivery at insights.wa-systems.eu.