Dates are coordination infrastructure

If you google engineering and deadlines, most of the writing agrees: dates don’t matter. Here’s one I read today.

There’s a version of this I agree with.

Software is hard to estimate. Unknowns show up late, work expands in ways you can’t always anticipate, and treating dates as hard commitments often leads to corner-cutting or burnout. I’ve been there.

And if a team is working well, focused on the most important thing, they will deliver what they can deliver. In that context, the exact date often doesn’t matter, and the idea that things will be done when they are is a reasonable and measured take.

That falls apart in my work immediately

The moment your work stops being primarily local, that take starts to crack. The moment your work becomes an integration point, dates matter.

Most of my work sits in the marketing platform layer. It touches the website, data, analytics, experiments, content systems, campaigns, and the teams behind all of those. Nothing ships in isolation.

A change in one place shows up somewhere else. A decision in one system creates constraints in another. Progress depends on multiple teams moving in some kind of sequence, even if loosely.

And in that world, you can’t really say things will be done when they are.

Because now:

• another team is waiting on your output to start their work
• a campaign depends on your platform being ready
• an experiment needs instrumentation in place before it can run
• a migration requires multiple teams to move in order

Dates, in this context, are not about estimation accuracy. They are about coordination.

What we’re actually disagreeing about

I had four different conversations about dates this week. In every one, I felt like we were all talking past each other.

One perspective was about:

• accuracy
• predictability
• whether engineers can reliably estimate software

Another perspective was about:

• planning
• sequencing
• how work shows up to the rest of the organization

Those are different problems.

And if we don’t separate them, we end up in conversations where everyone is technically right and still completely not on the same page.

Dates are about coordination

In the kind of work I do, marketing platform work, dates aren’t really about committing to a number. They’re about making work legible across teams.

A date isn’t just a promise. It’s a signal.

It tells other teams:

• when they can plan to depend on you
• when they need to be ready
• how to sequence their own work in relation to yours

Without that signal, everyone is either guessing or blocking.

Dates aren’t just about when something finishes. They’re about whether multiple teams can coordinate their efforts toward the same outcome. Dates are infrastructure.

What changes in practice

Once you start seeing dates this way, the goal changes.

You’re not trying to be perfectly accurate. But you also can’t afford to be wrong in a way that misleads other teams.

Because once other teams start planning around your timeline, a bad date isn’t neutral. It creates churn, rework, broken sequencing, and mistrust, teams starting too early, too late, or on the wrong thing

So the work of dates becomes something else entirely:

• setting timelines that are credible enough to plan around
• making dependencies and sequencing explicit
• updating timelines as reality changes, not waiting until it’s obvious
• being clear about uncertainty and what might move

The point isn’t to guess a date and hope it holds. It’s to maintain a shared picture of what’s happening and keep it close enough to reality that other teams can actually use it.

None of this works if dates become blame instruments. The fastest way to kill honest timelines is to punish the person who updates one. If a team moves a date early and gets treated the same as a team that misses silently, you’ll stop getting real signals, you’ll get defensive ones.

Moving at the speed of coordination

Most work that spans multiple teams doesn’t slow down because people aren’t working hard enough. It slows down because people don’t have enough shared context to make decisions or plan what comes next.

Timelines are one of the simplest ways that context gets created. Without them, teams hesitate or block.

Both things are true

Dates don’t matter in the way they teach us at school. They’re not guarantees and they shouldn’t force bad tradeoffs.

But they do matter when your work sits at the intersection of other teams. Because the value of your work isn’t just what you ship. It’s how well everyone else can move around it.

Of course dates will be wrong. The point was never to be right. The point is to keep the picture honest enough that when it shifts, everyone can shift with it. That’s the difference between a timeline and a guess.