Deadlines Are Not Our Friends

As Douglas Adams is famously quoted as saying, “I love deadlines. I like the whooshing noise they make as they fly by.”

Most of us have a love-hate relationship with deadlines. More particularly, we love to hate deadlines and the role that they play in our lives.

The challenge is that for many, deadlines seem to play a critical function in actually getting things done. For those who procrastinate, deadlines become a focal point that actually helps to crystallize action. Without a decline of any sort, nothing might otherwise get done. A very good friend of mine, for example, is incapable of writing without a deadline. Ask him for something on his schedule, and it will never see the light of day. Ask him for something on yours—no matter how unreasonable your schedule might actually be—and the requisite number of highly polished words will magically appear. On time.

The challenge is that deadlines are very often the primary constraint associated with organizational work. No matter how complex, challenging or critical a problem is to the on-going life and health of an organization, there is often a looming deadline behind it. Paradoxically, it often feels that the more important the problem, the more pressing and urgent the deadline is to deliver a result.

While executives may have a fetish for setting deadlines, the reality is that they aren’t overly helpful. Frequently, deadlines are a source of stress and anxiety. More importantly, we typically don’t produce our best work when we are stressed. So ramping up the pressure to deliver is not a terribly productive or helpful strategy, particularly if we care about the quality of the result that is produced.

That’s not to say that deadlines—even arbitrary ones—can’t be useful in certain circumstances. In brainstorming sessions, decision making scenarios, problem solving situations and even negotiations, a deadline can actually be helpful and constructive. Boxing the time available for brainstorming provides focus and motivation. If what is valued is moving forward—and any answer can support doing so—then dragging out the process can be counterproductive. In this context, creating a deadline can actually be constructive, in that it forces the issue and calls a halt to on-going debate.

The larger problem is when situations are more complex and uncertain. In these instances, deadlines can not only be unhelpful, but are sometimes actually counterproductive. Rather than forcing a choice between several otherwise undifferentiated and equally acceptable options, cutting short debate in these scenarios limits exploration and discussion of what possible options might be. The result is typically sub-optimal solutions that the organization is stuck with for an extend period of time.

A recent example illustrates the challenge well. An organization had committed to develop project management practices to guide project implementation, something that hadn’t existed before. While a working group was developed and there was a broad level of consultation into the problems, there was also a firm deadline of when the group had to be done. The result was that there was a strong perception that the process was being guided to a single, pre-conceived solution that everyone was expected to buy into, even though there were a number of significant concerns about the specific practices being developed.

Worse was yet to come, however. While there were many practical challenges when the new practices were implemented, and a number of specific expectations defined that did not culturally fit the organization, there was significant unwillingness on the part of the executive to go back and change what had been done. Part of the rationale for not doing so was that what was produced had been a collaborative effort. The most damning challenge, though, was that it was seen as too early to go back and revise the guidelines, as they had just been released. The deadline that had short-circuited the process up front was now also being cited as the reason to avoid change going forward.

While this is an extreme, we run into similar examples and challenges throughout our work day. I’m currently the program coordinator the presentations of a division at an academic conference. The ‘survival guide’ for the conference outlined a number of “firm” deadlines, all of which immediately went out the window when the deadline for paper submissions was extended. My work couldn’t start until papers had been reviewed and accepted, and we had also committed to collaborate with a number of other divisions regarding possible joint sessions. I finally got the list of accepted papers late on a Wednesday night, with the expectation of a final program being completed on the following Tuesday.

If I had only needed to put a program together, meeting the deadline wouldn’t have been a problem. Collaboration with two other divisions—sorting through scheduling constraints and exploring opportunities for alignment—was a completely different challenge. And until the collaborative part was finished, I had no idea what papers were left over to assemble a workable and compelling program for the remainder of sessions that I needed to fill. Miraculously, through a combination of earnest willingness to pitch in, emails at ridiculous hours and a sense of flexibility, the work got done (mostly) on time.

While some might look at that as the illustrating the power of deadlines (I didn’t think I had a prayer of getting everything done in two weeks, let alone five days) I would beg to differ. Yes, there was focus on solving the problem that probably wouldn’t have existed had there not been a looming deadline. At the same time, what got produced was suboptimal. There are efforts that could have been made and activities that could have been addressed that would have made for a much more integrative, collaborative and interesting program (if getting three divisions to work together was really the goal).

