I am a developer aiming to become a manager. I want to know if the following is a valid management technique (within reasonable parameters, to be determined), I want to know how to deal with it and to use it or not.

A group of developers is given a task that has a hard deadline of one week. Everyone knows that is impossible to achieve, concerns are raised, people speak up, but the deadline stands.

One week later, of course, the task is not finished. The deadline is moved another week further, and so on...

Could this actually be a management technique to create a sense of urgency to actually get the task done in the least possible amount of time, having management knowing full well all along that the imposed deadlines are impossible to meet?

  • 14
    It's a mismanagement technique IMO.
    – Lunivore
    Commented Oct 4, 2012 at 8:45
  • 4
    Valid? No. Common? Yes. If you're aiming to become a manager, read Peopleware. It sounds cliche but it's probably the best book I've ever read.
    – Kempeth
    Commented Oct 4, 2017 at 7:08

15 Answers 15


There is a difference between "impossible" and "aggressive".

Setting "impossible" goals, ones where there is almost zero chance of success, is a fantastic way to demotivate your team in the long run because teams are being set up for failure. I've been in companies where the team will provide an honest estimation that a project will take X months to complete and management divides that by some factor as your goal because they've already made a promise or projects are always "late". This becomes a self-fulfilling prophecy because there is too little time to get the project done. Very frustrating to be in that kind of environment.

Setting "aggressive" goals, ones where there is some chance of success even if unlikely, is a reasonable approach to get the team to perform better than they would otherwise. I've been in companies that do this and it has worked well, the main downside is that you have to find a reasonable definition of what "aggressive" looks like so that you can push the team to excel without burning them out.

  • 4
    +1 on the probability of zero. The only caveat to that, in my experience anyway, is I hear so many teams scream "impossible!!" when they don't get their targets they want; yet, somehow they finish on time. Risk aversion is so variable from person to person. What seems impossible to one person is a challenge to another. Hard to really know which is going on, sometimes. Commented Oct 3, 2012 at 15:09
  • 8
    @user1220 - Every company I've worked for has had a business justification for setting impossible goals. And almost every time the long-term impacts (poor product quality, cost overruns, schedule overruns, unhappy clients) absolutely outweighed the short term benefits.
    – Doug B
    Commented Oct 3, 2012 at 15:44
  • 1
    I was not commenting on a justfiication of an impossible goal. I was talking about whether a goal was truly impossible. It has nothing to do with a justification but rather an assessment of probability and risk aversion plays a huge part in that. Commented Oct 3, 2012 at 16:08
  • 1
    On top of risk aversion, you have cognitive, beliefs, and behavioral biases to control. When estimating, you have anchoring issues, optimism biases, ignoring base probabilities, etc, affecting your results. You have to counter these. So these techniques can be very helpful when done properly. Commented Oct 3, 2012 at 16:13
  • 4
    @DavidEspina - In all probability the teams that "finished" on time for the impossible deadline did it by cutting all kinds of corners.
    – psr
    Commented Oct 3, 2012 at 17:38

The only way to get the milestones accomplished on time is when the team sets either deadline or scope.
If someone else does it (a PM), and the team did not participate in negotiation, they will simply think that the deadline is not their responsibility. You can force them to accept it, but they will be set up for failure and they will certainly fail. At least to prove you: "we've been telling you that!"
And maybe the most important criteria to tell a good PM from a bad one is their ability to negotiate on very this matter.

Iron Triangle

Look at the Iron Triangle. The more balanced it is, the higher the quality of your product. You can stretch any axis, but not all. Leave one for the team, and they will do their best to keep their promise.

Actually, there are two typical cases as the team usually don't rule the resources:

  1. "We need this scope done" - then your team tells you when they can accomplish this. If their deadline is not satisfactory, re-define the budget.
  2. "We have a presentation on this date" - then you have to agree with your team what will be done by that date.

In other case, you should think on increased budget, e.g. hiring additional people, buying tools, etc.

  • 5
    Excellent answer - goes beyond the question to point out (one of the) underlying causes of the problem, and then goes beyond that to offer advice on how to resolve the problem.
    – MCW
    Commented Oct 5, 2012 at 14:21
  • 1
    Seconded @MarkC.Wallace. I would just add that a well-functioning, trusted team will be able to help with all three axes, by for example referencing similar tasks they have done before and comparing the outcome of those to what the business needs in this case.
    – l0b0
    Commented Oct 25, 2020 at 8:13

