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.
One method to explain how you can't just always add more people is to compare it to building a hotel that needs to be completed in a week.
Sure, you could add 10 more people to the project (although even that is a trade-off since that assumes that whatever they're doing is unimportant, which I've never experienced), but it's going to take a ton of time to:
- Walk them through the blueprints so they know what they're building
- Understand the current status, timeline and who is working on what
- Look at all of the current tasks and see if they can be divided up even further as there are now more people (and this isn't always possible, of course)
- Get them ramped up on to the tools and help them understand what's been built so far
And, probably, doing all of that will make the project late before they've really started. And just replace "hotel" with "project" and it's pretty much the same thing.
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"?
Let's reframe the dealine as a time-based goal. When will we try to have finished something? When shall we close the timebox and focus somewhere else? Then such a goal es very helpful.
There’s no doubt that deadlines work. However, the problem is that they can easily be misused or overused. Deadline-driven development often turns into a nightmare for teams and gives deadlines a bad reputation. The key, then, is understanding how to use deadlines effectively.
What I’ve learned is:
1. Replace "deadline" with "time boxing." Language has a magical power to shape mindsets. While the word "deadline" often evokes images of a pushy boss and unnecessary pressure, "time boxing" conveys discipline and focus.
2. Avoid punishing or blaming delays. Punishment creates a culture of fear, leading team members to add unnecessary buffers to their timelines for safety. This shifts the focus away from productivity and toward negotiating "appropriate" deadlines.
3. Break large timelines into smaller time boxes. Smaller time boxes are far easier to manage and control than a single, distant deadline. For example, time box activities like reading documentation, debugging, or prototyping.
From the triangle of options, I find playing with the scope to be the most efficient way of moving faster. I can't tell you how many times I've introduced scope bloat for no good reason, which slowed everything down.
As a PM, I'd recommend looking scope & time initially if things tend to repetitively go poorly (i.e. epics not finishing on time etc.). Resources are harder to influence on an epic-by-epic basis, particularly if you are 'just' a PM.
This is a good read. There are people who can make a deadline for themselves, but usually, people just postpone tasks and they never get done. Deadline is important. It determines the scope.
It is absolutely true! Without taking this seriously, I wouldn't have launched my first coding course last week. Despite designing multiple courses over the past two years and perfecting the topics and the examples, I never launched anything.
I was overplanning. Once I gave myself a limited time to plan, I could focus on the recording, and once the first couple of videos were done, I could finally see the end of the process.
You are right. Time constraints do help you get more done. But what if what you want to do is to explore an idea in detail. It doesn't help you get more done but may be what you want to do and it may actually lead somewhere. Curiosity leads to invention but doesn't play well with time constraints.
Super interesting post. Who should challenge the deadlines for developers? The engineering manager? Their peers? Themselves? The PM? A combination of people?
I organise my day by timeboxing all my tasks first thing when I get up. This manufactures some of the deadlines and helps me progress throughout the day; very useful.
Great article! If we consider the area of the triangle as a representation of quality, regarding overall expectations, then extending any side of the triangle leads to potentially missed expectations… if expectations are not reset.
The art of project management includes setting expectations while the science includes measuring progress, towards the agreed goals.
Setting deadlines only works when you know how to accomplish the task at hand. When there is a lot of unknowns at how to do particular task then deadline loses its restriction nature.
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.
One method to explain how you can't just always add more people is to compare it to building a hotel that needs to be completed in a week.
Sure, you could add 10 more people to the project (although even that is a trade-off since that assumes that whatever they're doing is unimportant, which I've never experienced), but it's going to take a ton of time to:
- Walk them through the blueprints so they know what they're building
- Understand the current status, timeline and who is working on what
- Look at all of the current tasks and see if they can be divided up even further as there are now more people (and this isn't always possible, of course)
- Get them ramped up on to the tools and help them understand what's been built so far
And, probably, doing all of that will make the project late before they've really started. And just replace "hotel" with "project" and it's pretty much the same thing.
Great analogy, thanks.
It's like adding team member in the middle of a three-legged race
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"?
Yes, I agree: being able to wield the tool deftly is the key.
Let's reframe the dealine as a time-based goal. When will we try to have finished something? When shall we close the timebox and focus somewhere else? Then such a goal es very helpful.
That's a neat way of phrasing it! I like it.
There’s no doubt that deadlines work. However, the problem is that they can easily be misused or overused. Deadline-driven development often turns into a nightmare for teams and gives deadlines a bad reputation. The key, then, is understanding how to use deadlines effectively.
What I’ve learned is:
1. Replace "deadline" with "time boxing." Language has a magical power to shape mindsets. While the word "deadline" often evokes images of a pushy boss and unnecessary pressure, "time boxing" conveys discipline and focus.
2. Avoid punishing or blaming delays. Punishment creates a culture of fear, leading team members to add unnecessary buffers to their timelines for safety. This shifts the focus away from productivity and toward negotiating "appropriate" deadlines.
3. Break large timelines into smaller time boxes. Smaller time boxes are far easier to manage and control than a single, distant deadline. For example, time box activities like reading documentation, debugging, or prototyping.
From the triangle of options, I find playing with the scope to be the most efficient way of moving faster. I can't tell you how many times I've introduced scope bloat for no good reason, which slowed everything down.
I've had to learn this lesson so many times that I wrote about it recently: https://alexdebecker.substack.com/p/7-signs-of-scope-bloat-i-no-longer-ignore
As a PM, I'd recommend looking scope & time initially if things tend to repetitively go poorly (i.e. epics not finishing on time etc.). Resources are harder to influence on an epic-by-epic basis, particularly if you are 'just' a PM.
I also found this interesting and true and witnessed this happening many times
This is a good read. There are people who can make a deadline for themselves, but usually, people just postpone tasks and they never get done. Deadline is important. It determines the scope.
My learning: https://glasp.co/kei/p/d438610448aa80ae6455
It is absolutely true! Without taking this seriously, I wouldn't have launched my first coding course last week. Despite designing multiple courses over the past two years and perfecting the topics and the examples, I never launched anything.
I was overplanning. Once I gave myself a limited time to plan, I could focus on the recording, and once the first couple of videos were done, I could finally see the end of the process.
Parkinson's law is a real time-saver!
You are right. Time constraints do help you get more done. But what if what you want to do is to explore an idea in detail. It doesn't help you get more done but may be what you want to do and it may actually lead somewhere. Curiosity leads to invention but doesn't play well with time constraints.
Super interesting post. Who should challenge the deadlines for developers? The engineering manager? Their peers? Themselves? The PM? A combination of people?
I organise my day by timeboxing all my tasks first thing when I get up. This manufactures some of the deadlines and helps me progress throughout the day; very useful.
Great article! If we consider the area of the triangle as a representation of quality, regarding overall expectations, then extending any side of the triangle leads to potentially missed expectations… if expectations are not reset.
The art of project management includes setting expectations while the science includes measuring progress, towards the agreed goals.
Setting deadlines only works when you know how to accomplish the task at hand. When there is a lot of unknowns at how to do particular task then deadline loses its restriction nature.