Project Anatomy: Dates Are Outputs, Never Inputs

TL;DR: A delivery date is either an input to planning or an output of it. Almost every “when will it ship?” conversation treats it as an input, then wonders why the number keeps slipping. A sailor who commits to an arrival time before checking the wind isn’t being confident. They’re being incompetent. This post is how to tell the arrow direction apart, and the six-question test to catch it.

The Meeting #

Someone new joins - a director, a staff engineer, doesn’t matter who - and in their first week they ask the innocent question. “So when will X ship?”

Somebody answers. It is Tuesday, so they say something like “end of Q3.” The number arrives with a small headshake that means “you know how it is.” Everyone nods. Somebody writes it down.

Six weeks later, the date slips. Nobody is surprised. Nobody investigates. The slip goes into the deck as “revised timeline” and the number moves right by a month. Business asks how confident we are in the new number. Somebody in the room does the exact same headshake. The number moves right by a month.

I’ve watched this loop run - unchanged, uninterrupted - for four consecutive quarters at more than one company. Nobody in the room is lying or lazy; the engineers are competent, the PM careful, the CEO reasonable. And yet the date is wrong every single time, and everybody knows it will be wrong the moment they hear it, and everybody says it anyway.

This post is about the moment before the date got said.

Because that is the moment the loop is set. Everything that happens after - the slip, the deck, the headshake - is the loop running its course. If you want to break it, you have to understand what happened in the four seconds between the question and the answer, and why the person answering did what any reasonable person would have done.

Two Mental Models #

There are two ways of thinking about “when will we arrive?”

The first is driving. You’re in a car, going from A to B. The road is mapped, the distance fixed, traffic a small perturbation you can adjust for on the fly. If somebody asks “when will you arrive?”, you can answer with confidence. Google Maps has an opinion. So do you. If you’re twenty minutes off, that’s rounding error.

The second is sailing. You’re on a boat, crossing an ocean to a fixed destination. The wind moves, the current pulls you sideways, the weather shifts. Somebody asks “when will we arrive?” and you check the chart, check the wind, check your speed, and compute a range. Not because you’re hedging - because that’s the honest answer. Tomorrow the range will be different, and different again in four hours. That is not a defect of the range. That is what the range is.

Nobody sane demands an arrival time from a sailboat captain before departure. Nobody argues that a range is a cop-out. Nobody sends a memo about how, if we would all just commit harder, we could arrive at 3pm on Thursday. It would be ridiculous.

And yet in software delivery, which sits far closer to sailing than to driving, we demand the 3pm-Thursday number every week. Then we’re surprised, and vaguely disappointed, when the boat gets to port at 4:30pm on Friday.

Here is a distinction that carries the rest of this post. A chart is a model of the environment: shoals, currents, harbours, prevailing winds. A route is a plan of how to cross it. The chart is durable. The route gets redrawn whenever the wind changes.

Roadmaps are charts. We insist on treating them as routes.

The moment we treat the chart as the route, the arrow flips: the date becomes the input, and the work has to compress under it. Every downstream failure - the missed dates, the death march, the trust erosion, the quiet cynicism - flows from that flip. Smart teams can ship constantly under this arrow and nothing moves, because “shipped” starts meaning “arrived at the number” rather than “arrived at the destination.”

Why We Keep Applying the Wrong Model #

The reason smart teams keep making this mistake is not ignorance. It is that the mistake has cover.

Dave Snowden’s Cynefin framework, developed at IBM in the early 2000s, separates two kinds of hard problem that get carelessly conflated.

Complicated problems have knowable answers. Cause and effect are discoverable by analysis. You may need expertise to find them - the answer is not obvious to a novice - but the answer exists, and the right response is sense, analyse, respond. Driving in a well-mapped city with heavy traffic is Complicated. A cardiac surgery is Complicated. Designing a load balancer is Complicated.