Of course it's a management technique. And at the risk of down-votes, it's used all the time. It's a function of Parkinson's Law, also known as the Student Syndrome - work expands to fill the time available.

If a team is given two weeks to finish a task that could be done in week, it will take the full two weeks. And before anyone attacks, there are any number of reasons for this, not all of which point to failure on the part of the team.

Management hedges against this. They have a task that HAS to be done it two weeks. They say 'one week', knowing they have a buffer of one week.

The Critical Chain Method is based almost entirely on this principle. It takes estimates, cuts them in half, gives the team the shortened time, and then banks the remaining time as 'buffers".

This doesn't mean it's a good technique, but it's also not a bad one. Sometimes it needs to be used. Those teams that are 'self-organizing' and always working at optimum speed and efficiency are rare.

  • 3
    Its the deception aspect of such a tactic that bothers me the most. If I found out a single time that such deception had been practiced, I would never, ever, believe a deadline from management again. Why would I? Commented Oct 3, 2012 at 22:05
  • 3
    @aclear, I understand your point, and to an extent agree. You said that if this deception was used on you once you'd never trust them again. But let me offer a counterpoint and illustration - suppose I assign you a task and you tell me it will take 4 days. If it then takes 5, am I now entitled to 'never trust your estimates again'? You see, it's not quite so cut and dried. We'd all like to work in a transparent world, but it's not always feasible. I'll also clarify that a lot of this depends on the type of work. You'll find it more prevalent in more hourly wage type jobs. Commented Oct 3, 2012 at 23:34
  • 3
    "They have a task that HAS to be done it two weeks. They say 'one week'." This is intentional deceit, not a poor estimation. Commented Oct 3, 2012 at 23:39
  • 6
    My point was, both sides hedge to protect themselves. If mgmt NEEDS it in two, they say one, allowing for slippage. Devs and contractros do the same thing - you know that if pushed you could do it in 4 days, but you say 5 ( 1 day buffer), just to protect yourself and make sure you can do it. It's not deception (on either side), it's 'risk management'. You want to make sure you deliver as promised, and mgmt is doing the same on the client side. One other point - I noticed that the only consequence was that the deadline was pushed, no penalties or punishment. This tracks with my thinking. Commented Oct 3, 2012 at 23:56
  • 2
    This is a result of the often used phrase "under promise and over deliver." Not only is this an accepted (and encouraged practice in most organizations, but also across multiple industries.
    – KirMasAna
    Commented Oct 4, 2012 at 17:58

I feel sorry for anyone tasked with maintaining or altering any software created in such a manner.

Is it possible to create software like this? Sure. You leave out the following things:

  • Unit Tests

  • Code Reviews

  • Refactoring

  • Architecture Enforcement

A team that skips these steps, and gets very good at skipping them can deliver new software at amazing rates. Right up until technical debt smacks them in the face. It will happen sooner or later.

And here's the worst thing about skipping these: as a PM, you'll have no idea that the product is un-maintainable until it is too late. You won't be able to tell that what was created is a hack, because most developers are quite good at making a hack work. Kind of.

When the technical debt starts to pile up, everyone will start screaming legacy code this, and legacy code that (when they were the ones who wrote it in the first place), and the tempo will fall off completely. Your good developers will go somewhere else, you'll blame them for making a bad product, and pretty much everyone involved will be unhappy.

So no, I don't think it is a legitimate managing technique. Unless of course your aim is to churn out an unmaintainable product, make a profit, and then go out of business. Getting the task done in the least amount of time possible is almost always a horrible metric of project success.

Edit If there actually is a hard deadline, then be honest with your team and tell them what that deadline is. Treat them like professionals, and expect them to be honest with you about whether or not the deadline is feasible. Either party being dishonest in this process will result in a downward spiral of lies and suspicion.


Asking the Wrong Question

Is imposing “impossible deadlines” a Management Technique?

Yes, it's part of the management framework henceforth known as Epic Failure™. It's right up there with flogging a dead horse, deliberately planning a death-march, and telling people to "work harder, not smarter."

That doesn't mean it isn't practiced as a management technique. Many, many companies do exactly what you've described. However, you're asking the wrong question. The right question isn't whether it's a management technique or not, but it's whether it's an effective one.

How People Address Impossible Deadlines

When faced with impossible deadlines, some common things may happen. For example:

  1. People ignore ridiculous and arbitrary deadlines, and continue doing whatever they normally do.
  2. People try to meet unrealistic deadlines, burn out, and move on to other projects and/or companies.
  3. People speak up, get singled out as "not a team player," and shrink the collective IQ or skill set of the team when they get drummed off the project.

This isn't an exhaustive list; I'm sure you can think of others. The end result, though, is typically a failed project. The mere use of this management technique is often a "project smell" that a project is currently failing, or is just about to fail, so it's a useful signpost that intervention is urgently needed.

My Personal Response to Ridiculous Deadlines

When faced with the Epic Failure™ management technique, I have actually said the following to various people in my professional life:

I've given you my very best professional estimate. If you prefer to apply a different metric, just subtract your deadline from my projected delivery date; that will tell you approximately how late the project will be.

A few people have appreciated the refreshing honesty over the years, but most Epic Failure™ practitioners do not. There are certainly consequences to being so outspoken, but one of the positive consequences is that I haven't been on a single involuntary death march in the past twenty years. Your mileage will certainly vary.


I am a developer who is studying project management as well.

It is a technique, but it is not an effective one if you want a top quality team.

Estimates need to come from the developers who are actually writing the code. It is the team lead's job to make sure that the estimates are reasonable to the skill of the developer, complexity of the task and quality of results that are expected.

Keeping everybody perpetually under the gun will result in an unhappy team and very likely will result in the loss of your most important people.

If I am asked how long something will take, then I will provide an estimate that is as accurate as I can make it. If my boss then tells me that I have half the time I estimated then I have 3 options:

  • Work extra long hours with no extra pay and push myself closer to burnout. Studies have shown this to be ineffective in the long run.
  • Cut quality. There are lots of ways to do this, leave bugs in the code so that you will be allocated time later to fix them. Don't unit test, don't comment, etc.
  • Take longer than the time that I have been allocated and think a bit less of my project manager or boss, because they clearly don't respect me as a developer.

I can't see how any of those options would come from a good management technique.

  • 2
    Good points. I also note that people start to become a lot more passive aggressive and the overall mood is really bad.
    – user1220
    Commented Oct 13, 2012 at 21:50
  • 1
    +1 When faced with such events, I fall in the 3rd option. If you are doing the job, why have the PM to estimate the time? This falls in a Taylorism management, used in industry over the "eras", assumes that employes are unqualifyed and irresponsible and have to be "tailored" to met the company expectations. Commented Oct 15, 2012 at 21:09

Overall, management by task deadlines is not a good idea. It leads, among other things, to student syndrome.

A better approach is Goldratt's critical chain method.

In critical chain, tasks are estimated at 'aggressive but possible' durations, however, there is NO EXPECTATION that such estimates will be met. In other words, there is a clear separation between estimations and commitments.

What is committed is the project end date. In order to protect it from unavoidable overruns of aggressive estimates, a project buffer is added to the end of the project. Buffer consumption is then monitored against project completion to assess whether the project is in green, yellow or red zone. This information is a basis for active project management.

For an excellent introduction, see the novel 'Critical Chain'.


This sounds quite severe and I would think the consequences of this kind of approach would not be favorable overall. However, there is a benefit of a challenge like this. The critical chain method is based on this concept to a degree.

Finishing any type of task is not deterministic. In other words, you cannot say that doing a task will take 15 days each and every time you do it. Task completion is probabilistic, where most variables that affect your final result are random, uncontrollable, and unseen. Therefore, a more precise estimate of completing a task would be a range of results with some type of probabilistic distribution on top of it.

Completing on time and within budget are two metrics that we have a tendency of putting too much weight on. So much so that it can be reasonably expected that we would target on the pessismistic side of both targets in order to increase our likelihood of being a "success." The benefit to this would, of course, that you will not overrun your targets except in extreme circumstances. The cost to this is, well, increased costs. And, since you built in the time and budget, due to things like Parkinson's Law and Student Syndrome, it is highly likely your team will use every bit of available time and budget to complete the work that would have otherwise taken less time.

So, there is, in my opinion, some efficacy to "challenge" the team by condensing the time and budget and pushing for better results.

What is better: To target 20 days and come in at 19, a favorable 1 day variance; or target 13 days and come in at 15, a two day unfavorable variance? If you don't have these type of challenges, the latter will never come true.

  • Thank you for an insightful answer. Regarding the last paragraph - here's what I suspect may be happening. "Targets" are different depending who you ask. For example, the CEO asks for such task. The CIO tells him, we can do it in three weeks, and informs the PM that he has two weeks to finish. The PM then tells the team, one week - that's all you have. So if it takes 2 1/2 weeks, the CIO is the one looking good on all this. If it takes 1 1/2 weeks both the CIO and the PM are in good shape. And all this time the team is under a lot of pressure and under the "challenge" you mentioned.
    – user1220
    Commented Oct 3, 2012 at 14:54
  • That sounds very sneaky but I can see how that can happen. Pressure is both good and bad. Some pressue can yield great results with both the project as well as with moral, team confidence, growth, etc. And, of course, too much it can cause team decompensation. Tough balance to achieve. Commented Oct 3, 2012 at 14:57
  • Thank you, David - sneaky but effective if used smartly it looks like. Of course there is a chance of burn out and mistrust of management if the use of such "technique" is divulged in some way.
    – user1220
    Commented Oct 3, 2012 at 15:00
  • I have not observed Parkinson's Law taking place in practice. (I have seen developers making stuff up when they don't have real work to do, with results that are only rarely worthwhile). It does seem like it might not be a coincidence that if Parkinson's Law were true there would be more call to hire project managers, and it is something project managers usually have great faith in. I have observed project managers believing Parkinson's Law was in effect - usually because enough pressure caused developers to cut corners in ways they couldn't immediately detect.
    – psr
    Commented Oct 3, 2012 at 17:44
  • "I have seen developers making stuff up when they don't have real work to do, with results that are only rarely worthwhile" That would likely be evidence of Parkinson's Law. Notwithstanding this, it would be difficult to see it in effect on a single observation...a single project. This phenomena was observed over many years of government work. Commented Oct 3, 2012 at 17:54

