Parkinson's Law states that "work expands so as to fill the time available for its completion." Although it is counter-intuitive, you will find that through practice and experience, there is a lot of truth to this. Projects that don't have deadlines imposed on them, even if they are self-imposed, will take a lot longer than they need to, and may suffer from feature creep and scope bloat.
By setting challenging deadlines you will actually get better results. It's all about manipulating the Iron Triangle of scope, resources, and time.
If you've not come across the Iron Triangle before, the idea is that it represents the three key constraints of a project:
Scope, which is the work that needs to be completed.
Resources, which are the people and tools that are available to do the work.
Time is, unsurprisingly, the amount of time that you have to get it done. Who'd have thought?
You can't change one without affecting the others. For example, if you want to do more work, then you're either going to need more people or more time. It's the embodiment of the "pick two" rule: you can have it good, fast, or cheap, but you can't have all three.
Back to Parkinson's Law: without tight time constraints, the scope of a team's project will expand to fill the time available. This is just human nature. Just look at how long my clean washing sits in the basket before I actually put it away, or how long those little DIY jobs around the house take to get done. With no deadline, there's no urgency, and so things just don't happen.
So, deadlines work. Now, the usual hip-shoot counter to deadlines is that "fake" deadlines lead to poor work being done, and, look: there is sometimes truth to that. However, that situation occurring typically represents poor application, rather than issues with the methodology. Putting challenging timeboxes on projects in a healthy environment can lead to serious innovation and creativity. Doing the same with impossible timeboxes in a toxic environment will lead to all of the bad things that you expect.
Deadlines really help human beings get things done. The only way that I've written books is because I set myself a challenging, but not impossible, schedule with the publisher. This contract of external accountability keeps the fire going through the long slog, and it forces me to make clear-cut decisions about what to include, what to leave out, and how to manage my spare time so I make progress.
The exact same thing is true with communication and software projects.
When you are asking people to do something, lead with a recommendation of when it should be done by. Be explicit about this, but open to negotiation. It's such a simple technique, but when you compound its usage over a year at a big company, you will be amazed at the difference it makes.
Deadlines force a clear tempo and cadence and, fundamentally, they make things happen. A canonical example of this is sending round a survey that can be filled in whenever versus one that needs to be filled in by tomorrow: just by asking, you will get a much higher response rate far faster. Learn from this, and apply it to your own communication.
This tempo and cadence is crucial for effective leadership. Even though you may not think that people want it, and even if people themselves think they don't want it, knowing that things need to be done by deadlines that are just on the cusp of the comfort zone forces real, tangible progress. If you think that a prototype might take a month, why not challenge the team to see what they can deliver by the end of the week?
You will be surprised, and so will they.
To get started, be aware that humans always underestimate what they can get done in one week. See how many teams, projects, and tasks that you can inject a weekly reporting cadence into: have teams plan, execute, and report on what they've done weekly, writing up their progress in an update that is shared widely in a place that anyone can see. This discipline is energy-giving, and soon you will find that it completely reshapes how people think about their work. Your staff will actively look forward to getting things done so they can write up and share their progress each Friday afternoon.
When wielded with grace, good intentions, and knowledge of what gets humans moving and feeling good, deadlines are a powerful tool. Parkinson's Law is real, and you will need to fight it harder the larger your organization is. If you can succeed in this fight, you can grow and still ship fast with an org size of tens of thousands. If you don't, then one day you'll look around and wonder why your startup turned into the software equivalent of local council's tax office.
Fight the drag. Set a deadline.
Usually the pushback for deadlines (especially ‘fake’ once, not connected to external events) is that it’s a way to make us work harder. In reality - it’s just a way to make us more FOCUSED.
The triangle is a great concept, but often abused. Playing with the time ‘lever’ is the worst option in my opinion, that’s how you end up with never ending projects.
But the resources vertex is also problematic. I’ve experienced PMs using it, pushing back on deadlines with the argument that I can get more developers. They forget about “Brook’s law” - adding human resources to a late software project makes it later. It holds also for non-late projects - beyond an optimal number, adding more resources can be inefficient.
For example if it’s a medium sized project, and I already have 3 people working on it, adding developers from another team will just slow us down.
(If you have a tip on how to explain it to non-technical people, I’ll be forever grateful)
The best lever to use is the scope. A fixed deadline, with fixed resources, and a scope that is open to negotiation. The best PM/EM duos I’ve seen, worked that way.
I have found this particularly helpful for getting 'important, non-urgent' things done (especially on my personal to do list). Without a deadline, these high-impact strategic actions can languish due to a day-to-day focus.
Of course there is a balance: I have also seen many times that made-up unrealistic deadlines caused a lot of unnecessary suffering and demotivation. My view is that this balance is down to the skill of the individual manager in question and the specific context they are operating in: are we "delivering sustainable results to the business over time"?