Leading in the Final Stretch: How to deliver under pressure
I was recently on a panel was asked me: “How do you manage the final weeks of a big AI project?”.
I think of releases a lot lot a show. When you put on a show - you sell tickets, the audience is showing up on Friday night, there is no alternative but to open the curtain on time. Taking that mindset into code deliveries forces conversations about scope - not schedule changes.
Most questions about “the final weeks” are really questions about projects under pressure. And here’s the problem with that: by the time a project is under timeline pressure, most of the things you can do as a manager are already gone.
So I want to split this into two things. What can you actually do at the end. And what should you be doing ahead of time so the end is manageable in the first place?
Done Is Sacred
Let me start with something I believe deeply: the word done is sacred.
Done means done. Not “done, but there’s a bug I know I need to fix.” Not “done, but that data feed still needs to—.” No qualifiers. Done is done, and not-done is not-done. That line has to be non-negotiable across the whole team.
A developer closing a story with a known bug is a story that isn’t done. A feature that works in staging but hasn’t been tested in production is a feature that isn’t done. The closer you are to launch, the more important it is that everyone shares this definition — because when people start fudging “done,” the whole release gets fuzzy, and fuzzy releases almost always go sideways.
Brooks’s Law
There’s a book that’s shaped how I think about delivery more than any other. Fred Brooks wrote it the year after I was born. It’s called The Mythical Man-Month. This book has been the bible of software development for 50 years. AI is putting a lot of the rules under pressure - but some are still relevant.
Brooks’s Law: adding people to a late project makes it later.
People hear that and think it sounds backwards. It’s not. When you add people late, you’re adding people who don’t have the context. They don’t know what broke last week or why. They come in with fresh ideas and new opinions — and right at the moment when you need fewer communication paths and more certainty, you’ve just added more of both.
What you need at the end is fewer voices, not more. You need people who can say yes or no with absolute authority. The last thing you want is a senior executive walking in with “it should also do this” energy two weeks before launch. You need the ability to shut that down completely.
The Wish List
Here’s how I handle that: I keep a wish list.
When someone comes to me with a feature request late in the cycle, I don’t say no. I say: “I hear you. I’m writing it down. It goes on the wish list.” That does two things. It tells the person their idea has value. And it makes crystal clear that it is not going into scope right now.
The wish list is one of those things that sounds too simple to matter. It matters enormously. It takes the decision out of the room — which is exactly when you need it most.
The Mode Shift
The other thing that happens at the end, and you have to be intentional about it: your team’s operating mode has to change.
For most of the project, the cycle is following a nice scrum rythym. Get a feature done, demo it, get feedback, iterate. That’s a great cycle. It’s not the cycle you need at the end.
At the end, you need a team thinking your release candidate, final testing schedule, practicing mock deployments. Who’s on the call when things go wrong? What’s the rollback plan? Is the scale plan adequate? What does the ops handoff look like? The muscle memory your team built over the last several allowing learning and iteration - has to change to saying no to additional feedback, closing conversation, making commitments that are non-movable. You have to explicitly make that shift — it doesn’t happen on its own.
Get a Release Manager
One thing I always fight for on product teams: a dedicated release manager.
The release manager’s job is to make sure there are no surprises when you go live. That means months before the release, they’re lining up infrastructure, talking to network and ops teams, running scalability tests, making sure every team that needs to know about what you’re deploying actually knows.
If you don’t have one and you’re already late — you’re probably out of luck for this release. But start now anyway. Map out documentation. Bring in your support team. Bring in ops. Walk them through everything you’re planning to deploy.
Without a release manager - bad things can happen: you’re three days from launch and everything looks green. And then you find out nobody submitted the provisioning ticket for the server allow list in production. Or the team that handles that infrastructure is overseas and the ticket will require an entire earth rotation to get done. You weren’t late. You were actually on time. And then you lose three days to something entirely preventable.
What This Adds Up To
The work of leading a release well happens long before the final three weeks. Done needs to be defined while the team still has time to hit it. The release manager needs to be in place early. The mode shift from feature development to deployment readiness needs to happen before everyone is exhausted.
Deliver. Zero surprises. That’s the job at the end.