On some of the worst run projects I’ve seen, leaders trying to get them back on track would set a date.

Never, ever, in that circumstance, have I seen a date be met. No-one believes in it, no-one is willing to work overtime to meet it. It slips. Another one is set. And another. Maybe six months later something goes out.

I feel conflicted about this because I do really believe in the power of setting a date as a goal. The thing is, for this to work:

• It needs to be part of the conversation from the point when the project is defined and real.
• It needs to push people but they have to be able to reason about and with it – it can’t be a joke.
• It has to be used as a way to force decisions – what’s in, what’s out.
• It has to be part of a healthy function where in general bottlenecks get investigated and removed.

We just shipped a complete replatforming for Twill, and this is how I approached it. I set a date – July 4 – because honestly what better time to ship a big thing than when Americans are OOO and partying. The engineer I work with told me I was wrong – and I was – we shipped a month later, on August 2.

On the one hand – one month overdue, 33% of the plan. On the other hand – four months. This required us to be brutal – as the CEO puts it, I said no to every request for four months.

You can only say no to everything for four months when you have credibility and you’ve given people a baseline first. You can only keep that up for so long – you have to ship.

This might seem basic, like yes, this is the thing we’ve all agreed on for a long time. Maybe you want to cast some shade that I was off by 33%.

But here’s the thing – whatever we had thought we’d agreed, AI has upended it. More and more the date isn’t a month out. It’s today.

A week out. A month out. Far enough away to seem possible without knowing what actually needed doing. Reality would arrive. Eventually they’d stop.

The leader who sets the date today is sometimes right.

It took me a while to set a date at all. My stance was that so much had changed that my way of estimating was off base. I’m not surprised I was wrong – I know exactly what was faster and what was slower than I had accounted for.

As I write this, some Claudes are working. One of them is cutting a release. Another is running agents and churning through a list of issues. This is completely different. But I will still need to validate the release before it goes live. And later I’ll come back to yet another Claude and figure out what else is ready to go, what needs human judgement or setup. That bit is less different.

The discipline of decision-making, of reducing collisions and churn… that continues.

There’s this dissonance around “go faster” being a strategy. It’s not a strategy. It was never a strategy. But I see engineering pushing back from a stance of, I thought we agreed this was bonkers? We have to come at it by reasoning about what has changed and what has not.

For years, in engineering, we’ve worked to make the conversation about velocity rational. Now we need to do that again. Even when “go faster” is the strategy, turning engineering – now with additional token spend – into impact is still the job.