I work at a company which often has very tight, and very impossible deadlines. One thing I've found is that if you tell people they /must/ produce results in 1 week, they can pull it off but they will cut corners because that's the only way to reach the deadline.

Here is what happens with an impossible deadline: people rush to meet it. People do as much as they can as quickly as possible and cut out all perceived non-important steps. At the end of the week you have results, but they were created with cut corners and last-minute patches. When you then say "actually the hard deadline is /next/ week so you can get it done properly" the entire project has to essentially start from scratch with people trying to patch up the shoddy work they did just to roll it out in time. It doesn't create a sense of urgency so much as create projects with numerous short-cutting errors and a very inefficient edit-and-re-edit process.

In my company, seven people have left in the last three months. Very, very high turnover because nobody can stand working like that.


This is a recipe for high turnover, since the team will implicitly know:

When you finish a project with an unrealistic deadline, your reward is another project with another unrealistic deadline. http://lifehacker.com/dont-always-aim-to-meet-unrealistic-deadlines-1444834485

It can also have unintended consequences:

Estimates are also not usually updated once the team realizes that a task is behind. The engineer(s) will typically try to speed things up and do more faster, or work longer hours and weekends. In the first case, they can’t suddenly multiply their productivity, and there would be a significant quality loss and risk of missing requirements even if they could. In the later case, this is the fast lane to burnout and reduced overall productivity from lack of downtime, rest, etc. https://www.innoarchitech.com/why-software-development-time-estimation-does-not-work-alternative-approaches/