Complex problems are different. Cause and effect are only visible in retrospect. Interventions change the system they are intervening in. Any prediction more than a short way out is unreliable, not because you failed to think hard enough, but because the system does not work that way. The right response is probe, sense, respond: run small, contained experiments, watch what happens, adjust. Crossing an ocean is Complex. Raising a child is Complex. Shipping a real product in a real market is Complex.

Here is where the mistake gets its cover. The individual tasks inside a software project are usually Complicated. This API needs to be built. This migration needs to be run. This bug needs to be found. Each has a knowable answer, and the person doing it has expertise.

The aggregate, though, is Complex. Requirements shift under discovery. Dependencies surface late. Integrations reveal misunderstandings nobody could have named in advance. Users react to earlier releases in ways that reshape later ones. Interventions change the system.

We estimate at the level where the world is Complicated (tasks) and then we forget that the shipping unit lives at the level where the world is Complex (the aggregate). We add up numbers that are individually defensible and produce a total that is systematically wrong.

Figure 1: We estimate where the world is knowable. We ship where it isn’t.

Fog is what Complex looks like from the deck. You can see three metres ahead of you, not thirty. You don’t plan through fog. You sense your way, and you update your position estimate constantly. The mistake is pretending the fog isn’t there because at the task level, you can see fine.

The Three Levers #

If the date is an output, what are the inputs? Three levers, and only three.

Capacity is how much work the team can complete per unit time. Not “how many engineers.” Not “how many story points we plan.” Measured throughput - what actually got merged, deployed, and marked done, averaged over enough weeks that the number stops jumping around. Anyone who has ever measured this at a real team has felt the mild shock of how much lower it is than the plan number.

Scope is what “shipped” means. The list of things that must be true for launch. Not the wish list, not the roadmap, not the vision deck. The actual, versioned, priority-ordered list of items that block the launch itself. If you can’t produce it in a doc that fits on one screen, you don’t have a scope. You have an opinion about what scope might look like once somebody makes some decisions.

Reliability is what fraction of the team’s weekly commitments actually land when committed. Not aspiration. Measured. If your team commits to twelve items on Monday and eight of them are done on Friday, your reliability is 66%. That number goes into the forecast. If you don’t have that number, you don’t have a forecast; you have a wish with error bars nobody has computed.

The arithmetic follows from the three levers. A sailor’s ETA is roughly remaining distance divided by current speed, updated hourly. The software equivalent, roughly, is remaining scope divided by (throughput × reliability), expressed as a range. Recomputed weekly. Published in the same place every time, even when the news is bad.

Figure 2: The date is an output of this arithmetic. If you can’t do the arithmetic, you don’t have a forecast.

Consider two Monday standups. Same team, same work, same CEO. In the first, the PM asks “when will X ship?” and gets a date: “end of Q3.” Everyone nods. Three weeks later, the date slips. Everyone knew it would; nobody knew when.

In the second, the PM asks the same question and gets a range: “currently 7 to 11 weeks, based on 60% reliability last quarter and current scope of 24 items.” Three weeks later, the range has narrowed to 5 to 8 weeks. One item has moved out of scope to make room for something the CEO wanted, and everyone can see it. The reliability number for last month is 68%, published under the range.

One team is guessing under pressure. The other is doing arithmetic in public.

Figure 3: Same team, same work, same CEO. One team is guessing under pressure; the other is doing arithmetic in public.

The difference is not talent. The difference is which direction the arrow points.

Wind and Drift #

The number-one move used to defend input-first dating is “yes, but we need to hold people to something. If we don’t commit to a date, nothing ships.”

Yes, teams need commitments. No, the commitment cannot be the date, because the date is downstream of things nobody controls.

Wind is external change. A requirement shifts because a customer said something in a demo. A vendor updates their API. A competitor moves. Wind is normal ocean behaviour, not a bug in the sailing model. A sailor who blames the wind for a delayed arrival isn’t doing their job.