What actually happened was a lot of short circuiting, with last minute adjustments as specific constraints, issues and barriers emerged. Only a subset of papers were considered for inclusion in collaborative sessions, even though more alignment and synergy could have been found if all of the papers were considered by everyone. The essential session structure was defined by one person, and pretty much never got challenged. The rest of the focus was on problem solving and making the schedule work for each division, and for the individual speakers. While the deadline was met, and all the boxes were ticked in terms of what needed to be done, there were several opportunities to produce a better result that simply weren’t explored. The deadline drove getting to an answer that everyone could live with, not an answer that was optimal.

The challenge with deadlines, then, is two-fold. First, they force short-circuiting of the process, favouring simple and expedient over comprehensive and well thought out. Secondly, they create a disincentive for re-opening and revisiting what has already been done, on the basis that “we just did that.” You may choose to argue that deadlines have benefits in that they prevent ‘analysis paralysis’ and force the creation of closure on things that might otherwise go on. That argument is most relevant where something has to be done by a certain time, and an imperfect answer is on some level inevitable and unavoidable. If ticking the box and calling it done is your goal, then deadlines are your friend. If getting it done completely, well and thoughtfully is the desired outcome, however, a deadline is simply an obstacle waiting to create a train wreck.

As a side argument, I am equally frustrated by projects that are organized as a run on series of sequential, theoretically immovable deadlines. The program development schedule I outlined earlier is an example; the acceptance date for papers changed, and that had a cascading impact on every subsequent date which, once changed, was once again seemingly immovable. Activities in projects tend to run in sequence. There is a natural movement from one to the next, and the time required to get one activity done will determine when the next can start. At the same time, there is a natural ebb and flow to activities and work; some things will happen faster, and some will take longer. Ignoring this reality imposes unnecessarily harsh and rigid—yet unfeasible—structure.

There is a target end date that everyone is trying to hit. There are some key milestones along the way that are necessary for coordination (my coordination amongst divisions being a primary example). Being clear about what is fixed, what is simply sequential, and how coordination and communication of progress is helpful. Being arbitrarily rigid begets arbitrary and imperfect results.

The real challenge with deadlines, in my view, is that they are an attempted substitute for negotiating about process. And they are a poor substitute at that. We don’t want to talk about the work that needs to happen, how that work might be done or what conversations and interactions might be required to get there. Extensive collaboration sounds painful and time consuming (and sometimes it is). Imposing a deadline on something is a nice easy way of creating structure, avoiding the mess and making sure people don’t think too hard about things.

The next time you accept—or are tempted to set—a deadline, take the time to test how valid and viable it actually is. Is this a hard and fast stopping point, and therefore absolutely inviolate? If you think so, ask again: is it really? In my experience, there are few actual instances where dates simply cannot be moved. Where dates are fixed there is usually some externality that drives it (for example, the dates for my conference—way out in June–are fixed; my program date, all the way at the beginning of April is likely arbitrary).

If it’s an arbitrary deadline, then ask why someone is attempting to impose a deadline where something can move. Are there real coordination requirements, where a broader check-in is required with many people, where not everyone being at the same place at the same time would be problematic? Is there a critical review, where a determination on whether or not the project will proceed will be made? Again, a deadline in these instances might be valid. But if it’s a deadline for the sake of imposing an arbitrary completion date, then consider pushing back and challenging what really needs to be done and when.

This isn’t about creating arguments for the sake of challenge, any more than we should accept or condone imposing deadlines for the sake of petty tyranny. It is about asking what is important. How good a solution are we looking for, and how difficult, complex and intricate a problem are we trying to solve? How good a solution is necessary, and to what extent are we looking for an answer that is perfect, good, sufficient or stop-gap in nature? How much time, energy and effort are we prepared to invest in doing this, and when are we prepared to cut our losses?

These are the questions we should be asking and getting answers to with respect to every assignment we take on. They are the expectations we should be setting every time we ask someone to take on work for us. They are the more involved and important explorations that provide value, rather than the convenient, arbitrary and often irrelevant imposition of an imaginary stop point.