Deadlines are a useful thing, many organizations and people use them to set goals and achieve them in an effective and coordinated way. They help to deliver.
There are a few of reasons for this:
- A deadline is a simple mental model, easy to remember. Once you learned it, it’s something that sticks.
- A deadline is easily communicated, and propagates well inside bigger organizations as a good mean to coordinate teams. Once you know that a task will be done by a date, and your work depends on that, you’re good.
- A deadline also helps to prioritize. What’s possible, what’s not possible, and push something out when it hits. It’s a productivity boost in a sense, because gives boundaries to the problem along one of the usual axis of project management (time, people, money). It supports goal setting.
That’s why it’s understandable that deadlines exist and are widespread, used in almost every team and organization. Even as individually, informally, it’s something we rely on.
Unfortunately, many organizations treat the deadline still in a similar way to the original definition:
On the inside of the stockade and twenty feet from it there is a dead-line established, over which no prisoner is allowed to go, day or night, under penalty of being shot.
— Cpt. Walter Bowie, via Origin of the “Deadline”
(We’ll ignore here the irony of a term that has its origin in prisons).
In other words, the deadline date becomes an end by itself. Everything is sacrificed to it: features, quality, sanity, stability. Communication among teams, and with clients, starts revolving around dates, instead than being around the actual goal that everyone is pursuing.
In these not uncommon scenarios, the deadline becomes a cult. People blindly stick to them, follow them, and get angry about them.
Deadlines stick even when there are zero consequences for a deadline moving.
Which means the organization is putting process ahead of actual results. Sometimes deadline exist for a good reason: there are strict dependencies and things that have to happen at a specific time. This is undeniable, and clearly when this happens it’s a strong boundary — even if probably still won’t get you killed. But these kinds of deadline are rare in most of the industries. Even when we talk about fields that aren’t software, deadlines slip, all the times. You surely would prefer to have that lift properly built and safe, instead of a building delivered on time, right?
Deadlines slip and change for a very good reason: things are impossible to forecast accurately, and the more complex things are, the less likely they are to be properly forecast. If anyone had found a way to do proper forecast, that person would be world famous, exactly like fortune tellers: if they were really able to tell the future, they would be millionaires, not fortune tellers.
I’m emphasizing this point because far too many people still believe that deadlines are something that can be set accurately and it’s a fault of the people for not doing that correctly. Others have learned to multiply any timeframe 4x-10x to get to a more accurate estimation.
Dealines as means of coordination
If instead we go back to the basics of why deadlines exist we reach a very simple understanding: deadlines exist to coordinate people in a way that is simple to propagate in organizations.
Taking coordination and propagation in mind, we are then freed to both change the way deadlines are used, or either entirely dismiss them with a different approach.
Tackling coordination, we might then decide to change the way teams are structured with a organization where each team is entirely independent and can progress their own piece of work alone. This makes every team to rely only on what’s already deployed, or otherwise activate to fill any gap, regardless of its location (note that independence here has two sides: teams acting independently and no team blocking another because “it’s our concern”). Any cross-team coordination then becomes a rarer, very different deal, because of the added cost of actually coordinating two or more teams, and the likelihood of this happening is low, because thanks to Conways’ Law, the service or product will become over time more modular thus reducing any cross-dependency.
Tackling propagation, we might throw away detailed project management tools for very fluidly updated fields on an online page – even just a simple blog! – where anyone can access it in realtime, and people that are interested can get a notification wherever a deadline changes. This suddenly shifts the issue from the tools used for planning (which, if you like, might still be Gantt charts) to how these are communicated. Which means finding better ways to keep everyone informed about it. And most of the time, organizations discover that deadlines aren’t even needed anymore because of this communication improvement.
These are just two examples, but they highlight how deadlines become a very different beast once we stop considering them immutable entities and goals on their own, sometimes to the point of disappearing entirely.
This change of mind is hard, but still easier in product companies. Working with clients might be harder, but it’s still doable if the work is, again, well communicated since early on.
Maybe, at some point we can even start calling deadlines just milestones, and throw away the “death” we have associated to them.
More sources:
- Chad Etzel (2014) How to ship without a deadline
- J. Yoon, A. Whillans, G. Donnelly (2019) Why We Don’t Ask for More Time on Deadlines (But Probably Should)