Writing / Hunter Harris
So Your Deadline Is Slipping
We’ve all been here - and if you haven’t yet, trust me, you will be. You’re a leader. You’ve set expectations. This year Black Friday is Nov 27. It’s the biggest day of the year for your customers. That means, it’s the biggest day of the year for you. Your Superbowl, your Olympics, your World Cup. You’ve got several projects in the works before them, but let’s call one Project X. Project X is your darling, and stands to both help your customers and make you a lot of money - especially on Black Friday.
In the interests of time, we’re going to skip around a little.
Today is September 1. The project is starting up. You’ve set a date - go live on Nov 23. The team assures you that’s more than enough time to get it done. You look forward to completion.
Today is October 9 (today-today!). The project is about midway through. You check in with the team on slack. Nothing is demoable yet, but the team tells you that’s normal. By all accounts, everything is on track. This might be the point when your gut churns just slightly.
Today is November 1. The project should be nearing completion. You check in with the team on slack. Nothing is demoable yet, but the team reassures you that it’ll happen soon. By all accounts, everything is on track. Your gut tells you something is wrong.
Today is November 16. The project really should be done by now! You check in with the team on slack. Nothing is demoable yet. By all accounts, everything is on track. You press for a demo of what’s available. You get a demo. It is wrong. Badly wrong. Your gut churns.
Today is Nov 23! The project should be live by now! You check in with the team - things are better, but they are not good, they are bad. The team tells you it will be done by Black Friday. You are an experienced leader - you now face the unenviable a choice of blowing the deadline, or YOLOing the solution to your customers on their busiest day. Your gut thrashes. You make a choice (or, you don’t, which is also a choice.)
Fast forward to Feb 7. The project is actually done and available with all features (optimistic, I know).
What the hell happened?
Top-down
First off, what the hell is a deadline? Deadlines apparently go back to the civil war and prison camps. It was a dead line - a line drawn on the ground. If you crossed it, you were shot. Pretty straightforward if you ask me.
There are deadlines, and there are deadlines. The difference is consequences. The former tends to be “I as a leader, want my team to go faster. I am going to set a deadline, and I will be upset if it is not met”. Consequences? Social strain? The latter is the example above - real business consequences. Finish X by Y for Z revenue, cost reduction, fine avoidance, and so on.
The most common way deadlines go bad starts with the former. You as a leader, pick a date. You cram it down into the organization. You pick a scope, and cram it down into the organization. You’ve probably read some business books about Responsibility and Ownership, so you saber-rattle a bit and tell people to Get It Done. No Questions, Just Do It. Chop-chop! Well, you get what you asked for - no questions, straight into execution, yes sir, we are afraid of losing our jobs!
Here’s the problem - you just started a project that was immediately off-track. The team knew, but you didn’t. Or worse, you did, and you tried unsuccessfully to wring a little more efficiency out of the team. And it didn’t work. You just did a shift right, and loosened your feedback loop - no questions means no questions, so no one can clarify scope. “Hard” deadline so there’s no place to move.
The only choice left is to just blow the deadline. And because there are no business consequences, the cost lands inside the organization. The team trusts you less (the deadline blew and nothing happened aside from Boss Got Angry - boss’s credibility got damaged). You trust the team less - they failed to step up. Maybe you ship early and things blow up, maybe you allow it to slip, but either way the hard soft deadline is a wash.
A couple rounds of this later, an actual hard deadline crops up, and the cycle repeats. At this point you, the leader, have cried wolf on deadlines several times. The team cannot tell the difference between hard and soft deadlines, because again, No Questions. This is the example from the start - you hard blow the hard deadline, and you miss real revenue. Hard deadlines always come.
Meet in the Middle
Let’s look at a different way of working.
You have some work that needs to be done. You want it done fast (who doesn’t?). Instead of picking a date and a scope and cramming them into the organization, you go chat with a leader inside your Product Technology organization - maybe it’s a Product Owner, Product Manager, Technical Lead, Architect, or CPTO. You tell them you want X by date Y. They laugh and say no way. You have a conversation.
There’s two major ways (three, but the third is a trap, we’ll cover it) to meet a deadline.
Timing
First, is change the deadline. If you’ve got a 4 month project, it generally takes 4 months to do - that’s why it’s a 4 month project. If it was a 2 week project, that’s what it would be - that’s what words mean. Which is to say, if you want a 4 month project done in 2 months, you’ll just blow the deadline by 2 months. So just move the deadline.
Of course this excepts actual hard deadlines - in this case, you have to be planning in advance. You have to have an idea of your upcoming hard deadlines, and plan for them well in advance. Personally, I like to be conservative with this one - if I know of a hard deadline within the next year I will immediately go plan for it, and usually just knock out the work required for it. This has a few advantages - first, you’re done, and you can cruise through the deadline and relax. Second, if things change, you’re already ready for the change. Third, you tend to learn important things, and you can go have important conversations around “whoops the world doesn’t actually work that way” well in advance of the deadline, allowing you to pivot before you’re under the gun. Finally, it just delights customers and unlocks revenue early. Opportunity cost is real, but usually moving things around to accommodate a hard deadline early pays off.
Scope
Second, change the scope. To go back to the prior example - a 4 month project usually takes 4 months. It doesn’t fit in 2 months. But what if the 4 month project could become a 2 month project? Applying the 80/20 rule - there’s probably 80% that’s relatively easy, and gets you 80% of the way there, and costs 20% of the time (so in this example, 24 days/ ~3 weeks!). What if you focused on getting that version out ahead of time and started gathering feedback well in advance of the deadline, then figured the rest out in post?
It might not surprise you that this is my favorite approach. I’ve generally found that selective scope cuts can deliver well over 80% of the value of the project, for 20-25% of the budget. The great thing about it is, the feedback lets you know if you even need to do the rest - you can just let it bake, and if everyone loves it, don’t juice it more than you have to.
Resources
Third, add more resources (this is the trap). It’s well known that more more people can do more stuff right? More hands make light labor and all that? Well, it’s true… to a point. But that’s more about taking an under-resourced project to properly-resourced.
Let me digress slightly. When I was a teenager, I got to participate in a festival in Japan. In this festival, portable shrines are carried at a jogging pace through the streets. These shrines weigh about a ton apiece. I want you to imagine trying to lift a 1 ton brick. It does not work. Now imagine you and the 4 strongest people lift a 1 ton brick. It does not work - you cannot lift 2000lbs. Now imagine you and 1000 other people try to lift the brick. Your share of the weight is 4lbs but it does not work because you are all stepping over each other.
How were I and a few other people able to run down the street with a 1 ton shrine on our backs then? Leverage. Teamwork. We had long poles run through the bottom, so that more people could throw the shrine on their shoulders. This allowed more people to contribute, and we had enough people to swap when someone got winded. It was still brutal, but a hell of an experience.
For most software projects, your available leverage is small - these files need these changes. AI has actually made this form of leverage smaller - instead of humans stepping on each other, agents will step on each other. So adding more people means more agents stepping on each other more. Far from ideal.
So the secret here is actually option 2 in the first place - to unlock additional leverage (to make the work more parallel), you need to change scope, to create space so resources don’t step on each other.
But even then, if the project starts off track (option 1), you’ll just scale chaos if you throw more people into the mix. Humans and agents both need context, and getting that context inflicts a startup cost. It’s well documented that adding resources to struggling projects tends to delay them rather than speed them because of this cost.
So plan properly, early, and start with the right people, and let them complete the work.
Visibility
We’ve covered planning so far, now let’s talk about reporting.
Everything comes back to fast feedback loops. Where are we? Where do we go next? A good starting point for this visibility is a weekly or biweekly update. Don’t just wait for updates, check in regularly (but not so regularly that you interrupt work).
I’m usually looking for three things: what is the scope of the project (the map), where are we (the location), and what did we do/not do the last time period (velocity). That gives me a picture - based on this rate of change, are we going to get where we want to go by the date? At this point, you’re in flight, so as we just discussed, ideally you avoid changing resources. So that leaves you week by week with a choice: do we need to move dates, or do we need to move scope? This should be a regular conversation you have.
I’m also looking for a counterpart here: a regular demo, preferably in production. This allows me to verify exactly what code is actually complete, and what that code actually does. Is it done? Is it overly complex? Does it do what is says on the tin? The proof is in the pudding as they say. There is no substitute for regular demos - and they don’t have to be user facing. Just show off progress and the cool things you’ve built.
Demos have a great function when they’re open as well - Technology tends to be divorced from the rest of the company. This is a great chance for your team to hear praise for what they’ve built and excitement over the difference it will make for others in the company and among your customers. It can be a massive morale boost.
Conclusions
Deadlines do not have to suck. If your deadlines suck, you should think carefully about why that is. Sort through which ones matter and which ones do not. And if the deadline doesn’t matter… just let it go. Focus on real revenue and real consequences. Don’t thrash your team just because you’re impatient.