Drift is the quieter, meaner cousin. It’s silent scope creep. The small “while we’re at it” additions. The requirement clarifications that quietly extend the work. The “just make it work the way Stripe does” moment in the meeting where nobody stopped to ask what that actually meant. Drift is what happens when you don’t correct against the wind, not because you didn’t notice the wind, but because nobody wanted to have the conversation about correcting.

You look up two weeks later and you are fifty nautical miles from where you thought you were, and nobody can point at the moment it went wrong. That is drift.

Both wind and drift argue for recomputing the ETA continuously, not against having a plan. The alternative to a moving forecast is not a fixed forecast. It is a fixed forecast that everyone quietly stops believing.

The Honest Counterargument #

Here is the counter that comes back at me when I make this argument out loud.

“Fine. But if the date is always a range that keeps changing, you’ve removed accountability. You’ve given the team a shield. Any missed target is just ’the range moved,’ and any complaint is met with ‘oh, it’s Complex, we can’t estimate.’ You’ve replaced hard commitments with vibes.”

That failure mode is real. I’ve seen it. It usually comes from a team that read half a book on agile and stopped there. It’s a close relative of the wishful-thinking failure mode: motion without accountability, dressed up as sophistication.

The output-first move is not “refuse to give a number.” It is “give a range, computed from measurable inputs, on a fixed cadence, published even when the news is bad.” The range replaces the point. The cadence replaces the promise. The arithmetic replaces the vibe.

A sailor tacks - zig-zags into the wind - to reach a destination they cannot sail toward directly. From the deck, tacking looks like progress in the wrong direction. From the chart, it is the only way there. Re-planning constantly is the plan, not evidence the plan failed. The mistake is confusing the daily heading with the actual course.

The accountability is not softer. It is harder, because it is measurable. Does the range narrow over time? Does the reliability number rise? Does the number of items in scope stay roughly stable, or does it silently grow while the delivery target holds? Those are numbers you can point at. A single-point date is not accountability. A single-point date is theatre.

If the range never narrows, the team is not sailing. It is drifting. That is the failure mode to catch, and it is caught with data, not with a memo.

The Test: Is Your Date an Input or an Output? #

Six questions. Apply them to any date you have committed to, or been handed, this quarter.

1. Origin. Where did the date come from? If a person said it, ask what number did they compute it from? If the answer is “gut feel,” or “it feels right for the pitch,” it is an input pretending to be an output.
2. Cadence. When was the date last recomputed? If it was set once and never updated, it is a wish, not a forecast.
3. Range. Is the date a point or a range? A point is dishonest about the uncertainty everyone already knows exists. A range makes the uncertainty visible and therefore manageable.
4. Displacement. If scope was added since the date was set, what got displaced? If nothing was displaced, the date silently slipped and nobody named the moment.
5. Reliability grounding. Is the date grounded in this team’s measured reliability, or in the aspirational reliability of a team that has never existed?
6. Symmetry. Is engineering’s slippage published on the same board as product’s late clarifications and business’s mid-quarter scope changes? If not, the number will be corrupted by asymmetric honesty.

If a date fails more than one of these questions, you’re input-planning. The date might still be met - people can push through - but the meeting where it got said was the moment the loop began. You’ve inherited a debt you’ll pay in headshakes and revised timelines.

The point of the test is not to embarrass whoever gave the date. It is to move the next conversation - the one that happens after this date is done, or slips - onto the right arrow direction.

Go back to the meeting from the beginning.

Someone new joins. They ask “when will X ship?” Somebody in the room pauses. This time, though, they don’t do the headshake. They don’t name a quarter. They pull up a chart with a range on it and a reliability number under it, and they say “today’s forecast is 5 to 8 weeks. Last week it was 7 to 11. Here is what changed.”

The person who asked the question does not look disappointed. They look informed. They ask the next question. It is a better question.

Same team. Same work. Same CEO. The only variable that changed was where the arrow pointed.

A date said with a headshake is a wish. A range that narrows every Monday is a forecast. Sailors know the difference. So can we.