Who Are You Trying to Impress with Your Deadlines?

A cheatsheet on why hard deadlines hurt your team, your product, and your customers — and what to do instead.

The Core Argument

Deadlines are useful. They create urgency and bring predictability. But hard, immovable deadlines — the kind where a miss is treated as a failure — are counterproductive. They serve management's need for control, not the customer's need for quality. If your company claims "customer obsession" but punishes missed sprints, those two values are in direct conflict.

Hard deadlines are not user first, they are management first.

Why Locked Sprints Fail

Locking a sprint — freezing scope so nothing moves in or out — creates a lose/lose dynamic regardless of whether the developer finishes early or runs behind. If they finish early, they either pretend they're still working or get assigned more tasks (unlocking the sprint anyway). If they fall behind, the pressure to "just get it done" leads to weekend work and burnout, setting a toxic precedent for every new hire watching.

At no point does anyone stop to ask the only question that matters: does slipping this task actually affect the customer? Most of the time it doesn't. But nobody checks, because the process has become the point.

What Gets Lost

Area	Impact
Quality	Corners get cut. Tests get skipped, documentation stays incomplete. You shipped on time, but the cost was invisible — until it wasn't.
Innovation	Nobody experiments when finishing under deadline is the only metric that matters. React wouldn't exist if someone at Facebook hadn't missed a deadline.
Delight	Quick wins die in the backlog. A trivial bug fix that could ship in a day gets queued for two sprints because The Process says so. You lose the chance to surprise a customer.
Culture	Wrong expectations take root. The new hire learns that weekend work is rewarded. The unwritten rules become the real leadership principles.

Good vs Bad Deadlines

Good Deadlines: Fuzzy, goal-oriented, and proportional to actual customer impact. Missing one triggers a conversation with stakeholders, not a manager scrambling to justify it up the chain. Probabilistic estimates replace gut-based guesses.

Bad Deadlines: Hard, set in stone, and self-imposed. Missing one triggers weekend work, blame, and a culture of performative urgency. Nobody asks whether the user actually cares about the date — the sprint board becomes the customer.

The Right Question

Instead of: "We committed to this, can you still try to wrap it up by end of sprint?"

Ask: "What happens if we move this to next sprint? Does it affect the user?" Then talk to your stakeholders and find out.

The Bottom Line

Have deadlines, but make them fuzzy. Scale the fuzziness to actual stakes: zero fuzz for a million-dollar deal, plenty of fuzz for a new feature. Replace locked sprints with trust, replace gut estimates with probabilistic ones, and always ask whether the deadline serves the customer — or just the weekly sync-up.

If the goal is measuring the thing deadlines are a crude proxy for, Measuring Developer Productivity surveys what 17 companies actually track — and finds every one of them pairs speed metrics with quality and satisfaction rather than collapsing to a single date.