More of a strongly worded date, if I’m being honest
Deadlines are about constraints, not dates.
With apologies to The Temptations and Edwin Starr:
🎤 Deadlines (huh)
🎤 What are they good for?
🎤 As forcing functions!
I have many feelings about deadlines, but instead of ranting, let’s talk about using them constructively.
A deadline is finite and not too far in the future. Not so close that you have to scramble, not so far ahead that you can ignore it. If you have to drop everything to work on it, that’s an incident or emergency or drama. If it’s far enough out that you can focus on another project entirely, it’s a milestone or goal or a dream. A good deadline lives in the sweet spot between urgency and aimlessness.
Most deadlines aren’t scientific. They’re arbitrary dates chosen for plausibility, not intended accuracy. (More on dates that matter because consequences shortly.)
Deadlines prevent work from snowballing. They guide us to favor the clarity of the present over the speculative grandeur of the future. The siren calls of “we’ll roll this into the next sprint”, “one more refactoring”, or “let me tweak this screen just a little more” are harder to hear when there’s a deadline on the horizon. Improvements to the craft and attention to detail of our work are permissible under deadlines, but they need to co-exist within the constraints of the present.
A well-chosen deadline gives you time between finishing and delivering. Use that interim to test and get early feedback. Socialize it with the rest of the organization or preview it to people who will publicize it. Then, start on the process of turning working software into software in the hands of your customers. (You have a checklist, right?)
A deadline distinguishes between two kinds of scenarios: “we are imposing this discipline on ourselves” or “markets, regulators, competitors, or leadership are imposing this constraint on us”. The former, a date set arbitrarily because it seemed realistic at the time, is the kind of deadline I’ve been talking about so far. The latter is a different kind of tool. When there will be major consequences for missing a deadline, what you really want is a bunch of self-imposed deadlines leading up to the critical date.
Sometimes, dates really do matter. A deadline may say this work is important enough that we’re going to finish it in November even though marketing won’t promote it until February. Missing that date in February would be bad. So, we’re giving ourselves plenty of cushion to finish, deliver, iterate, deliver (again), and gain confidence that the thing won’t blow up in our face when marketing runs that big campaign.
Working to a deadline imposes a cost. You can’t rely on them to impose discipline all the time. Better to bootstrap a (team’s) sense of pace and trade-offs through a few sparing deadlines than to continuously crack the whip with them. If you find yourself feeling like deadlines are always “looming” or “hanging over you”, then you’re using them wrong.
Deadlines are never about the date, drop-dead dates aside. Instead, setting a deadline imposes a bundle of constraints that encourage acting in the present and getting stuff done. That’s a pretty good forcing function!