What Would It Take to Go Live Next Week?

Deadlines have a strange power because they collapse theory into fact. They reveal the truth of a system faster than any meeting ever will.

We recently pulled a major migration forward by months with one question: what would have to be true for us to go live next week?

It wasn’t bravado. It was an experiment in honesty.

Within days, we uncovered issues that had been quietly waiting for someone to look. Dependencies we thought were done weren’t. Interfaces we assumed were stable weren’t. But instead of hearing these second-hand in a status meeting weeks later, we discovered them by trying to move.

The question worked because it forced clarity. We stopped talking about readiness and started testing it. The team checked what could run, what would break, and what wasn’t yet wired up. Work took on shape. Theoretical blockers became visible, and everyone could call out what still needed attention.

Projects have a way of expanding to fill the time available. The longer the horizon, the fuzzier the edges. Urgency is often seen as risk, but a short horizon creates focus. Ask what could be true in a week, and you find out what is actually standing in the way.

This approach only works when used sparingly. You cannot run every delivery in crisis mode. Teams burn out, quality suffers, and trust erodes. Some systems need deliberate sequencing. Some dependencies take time. The point is not to skip planning but to use action as a diagnostic.

Pulling a date forward means something will be unfinished. Corners will show. Some polishing will roll into the next sprint. There is a line between untidy and unsafe. The first is often fine; the second never is. The art lies in knowing which details can wait and which cannot.

Trying to go live early does more than accelerate delivery. It reveals structure, shows which dependencies are brittle, which processes are slow, and where ownership is unclear. These are truths no meeting will ever surface. But motion only helps if we stop long enough to see what it revealed. The aim is to learn, not to rush. The moment people feel it is theatre, it stops working.

For strong engineering teams, this can feel uncomfortable. They care deeply about craft. Being asked to move before everything is perfect can sound like lowering standards. And often, they hesitate for good reason, because they have seen what happens when urgency is used carelessly. It can mean after-hours callouts or last-minute fixes that could have been avoided. And yes, that cost is real. But the benefit can be greater. The act of trying exposes truths that drift unseen in long projects. More often than not, what we learn in those moments saves far more than it spends.

When I ask what would it take to go live next week?, the right answer might be nothing, we are not ready. That is fine. The point is to look, not to leap. The question gives us a shared view of what is true and what still needs care.

These experiments also surface broader truths: the gaps between teams, the bottlenecks in governance, the missing ownership around integration points. They show that coordination is a product, not an accident. Seeing those friction points early is what makes them fixable.

Engineering excellence matters, but it serves something larger. The goal is not perfection. It is delivering a better player experience sooner. Most of the time we are closer to good enough than we think, and progress depends less on certainty than on trust, in the system, the craft, and each other. A few days spent trying to ship often beats weeks of waiting to talk.