And produce an inferior product:

Unrealistic time estimates and the subsequent perceived date commitments can also incentivize the wrong things. They incentivize speed, which often results to reduced quality, increased defects, missed requirements, rework, unhappy customers and CS staff, technical debt, and additional maintenance cost and time. https://www.innoarchitech.com/why-software-development-time-estimation-does-not-work-alternative-approaches/

There is no good rationale for such a metric:

The problem is that velocity and/or software development estimates rarely involve probabilities and statistics, and yet must. The resulting estimates are therefore nonsense since we try to deterministically produce the value of a stochastic random variable. This would be considered a laughable practice by any statistician. https://www.innoarchitech.com/why-software-development-time-estimation-does-not-work-alternative-approaches/

And no historical context by which a precedent can be set:

In practice, an engineer (or team) decides on an approximate lead time based on gut feel, experience, educated guess, etc. This process requires almost zero actual time. Once decided, the task is worked on and the actual lead time is recorded once complete, along with some way to categorize the relative size for the task. Over time, a data set is created that allows for statistical analysis and much more realistic estimates (lead times) and due-date performance metrics. https://www.innoarchitech.com/why-software-development-time-estimation-does-not-work-alternative-approaches/

Which is the opposite of the true goal:

Remember that no one else cares and no one else matters. Most people are so wrapped up with themselves that they won’t notice any "slip" on your part. Let your desire to impress others go, and decouple your performance from your sense of self-worth. http://webstandardssherpa.com/reviews/breaking-the-perfectionism-procrastination-infinite-loop/


  • @MarkC.Wallace three sources are listed at the bottom. Do you mean internal citations? Commented Jul 20, 2017 at 13:46
  • There is no way for me to tell which of the internal quotes is from which of the referred to works. - if I wanted to quote "remember that no one else....", I wouldn't know which citation I would use..... The answer is high quality - but my inability to tie quotes to references makes me uncomfortable about relying on them.
    – MCW
    Commented Jul 20, 2017 at 14:46
  • 1
    @MarkC.Wallace Done. Searching for the quoted phrase would return the original URL in case of link rot. Commented Jul 20, 2017 at 15:08

