As a developer, fake deadlines drove me crazy.

I always feel responsible for delivering on time, so I used to work my ass off (weekends and nights included) just to meet a random date. And then… Silence. Nothing happens. The press release is not planned for a month yet, or another team is delayed so we just need to wait.

That was so frustrating!

Once I became a manager, I finally saw why they were needed, but felt guilty about using them.

Then, 9 months ago, I read James Stanier’s post about fake deadlines. Finally, it all clicked, and I shared that one with my team and manager.

So today, he agreed to share his take with you!

Passing the mic to James 🎤

*Non of the links are sponsored/affiliated

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 - the work that needs to be completed.

• Resources - the people and tools that are available to do the work.

• Time - the amount of time that you have to get it done.

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 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.

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.

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 the local council's tax office.

Fight the drag. Set a deadline.

Anton here - thanks James for his take. After reading it, I understood that I was doing a disservice to the team by fighting every fake deadline. It’s a powerful tool, and I was ignoring it just because I was burned by it a few times before.

Here are some mistakes to avoid:

I made sure to not repeat what annoyed me as a developer. It’s completely ok to not have anything external happen when the deadline arrives!

That doesn’t mean the effort to meet it was wasted. You built trust with the rest of the organization and you freed yourself to work on other things.

If you set the expectations right, people won’t be disappointed.

Deadlines work best when the team takes part in deciding the scope that can be achieved. It doesn’t mean you need to reach a consensus, it’s ok to take a different decision - as long as they were part of the conversation.

Imagine the frustration of starting on a project you know from day 1 you won’t be able to achieve on time. If your engineers think “If only somebody asked me…” - you failed.

The whole point of the deadline is to get the team focused on the goal. Even if you all agreed together about the achievable scope, things change.

Maybe you encountered an unexpected obstacle, or were blocked by another team for a week. Or maybe it just took more than you anticipated.

Being very strict with the rules, and priding yourself that ‘my team always delivers on time!’ can create unnecessary conflicts. It’s probably better to miss a fake deadline once in a while than make your team work extra hours and weekends (even if you pay extra).

The other side of the coin. Some managers try very hard to please their team, and are afraid to demand more from them. In some cases they even try to compensate by doing it themselves (especially first-time managers).

It’s ok to ask people to work a bit harder. It’s your job to find the right balance.

Sometimes external people will want to change the deadline (especially your PM), or add some scope. Your first instinct might be to respond by saying: “No way, we agreed to X by Y. We are not changing that right now”.

You don’t want to look stupid in front of your team, which worked hard to finish by date Y.

That’s understandable, but don’t let it drive you. Going back to #1 - people are not stupid. As long as you communicate well, they’ll understand.

1. Churn, Attrition and Decay - Mental Model by

2. The True Cost of Custom Features: 3 Painful Taxesb by

3. Product management is broken. Engineers can fix it by