Within technology, one of our responsibilities is to provide options. If management sets a deadline, it is our responsibility to provide options for how this can be accomplished (variance to minimal viable product, people, etc). Use data to tell the story, not subjective opinions. In my experience, a "business person" (read manager/execitive) will find ways to go around you, through you, behind you, any way to get what they need done. By providing options (backed by data) with costs/cost impacts for alternatives outlined and giving them a thoughtful response, you make it a business decision, not a technology capabilities decision.

I have worked for a CEO who regularly set the bar very high just to see if people would step up. I asked him why he did this and he replied that people generally sell themselves short, tell themselves all the ways it can't be done. By setting the bar high, you will find out what people are capable of given the right environment.


In short, what you want to set is a Timebox, not impossible deadlines. Impossible deadlines are highly demotivating, as developers usually know when a deadline is impossible. If you keep using and pushing impossible deadlines just to scare them, soon it'll become useless.

Setting a timebox is a more formal way to do that. You're telling your team that you are with them, but you don't have all the time/budget available, so at the end of the timebox, what was done is either accepted and pushed into production or simply rejected. Keep in mind that who makes estimations come true are developers, not managers. You want the best that can be done in X weeks, not shrink Y months in X weeks, as this usually leads to catastrophic results.


On paper, it sounds like incompetence on the part of management.

On the other hand, it is part of mainstream culture. Hard Drive talks about how agressive Microsoft was in getting early contracts. Renegades of the Empire suggests this is actually a strategy to keep people perpetually never satisfied.

Many young developers have never failed at anything in their lives, and companies prey on this insecurity. It's not sustainable, but neither are many other bad management practices.


I know there are already 15 answers to this question, but I see an important factor not being discussed:

Under normal circumstances, impossible deadlines is not a sensible nor a sustainable management technique, unless you're aiming for low-quality software and high employee churn.

But, in emergencies - when the team needs to be put in crisis mode - then impossible deadlines is the most effective way to patch a problem ASAP.

It sends a clear message to the team that overtime is expected (and hopefully rewarded) and that the aim is to get the job done and leave the frills, bells & whistles for later.

So, what is normally a disastrous idea, can be very effective if used rarely and when everybody involved understands the urgency.


Sounds like a project that is out of control and management that will soon burn-out its personnel from too much of the "boy who cried wolf."

  • Maybe not, that's why I ask. When asked, developers may give you what some may consider an inflated estimate; so you preempt and give them a hard deadline, we need to get the business, we need to get it done - do the best you can. I agree however that over time it may create burn out and people may leave. Or some will understand the game and simply be professional, do it properly, during business hours, creating something of quality and not really caring about the so-called hard deadline.
    – user1220
    Commented Oct 3, 2012 at 15:18
  • Your question states that the deadline comes from management down without input from the developers or a leadership/vision message. But more to the point, the minute you start to play "the game" you lose control of a project and credibility with people. Effective management is based on reality, not games. Commented Oct 3, 2012 at 15:22
  • 1
    Yes, that's how I see it coming - straight down from management, damn the torpedoes. And I agree, I can see the fabric of the group tearing down. However my question still is - is this some sort of "management technique" where management weighs the pros and cons of burnout versus getting a project done?
    – user1220
    Commented Oct 3, 2012 at 15:26
  • I'd call it a "mis-management technique" :-)
    – Doug B
    Commented Oct 3, 2012 at 15:46
  • Perhaps you could clarify as to why it is important if this is a "management technique" or not. What is the specific problem you are trying to solve? Commented Oct 3, 2012 at 15:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.