Using fake deadlines without driving your engineers crazy(newsletter.manager.dev)
newsletter.manager.dev
Using fake deadlines without driving your engineers crazy
https://newsletter.manager.dev/p/using-fake-deadlines-without-driving
97 comments
100000%. If I was put through stress to to meet a deadline that I later found out was totally arbitrary "So that I can do more work". I would instantly lose motivation. Everything is made up and the points don't matter. Got it.
Someone should make a modern day boy cried wolf story except it’s with software engineers and fake deadlines.
don't they do it with wait-i-didn't-mean-it-layoffs and fake job interviews?
The DevOps Who Cried Deadline
Once upon a time in Silicon Valley, there was a product manager named Maxwell who oversaw a team of talented software engineers at TechNova Inc. Maxwell had a reputation for creating a sense of urgency to "motivate" his team.
"We need this feature deployed by Friday!" Maxwell would announce dramatically during Monday standups. "The investors are coming!"
The engineers would frantically work late nights, skip lunches, and cancel weekend plans. They'd push code furiously, cut corners on testing, and deliver by the deadline—exhausted but proud.
But Friday would come and go. No investors appeared. The deployment would sit unused.
"Great work, team!" Maxwell would say. "The investors rescheduled, but we're ready for them now!"
Two weeks later: "Critical deadline this Wednesday! The sales team needs this dashboard for a major client demo!"
Again, the engineers would scramble, work overtime, and deliver—only to discover the "major client" had merely expressed passing interest in a product roadmap conversation.
*The engineers began to notice the pattern*. Their trust in Maxwell eroded with each false alarm. Some started working at a measured pace regardless of the supposed urgency. Others began looking for new jobs.
During one team meeting, a junior developer named Zoe spoke up.
"These deadlines don't seem to connect to any real business need," she said. "Are we just manufacturing urgency?"
"You don't understand the bigger picture," Maxwell replied dismissively. "Sometimes we need to push ourselves to excellence."
Months passed. The team grew increasingly disengaged. They'd nod during Maxwell's urgency announcements but work at their own pace. Productivity actually improved as they focused on quality rather than rushing.
Then one day, Maxwell burst into the office genuinely panicked.
"The production server is down! Our main authentication service has been compromised! We have *three hours before all user data is exposed*!"
The engineers exchanged knowing glances. Another fake deadline.
"Sure thing, Maxwell," said the lead engineer without looking up from his mechanical keyboard. "We'll get right on that."
"No, this is real!" Maxwell insisted, his face pale. "The company could go bankrupt if we don't fix this NOW!"
But *no one moved with urgency*. Some engineers continued working on their current tasks. Others took their scheduled lunch breaks.
As the actual deadline approached, Maxwell grew increasingly desperate. He tried pulling individual engineers aside, even offering bonuses, but years of crying wolf had rendered his pleas meaningless.
The breach was catastrophic. By the time the team finally understood the gravity of the situation, it was too late. The hackers had extracted the entire customer database, including payment information and personal data for over 12 million users.
The following Monday, the once-bustling office was eerily quiet. Security guards stood at the entrance, allowing employees in only to collect personal belongings. TechNova's stock had plummeted 87% overnight. News vans crowded the parking lot.
Maxwell sat alone in his car, staring at the termination letter. His phone buzzed constantly with notifications from class-action lawsuits naming him personally. His industry reputation was irreparably damaged.
The engineers fared no better. With "TechNova" on their resumes now a scarlet letter, they faced grueling interviews where they had to explain their role in what tech blogs were calling "The Deadliest Deadline." Many would remain unemployed for months.
Zoe, who had questioned the deadline culture but still failed to act when it mattered, couldn't shake the guilt. "We knew better," she told the investigative committee. "We just stopped caring."
In the tech campuses across Silicon Valley, the cautionary tale spread quickly. Companies instituted new protocols for emergency response, but the deeper damage was psychological. In an industry built on trust between managers and builders, the TechNova incident laid bare how completely that trust could collapse.
The tragedy wasn't just the breach itself — it was that a team of brilliant people had become so desensitized to false urgency that they couldn't recognize real danger when it finally arrived. The wolf had finally come, and no one believed the cry until it was too late.
Once upon a time in Silicon Valley, there was a product manager named Maxwell who oversaw a team of talented software engineers at TechNova Inc. Maxwell had a reputation for creating a sense of urgency to "motivate" his team.
"We need this feature deployed by Friday!" Maxwell would announce dramatically during Monday standups. "The investors are coming!"
The engineers would frantically work late nights, skip lunches, and cancel weekend plans. They'd push code furiously, cut corners on testing, and deliver by the deadline—exhausted but proud.
But Friday would come and go. No investors appeared. The deployment would sit unused.
"Great work, team!" Maxwell would say. "The investors rescheduled, but we're ready for them now!"
Two weeks later: "Critical deadline this Wednesday! The sales team needs this dashboard for a major client demo!"
Again, the engineers would scramble, work overtime, and deliver—only to discover the "major client" had merely expressed passing interest in a product roadmap conversation.
*The engineers began to notice the pattern*. Their trust in Maxwell eroded with each false alarm. Some started working at a measured pace regardless of the supposed urgency. Others began looking for new jobs.
During one team meeting, a junior developer named Zoe spoke up.
"These deadlines don't seem to connect to any real business need," she said. "Are we just manufacturing urgency?"
"You don't understand the bigger picture," Maxwell replied dismissively. "Sometimes we need to push ourselves to excellence."
Months passed. The team grew increasingly disengaged. They'd nod during Maxwell's urgency announcements but work at their own pace. Productivity actually improved as they focused on quality rather than rushing.
Then one day, Maxwell burst into the office genuinely panicked.
"The production server is down! Our main authentication service has been compromised! We have *three hours before all user data is exposed*!"
The engineers exchanged knowing glances. Another fake deadline.
"Sure thing, Maxwell," said the lead engineer without looking up from his mechanical keyboard. "We'll get right on that."
"No, this is real!" Maxwell insisted, his face pale. "The company could go bankrupt if we don't fix this NOW!"
But *no one moved with urgency*. Some engineers continued working on their current tasks. Others took their scheduled lunch breaks.
As the actual deadline approached, Maxwell grew increasingly desperate. He tried pulling individual engineers aside, even offering bonuses, but years of crying wolf had rendered his pleas meaningless.
The breach was catastrophic. By the time the team finally understood the gravity of the situation, it was too late. The hackers had extracted the entire customer database, including payment information and personal data for over 12 million users.
The following Monday, the once-bustling office was eerily quiet. Security guards stood at the entrance, allowing employees in only to collect personal belongings. TechNova's stock had plummeted 87% overnight. News vans crowded the parking lot.
Maxwell sat alone in his car, staring at the termination letter. His phone buzzed constantly with notifications from class-action lawsuits naming him personally. His industry reputation was irreparably damaged.
The engineers fared no better. With "TechNova" on their resumes now a scarlet letter, they faced grueling interviews where they had to explain their role in what tech blogs were calling "The Deadliest Deadline." Many would remain unemployed for months.
Zoe, who had questioned the deadline culture but still failed to act when it mattered, couldn't shake the guilt. "We knew better," she told the investigative committee. "We just stopped caring."
In the tech campuses across Silicon Valley, the cautionary tale spread quickly. Companies instituted new protocols for emergency response, but the deeper damage was psychological. In an industry built on trust between managers and builders, the TechNova incident laid bare how completely that trust could collapse.
The tragedy wasn't just the breach itself — it was that a team of brilliant people had become so desensitized to false urgency that they couldn't recognize real danger when it finally arrived. The wolf had finally come, and no one believed the cry until it was too late.
My pet peeve is that in the boy cried wolf story in the end the wolf was real and the boy got eaten.
Imagine a real village where a boy sees a wolf and three times the villagers run out and don't see a wolf and then one day the boy cries wolf again and gets eaten — which is more likely:
1. The boy lied to the villagers about the wolf and then by a turn of fate a wolf showed up.
2. The boy actually saw a real wolf, but that wolf evaded the villagers, then the villagers let the boy get eaten and out of shame they started telling the story in a way that tells us the boy lied, even if he didn't. That boy had it coming. He always was a bit misguided — says the person who thinks death is an acceptable punishment for lying.
I find the latter way more likely and the lesson to be learned from it more profound.
Imagine a real village where a boy sees a wolf and three times the villagers run out and don't see a wolf and then one day the boy cries wolf again and gets eaten — which is more likely:
1. The boy lied to the villagers about the wolf and then by a turn of fate a wolf showed up.
2. The boy actually saw a real wolf, but that wolf evaded the villagers, then the villagers let the boy get eaten and out of shame they started telling the story in a way that tells us the boy lied, even if he didn't. That boy had it coming. He always was a bit misguided — says the person who thinks death is an acceptable punishment for lying.
I find the latter way more likely and the lesson to be learned from it more profound.
This is called the hamster wheel and destroys trust rather than builds it, ime. Maybe it communicates trust to the org? The people within the team will question the motives. One piece of advice I read early on, was don’t bullshit your engineers. They know.
I’m a big fan of value as prioritization. Work on the things that deliver value. However value is defined. Revenue, nps, etc. Ime, small companies don’t care about deadlines or they shouldn’t. They care about what’s delivering value or the next outcome. It’s only as you grow the company suddenly people want deadlines. Or you have small companies that misunderstand what their focus should be. There are obviously some time constraints that need deadlines. You can’t work on something for the holidays and deliver in Feb.
I’m a big fan of value as prioritization. Work on the things that deliver value. However value is defined. Revenue, nps, etc. Ime, small companies don’t care about deadlines or they shouldn’t. They care about what’s delivering value or the next outcome. It’s only as you grow the company suddenly people want deadlines. Or you have small companies that misunderstand what their focus should be. There are obviously some time constraints that need deadlines. You can’t work on something for the holidays and deliver in Feb.
>I'd expect that deadline to have some sort of meaning, not just "now others trust you more".
Every place of work where I saw that being pushed and accepted once, then crunch just became the new norm over time, 100% of the time.
Developers accepting the crunch to please management, signals to management that they can outsource the externalities and consequences of their bad estimations and planning onto the developers without consequences while they collect the bonuses for the deadlines being met.
While on the other hand, pushing against the crunch when/if you can, forces management to be more careful and realistic with expectations, basically to do their fucking job right.
Every place of work where I saw that being pushed and accepted once, then crunch just became the new norm over time, 100% of the time.
Developers accepting the crunch to please management, signals to management that they can outsource the externalities and consequences of their bad estimations and planning onto the developers without consequences while they collect the bonuses for the deadlines being met.
While on the other hand, pushing against the crunch when/if you can, forces management to be more careful and realistic with expectations, basically to do their fucking job right.
But they actually aren't leaving productivity on the table. This isn't an assembly line. Crunching makes you tired, and your brain slows down when you're tired. You wind up doing the same work in a 10-hour day that you would have done in an 8-hour day.
Extreme programming (XP) was all about going as fast as you can. One of the rules was, "Never work overtime for more than one week in a row." Why? Because when you're tired, you slow down. When you're tired, stop. Go home. Get some sleep. Come back tomorrow with a brain that isn't tired.
Extreme programming (XP) was all about going as fast as you can. One of the rules was, "Never work overtime for more than one week in a row." Why? Because when you're tired, you slow down. When you're tired, stop. Go home. Get some sleep. Come back tomorrow with a brain that isn't tired.
Yes, and I'd add further - this is knowledge work. Creating a mentally/emotional safe environment is going to enhance productivity more than shouting at people.
Shouting at a team is a good way to burn a day of productivity and months of built up good will. This should be obvious, and yet I still see about 20% of managers do it.
Shouting at a team is a good way to burn a day of productivity and months of built up good will. This should be obvious, and yet I still see about 20% of managers do it.
>Crunching makes you tired, and your brain slows down when you're tired.
Sure, but management doesn't care about the health of the workers, they care about line going up, for them workers are replaceable cogs. If people are too slow and tired from crunch, then it's their problem, so you put them on pip then fire them and replace them with fresh hires. Rinse and repeat. It is only a problem for them, if they manage to burn through all their cogs and have no more replacements. But then there's immigration and visas.
I've seen this twice already where I worked.
Wasn't Japan the country where people even die from overwork? If management saw this as a problem, surely they would have put an end to it by now and give workers there a French/Danish work-life balance instead to increase their productivity, but it seems like that's not how companies view productivity.
Sure, but management doesn't care about the health of the workers, they care about line going up, for them workers are replaceable cogs. If people are too slow and tired from crunch, then it's their problem, so you put them on pip then fire them and replace them with fresh hires. Rinse and repeat. It is only a problem for them, if they manage to burn through all their cogs and have no more replacements. But then there's immigration and visas.
I've seen this twice already where I worked.
Wasn't Japan the country where people even die from overwork? If management saw this as a problem, surely they would have put an end to it by now and give workers there a French/Danish work-life balance instead to increase their productivity, but it seems like that's not how companies view productivity.
Let's suppose I was a manager who only cared about line go up. And let's suppose I was able to think about second-order effects. What would I do?
I would care about not burning out my programmers. Burned-out programmers program slower, not faster. Slower doesn't make line go up. Sure, I could get faster... for a week, maybe two. After that it's counterproductive. If I don't really need it, right now, then I shouldn't do it.
Same thing with workers leaving. Sure, I could hire more, but training costs. I spent a lot of money getting the ones I have now to learn what's going on well enough to be effective. If I care about line go up, I don't want to lose those people.
Extreme Programming (XP) was all about going as fast as possible. One of their rules was "Never work overtime longer than one week in a row." Why? Because programming isn't an assembly line. Tired people miss things. They write more bugs. They just work slower. If you want to go as fast as possible, be rested. When you're tired, go home. Get some sleep. Come back with a brain that works.
Look, a decent human being should have some empathy for other human beings. But even a manager with no empathy whatsoever, if they understand, still shouldn't be making their programmers work crunch time except in very short, rare amounts.
The problem isn't just managers who only care about line go up. It's managers who do so in a clueless way.
I would care about not burning out my programmers. Burned-out programmers program slower, not faster. Slower doesn't make line go up. Sure, I could get faster... for a week, maybe two. After that it's counterproductive. If I don't really need it, right now, then I shouldn't do it.
Same thing with workers leaving. Sure, I could hire more, but training costs. I spent a lot of money getting the ones I have now to learn what's going on well enough to be effective. If I care about line go up, I don't want to lose those people.
Extreme Programming (XP) was all about going as fast as possible. One of their rules was "Never work overtime longer than one week in a row." Why? Because programming isn't an assembly line. Tired people miss things. They write more bugs. They just work slower. If you want to go as fast as possible, be rested. When you're tired, go home. Get some sleep. Come back with a brain that works.
Look, a decent human being should have some empathy for other human beings. But even a manager with no empathy whatsoever, if they understand, still shouldn't be making their programmers work crunch time except in very short, rare amounts.
The problem isn't just managers who only care about line go up. It's managers who do so in a clueless way.
No you'd just outsource to India and cycle through as many billions of souls needed.
You'd still have to bring each new hire up to speed. Still not a smart plan.
Generally people forget to consider replacement and training costs as reasons to be kind to your current employees.
I've basically never seen this happen in my career (although I live in hope).
I've basically never seen this happen in my career (although I live in hope).
Not sure why this got downvoted, management really does not care about your health. They may say things out of social niceties, but they really do not care. Maybe if it causes their cost share of your healthcare plan to go up they might, but not really.
>Not sure why this got downvoted
Because HN doesn't like comments that are blunt about harsh realities, they like a warm tone that coddles and softens the facts.
>They may say things out of social niceties, but they really do not care.
My favorite part is when companies pretend to tackle burnouts with giving their workers subscriptions to yoga or mindfulness apps, instead of you know, the sane thing that actually works, which is less workload and a less toxic work environment.
> Maybe if it causes their cost share of your healthcare plan to go up they might, but not really.
Would be nice if that were the case. I live in a country with universal healthcare, so all the externalities of burnouts get socialized from the private system to the state healthcare and welfare systems, not to the employers. It's incredibly rare that an employer here is reprimanded against stress induced onto the workers. Only if there's hard evidence proving the employer is the cause, or an employee kills themselves you might see the state looking into it and fining the employer.
Because HN doesn't like comments that are blunt about harsh realities, they like a warm tone that coddles and softens the facts.
>They may say things out of social niceties, but they really do not care.
My favorite part is when companies pretend to tackle burnouts with giving their workers subscriptions to yoga or mindfulness apps, instead of you know, the sane thing that actually works, which is less workload and a less toxic work environment.
> Maybe if it causes their cost share of your healthcare plan to go up they might, but not really.
Would be nice if that were the case. I live in a country with universal healthcare, so all the externalities of burnouts get socialized from the private system to the state healthcare and welfare systems, not to the employers. It's incredibly rare that an employer here is reprimanded against stress induced onto the workers. Only if there's hard evidence proving the employer is the cause, or an employee kills themselves you might see the state looking into it and fining the employer.
I've also noticed, especially in the last 6 months, any threads going too far in questioning paymasters here quickly gets downvoted/filtered/disappeared off main page quite quickly.
Yeah. Organically, over time, someone will step 1 day over the deadline, then 2, then 3, without any consequences. Over time, engineers will figure out the "real" deadline, and learn to ignore the useless lying manager.
the most demotivating moments in my professional life were when i just hit some manager’s deadline and the project didn’t go live for months after that, or adopted by the target consumers, etc
My manager gave me a fake deadline (pretending it was not fake, of course) and almost declined my vacation request right after it "in case I couldn't meet the deadline". I committed to finishing my work before leaving on vacation.
It was a tough deadline. I worked during the weekend and few nights before my vacation to meet it. I finished on time and left quite exhausted, but happy I made it.
NOTHING happened with my work in the next 2 months. I asked my manager and he finally said "oh yeah, the deadline is in 2 weeks"... so I asked why I had worked like an idiot before my vacation. His answer: "I did that to help you organise". I kindly told him that I didn't need his help to organise my work and that I would like him to never do that again. He answered that "I understand your feeling, but I will keep doing that, because I am convinced it helps you even if you say it doesn't". That's not the only time he screwed me like this.
I never trusted that guy again. I've seen him take wrong decisions and let him. I've seen situations where he was struggling and I could have helped, but didn't. And when he complained about bad decisions later, I happily reminded him that he took them.
A manager can choose to play with me or against me. But if they play against me, it means I play against them. And once they've brought me there, I'm not coming back in their team, ever.
It's easy to break trust, hard to rebuild.
It was a tough deadline. I worked during the weekend and few nights before my vacation to meet it. I finished on time and left quite exhausted, but happy I made it.
NOTHING happened with my work in the next 2 months. I asked my manager and he finally said "oh yeah, the deadline is in 2 weeks"... so I asked why I had worked like an idiot before my vacation. His answer: "I did that to help you organise". I kindly told him that I didn't need his help to organise my work and that I would like him to never do that again. He answered that "I understand your feeling, but I will keep doing that, because I am convinced it helps you even if you say it doesn't". That's not the only time he screwed me like this.
I never trusted that guy again. I've seen him take wrong decisions and let him. I've seen situations where he was struggling and I could have helped, but didn't. And when he complained about bad decisions later, I happily reminded him that he took them.
A manager can choose to play with me or against me. But if they play against me, it means I play against them. And once they've brought me there, I'm not coming back in their team, ever.
It's easy to break trust, hard to rebuild.
We call that "hurry up and wait!" around my parts.
Yeah, I feel like he sunk his entire post with this first learning.
What's the point if nothing happens?
It doesn't have to be "we ship to a million users".
It could be simply "The CEO will then test the flow and give their feedback".
Then, those stakeholders have to hold up their end of the bargain as well, actually use the feature, and give thoughtful feedback. If they don't reciprocate, the future of all fake deadlines is in jeopardy.
What's the point if nothing happens?
It doesn't have to be "we ship to a million users".
It could be simply "The CEO will then test the flow and give their feedback".
Then, those stakeholders have to hold up their end of the bargain as well, actually use the feature, and give thoughtful feedback. If they don't reciprocate, the future of all fake deadlines is in jeopardy.
The pressure to deliver and complete dereliction in giving feedback is what breaks the loop for engineers .. completely demotivating
[deleted]
Frankly the correct answer to the post's headline is an emphatic:
DON'T
DON'T
Fake deadlines suck. They cut against high-trust teamwork. They obscure real deadlines, including real commitments to customers.
The author writes "Once I became a manager, I finally saw why they were needed, but felt guilty about using them."
You SHOULD feel guilty. Truth matters. Trust matters.
If you're having problems with estimation and planning, then success looks like working on these areas-- not faking them.
Good tactics to try are work breakdown structures, planning poker, transparency for timelines, good project management tooling, critical chain scheduling, and above all trusting your teammates.
The author writes "Once I became a manager, I finally saw why they were needed, but felt guilty about using them."
You SHOULD feel guilty. Truth matters. Trust matters.
If you're having problems with estimation and planning, then success looks like working on these areas-- not faking them.
Good tactics to try are work breakdown structures, planning poker, transparency for timelines, good project management tooling, critical chain scheduling, and above all trusting your teammates.
I think the pragmatic consensus is: feel guilty about it; then do it anyways.
I think transparency is a good policy and helps provide context and meaning, and actually builds trust.
So "fake deadlines" aren't needed. It is perfectly OK to show the plan to the team and to explain that, for example, the committed plan is that the test team will start overall testing on 1st May so we have to deliver our software to them no later than the week before. And then you can tell the team that you set the target date in advance of that to account for any issues and delays.
Now this is a real deadline and everyone knows why it exists and why it matters.
Now, if that 1st May was a "fake deadline" set above your head at least you are 'clean' and get to keep you leadership status among your team.
So "fake deadlines" aren't needed. It is perfectly OK to show the plan to the team and to explain that, for example, the committed plan is that the test team will start overall testing on 1st May so we have to deliver our software to them no later than the week before. And then you can tell the team that you set the target date in advance of that to account for any issues and delays.
Now this is a real deadline and everyone knows why it exists and why it matters.
Now, if that 1st May was a "fake deadline" set above your head at least you are 'clean' and get to keep you leadership status among your team.
> 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.
It’s an error to work as hard as you ask your subordinates to, in service of an arbitrary deadline you cooked up just to put pressure on them?
> 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. […]
Once I became a manager, I finally saw why they were needed, but felt guilty about using them.
Perhaps it’s worth listening to that twinge of guilt. There’s nothing virtuous about tricking or cajoling people into that kind of a cadence—especially just as routine way of running your shop. Emergencies, maybe—real deadlines, maybe—but run a respectful shop and I bet people will step up when times call for it.
It’s ok to ask people to work a bit harder. It’s your job to find the right balance.
It’s an error to work as hard as you ask your subordinates to, in service of an arbitrary deadline you cooked up just to put pressure on them?
> 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. […]
Once I became a manager, I finally saw why they were needed, but felt guilty about using them.
Perhaps it’s worth listening to that twinge of guilt. There’s nothing virtuous about tricking or cajoling people into that kind of a cadence—especially just as routine way of running your shop. Emergencies, maybe—real deadlines, maybe—but run a respectful shop and I bet people will step up when times call for it.
It is not a fun reality — but in a business where profit is the goal, cadence deadlines are helpful.
When used right, they give you a good gauge on how much time the company would like you to spend on the problem. Ideally they calculated that risk higher up for the business’s needs, and you are being assigned the work for a strategy.
The frustrating part is this rarely happens in practice :) I’m working at a place now where they actually do this, and they strike the right balance: Not too demanding, but gives a good idea on the effort I’m expected to give for this, and my work clearly has an effect on the grander vision.
I can make a beautiful program in one month — or I can make some compromises and get it out by Friday. That’s programming vs. engineering.
When used right, they give you a good gauge on how much time the company would like you to spend on the problem. Ideally they calculated that risk higher up for the business’s needs, and you are being assigned the work for a strategy.
The frustrating part is this rarely happens in practice :) I’m working at a place now where they actually do this, and they strike the right balance: Not too demanding, but gives a good idea on the effort I’m expected to give for this, and my work clearly has an effect on the grander vision.
I can make a beautiful program in one month — or I can make some compromises and get it out by Friday. That’s programming vs. engineering.
That makes a lot of sense to me. I think I reacted more to the idea that fake deadlines are an appropriate technique for the purpose of squeezing people until they always scramble through their nights and weekends as a routine matter, like this guy seemed to like to do when he was on the front line.
“We’re going to spend the next two weeks working on X, so scope your ambitions accordingly—what’s realistic to expect in that timeframe?” seems like a perfectly reasonable and healthy negotiation to have, one compatible with respectful working relationships.
“We’re going to spend the next two weeks working on X, so scope your ambitions accordingly—what’s realistic to expect in that timeframe?” seems like a perfectly reasonable and healthy negotiation to have, one compatible with respectful working relationships.
Yeah I see what you mean too :) It is big suck.
This kind of behavior also rewards the wrong behaviors. A lot of "I think my team isn't working hard enough" is optics not output.
It's very easy to be performatively more busy to please these types of bosses. This does not add any value and erodes trust. It also makes me lose all respect for a manager when I feel I need to do this.
It's very easy to be performatively more busy to please these types of bosses. This does not add any value and erodes trust. It also makes me lose all respect for a manager when I feel I need to do this.
> Once I became a manager, I finally saw why they were needed, but felt guilty about using them.
The "why they were needed" is some guy with exponentially more university connections than sense trying to squeeze the engineering department for his bonus.
Don't lie to your employees, you snotball.
The "why they were needed" is some guy with exponentially more university connections than sense trying to squeeze the engineering department for his bonus.
Don't lie to your employees, you snotball.
If you draw a picture, you can spend 20 minutes, 2 hours, or 1 day and the quality will vary. Budgeting time should be a process of achieving team consensus about which level of effort will be applied for a particular job.
You don’t need to lie to have that conversation.
You don’t need to lie to have that conversation.
Yeah, it's super weird that having been on the other side they don't see the normal agile-ish process as getting you all the benefits of fake deadlines with buy-in from the developer's themselves. We planned out the work, quantized it, estimated the time for each portion, and assigned them. If someone consistently isn't completing cards in the expected time and doesn't have good reason then you have a convo with them.
Ya know, basic manager stuff.
Ya know, basic manager stuff.
Not your point, but setting and managing deadlines on when a picture from a professional artist will be delivered is an art in itself.
Yeah I think management / product / even engineers underestimate how much of time budgeting is "level of doneness" as much as "what should be done".
Stronger: You need to not lie to have that conversation.
Deadlines aren't for tech teams. Their for anal upper management more concerned with quarterly financials than deliverables and stake holders who fundamentally do not understand how tech works.
When someone asks for a deadline, the answer should be "it gets done when it gets done."
But if you are a technical who is being asked, the correct answer is the real estimated timeline + at least 2 weeks, depending on complexity.
Wasn't agile created to solve this BS? Why is this still even a discussion? I have got better things to do than waste time answering stupid questions form stupid managers.
When someone asks for a deadline, the answer should be "it gets done when it gets done."
But if you are a technical who is being asked, the correct answer is the real estimated timeline + at least 2 weeks, depending on complexity.
Wasn't agile created to solve this BS? Why is this still even a discussion? I have got better things to do than waste time answering stupid questions form stupid managers.
>Deadlines aren't for tech teams.
Uh, that's just wrong. You may have contractual deadlines for delivery that are real and meaningful, for example.
>When someone asks for a deadline, the answer should be "it gets done when it gets done."
A refusal to engage in meaningful discussions about forecasts does not free you from the obligation to meet one. You must might not like the one you get imposed on you if you refuse.
Uh, that's just wrong. You may have contractual deadlines for delivery that are real and meaningful, for example.
>When someone asks for a deadline, the answer should be "it gets done when it gets done."
A refusal to engage in meaningful discussions about forecasts does not free you from the obligation to meet one. You must might not like the one you get imposed on you if you refuse.
Please introduce me to the fantasy world where everything else can survive without deadlines and schedules.
As an engineer, I don't like deadlines either given how unpredictable large scale software development can be, but the fact of the matter is that most software is in service to a business, and businesses need to run on schedules. If you don't like that, you shouldn't be working in a software business, you should be working in a research think tank or academia.
As an engineer, I don't like deadlines either given how unpredictable large scale software development can be, but the fact of the matter is that most software is in service to a business, and businesses need to run on schedules. If you don't like that, you shouldn't be working in a software business, you should be working in a research think tank or academia.
To add, coming from a research environment (industry AI researcher turned community college professor), there are deadlines in industrial research labs and academia, too. All of my industry research projects had to fit within management-defined schedules. Back in grad school I was well knowledgeable of the “call for papers” deadlines of all the major conferences of my field, and my professors also were well aware of the various deadlines for applying for NSF grants.
I hate project estimation with a passion, especially when doing research, but I recognize that funding isn’t infinite and funders want to assess their own risks. This, we as researchers and engineers have to try our best when it comes to project estimation, even though there are so many “unknowns.”
The only situations that I could think of that are free of deadlines and estimation pressures are projects that are not on the “critical path” of a business or organization, such as a tenured professor working on a project where the outcome doesn’t negatively impact job security, or a student’s side project (like Linux circa 1991) where the only constraint is time.
I hate project estimation with a passion, especially when doing research, but I recognize that funding isn’t infinite and funders want to assess their own risks. This, we as researchers and engineers have to try our best when it comes to project estimation, even though there are so many “unknowns.”
The only situations that I could think of that are free of deadlines and estimation pressures are projects that are not on the “critical path” of a business or organization, such as a tenured professor working on a project where the outcome doesn’t negatively impact job security, or a student’s side project (like Linux circa 1991) where the only constraint is time.
This makes no sense at all. The business needs to make money to pay you. Your time is the development cost of the software. It is completely reasonable and rational for a company to say, "This is valuable to us if it can be built in three weeks, but if it takes longer, we don't want it." Because three weeks of paying your team costs a certain amount of money, and a cost higher than that puts the value of the work underwater.
If you cannot forecast whether it can be built in three weeks and then deliver against that forecast, you aren't doing your job.
> Wasn't agile created to solve this BS?
Agile sets regular deadlines for shipping to customers, that is literally the core idea. Instead of one big deadline 6 months from now, you have a small deadline every two weeks for the next 6 months. It's still a deadline.
If you cannot forecast whether it can be built in three weeks and then deliver against that forecast, you aren't doing your job.
> Wasn't agile created to solve this BS?
Agile sets regular deadlines for shipping to customers, that is literally the core idea. Instead of one big deadline 6 months from now, you have a small deadline every two weeks for the next 6 months. It's still a deadline.
You want milestones and progress over estimates and deadlines.
The value equation of a software development team isn't a product of their time and salary compared to the code/features/whatever-unit they produce. It's the theories and knowledge they build in their heads and share through the process of understanding problems and developing solutions. You can't optimize that process in a Taylorist fashion.
If there is a process called Agile that's still useful, it's built on this manifesto that eschews management in the Taylorist sense. The principles are built on a preference for organizations driven by the workers rather than the managers. It was perhaps too radical and too naive.
"It gets done when it gets done," is a glib way of saying that progress is more important than deadlines. The idea that systems take time and what's important is that people know where we're at and where we're heading more than threatening punishment for not delivering what we estimated at an agreed upon time.
The value equation of a software development team isn't a product of their time and salary compared to the code/features/whatever-unit they produce. It's the theories and knowledge they build in their heads and share through the process of understanding problems and developing solutions. You can't optimize that process in a Taylorist fashion.
If there is a process called Agile that's still useful, it's built on this manifesto that eschews management in the Taylorist sense. The principles are built on a preference for organizations driven by the workers rather than the managers. It was perhaps too radical and too naive.
"It gets done when it gets done," is a glib way of saying that progress is more important than deadlines. The idea that systems take time and what's important is that people know where we're at and where we're heading more than threatening punishment for not delivering what we estimated at an agreed upon time.
> The value equation of a software development team isn't a product of their time and salary compared to the code/features/whatever-unit they produce. It's the theories and knowledge they build in their heads and share through the process of understanding problems and developing solutions. You can't optimize that process in a Taylorist fashion.
There is no value equation for "the theories and knowledge" that developers build in their heads. Value in software happens when customers pay for software. That's how business works. It happens to be true that developers need to build theories and knowledge in their heads, but that isn't unique to software engineering and doesn't prevent deadlines from being effective.
> "It gets done when it gets done," is a glib way of saying that progress is more important than deadlines. The idea that systems take time and what's important is that people know where we're at and where we're heading more than threatening punishment for not delivering what we estimated at an agreed upon time.
I understand the argument, having heard it from teammates ten thousand times in my career. I'm somewhat sympathetic to it, but it is not a full picture of the software business. A business that fully adopts such a strategy has no long-term plan and can't make promises to customers. That can work if you lucked into all the money in the world (Google), but most of us are not so lucky and need to deliver to customers within reasonable timeframes or the customers go to someone else who can.
I get that estimation can be hard, conversations about scope can be hard, and managing expectations can be hard. I don't care. If you still have a job in this industry you are extremely well compensated to overcome those difficulties.
There is no value equation for "the theories and knowledge" that developers build in their heads. Value in software happens when customers pay for software. That's how business works. It happens to be true that developers need to build theories and knowledge in their heads, but that isn't unique to software engineering and doesn't prevent deadlines from being effective.
> "It gets done when it gets done," is a glib way of saying that progress is more important than deadlines. The idea that systems take time and what's important is that people know where we're at and where we're heading more than threatening punishment for not delivering what we estimated at an agreed upon time.
I understand the argument, having heard it from teammates ten thousand times in my career. I'm somewhat sympathetic to it, but it is not a full picture of the software business. A business that fully adopts such a strategy has no long-term plan and can't make promises to customers. That can work if you lucked into all the money in the world (Google), but most of us are not so lucky and need to deliver to customers within reasonable timeframes or the customers go to someone else who can.
I get that estimation can be hard, conversations about scope can be hard, and managing expectations can be hard. I don't care. If you still have a job in this industry you are extremely well compensated to overcome those difficulties.
If you don't care, I can't help change your mind.
I took a small company that was living contract to contract into a world where they started making millions in annual recurring revenue.
There's no secret, magic bullet. All I did was make sure we were delivering progress at a regular cadence. Kept communication channels open. And tried to, but ultimately failed at, training the sales team to stop with the secret deadline negotiation.
I understand the sales cycle at the enterprise SaaS level is a long song-and-dance of promises and and punishments. I understand that money only changes hands when the customer feels like they will get their money's worth or else your business will go out of existence. It's a difficult game to play.
However... they were never unhappy. Steady, reliable, and consistent beat out guessing, promising, and hoping to deliver every time. The dollars proved it.
I took a small company that was living contract to contract into a world where they started making millions in annual recurring revenue.
There's no secret, magic bullet. All I did was make sure we were delivering progress at a regular cadence. Kept communication channels open. And tried to, but ultimately failed at, training the sales team to stop with the secret deadline negotiation.
I understand the sales cycle at the enterprise SaaS level is a long song-and-dance of promises and and punishments. I understand that money only changes hands when the customer feels like they will get their money's worth or else your business will go out of existence. It's a difficult game to play.
However... they were never unhappy. Steady, reliable, and consistent beat out guessing, promising, and hoping to deliver every time. The dollars proved it.
I think we're talking past each other.
> I took a small company that was living contract to contract into a world where they started making millions in annual recurring revenue.
> There's no secret, magic bullet. All I did was make sure we were delivering progress at a regular cadence. Kept communication channels open. And tried to, but ultimately failed at, training the sales team to stop with the secret deadline negotiation
This is what I call hitting deadlines.
> I took a small company that was living contract to contract into a world where they started making millions in annual recurring revenue.
> There's no secret, magic bullet. All I did was make sure we were delivering progress at a regular cadence. Kept communication channels open. And tried to, but ultimately failed at, training the sales team to stop with the secret deadline negotiation
This is what I call hitting deadlines.
> I think we're talking past each other.
Perhaps. I'm not saying that deadlines don't exist or shouldn't. I am saying that they're often unnecessary and most software teams can deliver value without them.
If you're in the embedded space there's no dodging deadlines. If you need to flash ROMs it could be months before you can do a release if you miss your deadline. You might not have enough money to survive until then.
If you're shipping boring, line-of-business enterprise SaaS you don't need deadlines. Customers want software that solves their problems and are happy with something that works for 80% and a steady rate of improvements over time. They want progress and milestones. There's nothing wrong with taking an extra week or month to reach the next milestone.
Where you get the "deadlines equal dollars," mentality in enterprise software is from the long sales cycle with the big price tags. A business is going to have reservations about dropping a few hundred thousand on a new software product. And so you end up with these negotiations between sales, management, and the software teams where you're lying about the deadlines to different parties in order to keep everything in line. I don't think that's a good way to go about it.
Especially when most of the time it's not even necessary. This was the finer point I was often finding myself in opposition to the sales folks with. Their reality was that deadlines are a negotiating chip they can't ignore. The software developers' reality was that any estimate about a deadline is completely made up of hopes, dreams, and unicorns. The easiest way to get people to work together, in my opinion and experience, is to cut out the lying and just be honest.
Some organizations like that, some don't. I went back into being an IC because I just can't operate at that level and keep my sanity/energy.
Perhaps. I'm not saying that deadlines don't exist or shouldn't. I am saying that they're often unnecessary and most software teams can deliver value without them.
If you're in the embedded space there's no dodging deadlines. If you need to flash ROMs it could be months before you can do a release if you miss your deadline. You might not have enough money to survive until then.
If you're shipping boring, line-of-business enterprise SaaS you don't need deadlines. Customers want software that solves their problems and are happy with something that works for 80% and a steady rate of improvements over time. They want progress and milestones. There's nothing wrong with taking an extra week or month to reach the next milestone.
Where you get the "deadlines equal dollars," mentality in enterprise software is from the long sales cycle with the big price tags. A business is going to have reservations about dropping a few hundred thousand on a new software product. And so you end up with these negotiations between sales, management, and the software teams where you're lying about the deadlines to different parties in order to keep everything in line. I don't think that's a good way to go about it.
Especially when most of the time it's not even necessary. This was the finer point I was often finding myself in opposition to the sales folks with. Their reality was that deadlines are a negotiating chip they can't ignore. The software developers' reality was that any estimate about a deadline is completely made up of hopes, dreams, and unicorns. The easiest way to get people to work together, in my opinion and experience, is to cut out the lying and just be honest.
Some organizations like that, some don't. I went back into being an IC because I just can't operate at that level and keep my sanity/energy.
While I agree with your framing of the discussion, the fact still remains that in business there are many areas where deadlines are required both because (a) time is literally money - if you believed it would take X days to release a feature, but it ends up taking 3X, it could have been the case that, in retrospect, we never would have then implemented that feature in the first place, and (b) there are often many other people working on a project that need to be coordinated - try managing that process if every team just gets to say "it takes as long as it takes".
The industry is littered with software development teams that guessed when they could deliver something and failed.
If business can only depend on "this happens first, then that," well... they're either going to get lucky or fail.
It's just not how software development works. Knowledge work isn't a line in a Toyota factory. Scrum and agile all you want.
As someone else in another thread put it, you don't throw out your work just because it was delivered late. Knowledge is valuable regardless of how long it takes to acquire it.
If business can only depend on "this happens first, then that," well... they're either going to get lucky or fail.
It's just not how software development works. Knowledge work isn't a line in a Toyota factory. Scrum and agile all you want.
As someone else in another thread put it, you don't throw out your work just because it was delivered late. Knowledge is valuable regardless of how long it takes to acquire it.
I think the person you replied to would consider your description of agile to be === "it gets done when it gets done." Despite the term "deadline" used to describe "expected completion date" in agile they're not actually deadlines--you don't throw the work away because it's useless if it's not completed in time.
> With no deadline, there's no urgency, and so things just don't happen.
At least for private projects, this is not true. Nearly all private projects that I do are because I hate the status quo so much that the intrinsic motivation (and thus the felt urgency) is insanely high.
At least for private projects, this is not true. Nearly all private projects that I do are because I hate the status quo so much that the intrinsic motivation (and thus the felt urgency) is insanely high.
"Deadline". I hate it when a word starts to lose the exact meaning it is supposed to have!
I am not sure this is totally true, but it certainly matches the compound word itself: dead + line came from a literal line on the ground where a prisoner would be shot dead if they crossed [0]. In corporate jargon this should mean that if you fail to deliver, the project or company has severe consequences (hopefully no one literally dies). It's really annoying when terms get so watered down that they lose all meaning.
[0]: https://www.etymonline.com/word/deadline
I am not sure this is totally true, but it certainly matches the compound word itself: dead + line came from a literal line on the ground where a prisoner would be shot dead if they crossed [0]. In corporate jargon this should mean that if you fail to deliver, the project or company has severe consequences (hopefully no one literally dies). It's really annoying when terms get so watered down that they lose all meaning.
[0]: https://www.etymonline.com/word/deadline
Wow, this hits close. When I was managing teams, I put a lot of effort into making deadlines clear, measurable, fair, etc. I personally use Deadlines for everything, maybe is the ADHD coping I have the reason I like dates a lot, but is not the same when I work with others in a team
I thought I was helping my team with structure, clarity, direction. But looking back, even though we all wanted to do good work and move forward, and genuinely care about each other, something always felt off. There was this tension around "dates". I felt it. The team felt it. And we quietly resent them
Years later, I stop managing and become part of a team again, and I saw another manager approach deadlines totally differently. She talked about deadlines as "things that happen" you wanted or not, almost like happy accidents. The real focus was on creating an effect. That shift in language unlocked something for me. Deadlines became markers to check if we were moving forward, making the impact we wanted, not pursuing goals. That change made everything feel sane and more honest, and give more room to be ambitious. The day to day was the same but different, we checked whether what we were doing was aligned, and deadlines where just times to "measure" how things were going, so deadlines was something we wait for, and they were easier to negotiate, because if you have the effect or goal in mind, you move deadlines to match the outcomes we wanted, and not just avoid the deadline themselves
It's not directly on the post, but the idea is similar: it's better to use deadlines as measurement tools rather than a time to do judgment. Better to build trust through alignment and purpose.
I thought I was helping my team with structure, clarity, direction. But looking back, even though we all wanted to do good work and move forward, and genuinely care about each other, something always felt off. There was this tension around "dates". I felt it. The team felt it. And we quietly resent them
Years later, I stop managing and become part of a team again, and I saw another manager approach deadlines totally differently. She talked about deadlines as "things that happen" you wanted or not, almost like happy accidents. The real focus was on creating an effect. That shift in language unlocked something for me. Deadlines became markers to check if we were moving forward, making the impact we wanted, not pursuing goals. That change made everything feel sane and more honest, and give more room to be ambitious. The day to day was the same but different, we checked whether what we were doing was aligned, and deadlines where just times to "measure" how things were going, so deadlines was something we wait for, and they were easier to negotiate, because if you have the effect or goal in mind, you move deadlines to match the outcomes we wanted, and not just avoid the deadline themselves
It's not directly on the post, but the idea is similar: it's better to use deadlines as measurement tools rather than a time to do judgment. Better to build trust through alignment and purpose.
yes thats one way of looking at it!
I don’t think that fake deadlines are better than real ones. Fake deadlines can provide value but they indicate the environment is deficient in other ways: some sort of trust is lacking. The fake deadline is a bandaid on top of that.
I think you can get the same benefit as fake deadlines with real deadlines (ones with teeth) and without executing from an initial position of, “someone can’t be trusted so the deadline must be fake.”
I think you can get the same benefit as fake deadlines with real deadlines (ones with teeth) and without executing from an initial position of, “someone can’t be trusted so the deadline must be fake.”
> 2. Not consulting with your team about what’s feasible
Right, and the way to do this is by dividing work into easily digestible pieces that are easy to reason about, and to _feel_. Agile or lean.
> 5. Being rigid about the deadline
> 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”.
Not sure I like this definition of deadline. Seems more like a random fire up the arse.
---
Deadlines are great for one thing: coordination between departments that don't understand each others' work. If marketing and engineering are trying to make a product together, they need common grounds for getting things done and correcting course. You do this with deadlines. The deadlines might contain work to be done, to reduce risks, or planning could be just "let's see where we're at no later than this date."
Deadlines are made feasible by forcing the team to discuss the work, and ensure understanding within the competent team. Scrum planning poker provides one process (yeah, there, I said it) for that.
I once had a manger asking us line managers how to make the teams feel urgency. I guess it is indeed a question, but it's mostly a question to make fun of, not to be answered. Or at least that's how I reacted when I violently argued against this abuse of my direct reports' stress levels.
Right, and the way to do this is by dividing work into easily digestible pieces that are easy to reason about, and to _feel_. Agile or lean.
> 5. Being rigid about the deadline
> 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”.
Not sure I like this definition of deadline. Seems more like a random fire up the arse.
---
Deadlines are great for one thing: coordination between departments that don't understand each others' work. If marketing and engineering are trying to make a product together, they need common grounds for getting things done and correcting course. You do this with deadlines. The deadlines might contain work to be done, to reduce risks, or planning could be just "let's see where we're at no later than this date."
Deadlines are made feasible by forcing the team to discuss the work, and ensure understanding within the competent team. Scrum planning poker provides one process (yeah, there, I said it) for that.
I once had a manger asking us line managers how to make the teams feel urgency. I guess it is indeed a question, but it's mostly a question to make fun of, not to be answered. Or at least that's how I reacted when I violently argued against this abuse of my direct reports' stress levels.
I’ll go against the grain and say that fake deadlines are incredibly useful. They highlight unexpected costs, they force the team to bring forward hard decisions and push towards action.
It’s the same as time boxing or pomodoro. You tell yourself it’ll take an hour. An hour later, you ask yourself what did you actually do and whether it makes sense how you spent your time.
I don’t think fake deadlines should be external. Hard deadlines is for external teams depending on you like marketing or sales or a customer.
Fake deadlines are for you to check in with yourself if things still make sense or if new decisions should be made because things didn’t turn out as expected.
> 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.
This is a great thought experiment but terrible for maintainability. It’s good to discuss what happens if we need it sooner, or what we could accomplish if we had more time. It’s bad to waste a week and commit to the bad decisions we make to meet a 1-week deadline when we all think 1 month is more reasonable.
Young people have a tough time pushing back. This technique is great for senior people, but juniors are just going to burn out. You have to be super careful with your language and be pretty clear that the pressure here is hypothetical.
It’s the same as time boxing or pomodoro. You tell yourself it’ll take an hour. An hour later, you ask yourself what did you actually do and whether it makes sense how you spent your time.
I don’t think fake deadlines should be external. Hard deadlines is for external teams depending on you like marketing or sales or a customer.
Fake deadlines are for you to check in with yourself if things still make sense or if new decisions should be made because things didn’t turn out as expected.
> 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.
This is a great thought experiment but terrible for maintainability. It’s good to discuss what happens if we need it sooner, or what we could accomplish if we had more time. It’s bad to waste a week and commit to the bad decisions we make to meet a 1-week deadline when we all think 1 month is more reasonable.
Young people have a tough time pushing back. This technique is great for senior people, but juniors are just going to burn out. You have to be super careful with your language and be pretty clear that the pressure here is hypothetical.
> I’ll go against the grain and say that fake deadlines are incredibly useful.
If everyone's on board with your definition of deadline and it always works that way, then sure yeah whatever I'm not going to argue the point.
But I'd argue the "fake" in "fake deadline" is admission to deliberately exploiting information asymmetry about where exactly a "deadline" sits between the "time box" definition of deadline and the "point when we stop working because the deliverable is now worthless" definition of deadline.
If everyone's on board with your definition of deadline and it always works that way, then sure yeah whatever I'm not going to argue the point.
But I'd argue the "fake" in "fake deadline" is admission to deliberately exploiting information asymmetry about where exactly a "deadline" sits between the "time box" definition of deadline and the "point when we stop working because the deliverable is now worthless" definition of deadline.
Just drop the word "fake". They become mile markers. Be honest about it and accentuate communication.
The article would not be so controversial if it weren't outright saying "fake deadline". Of course you need a plan and a push, and stakeholders legitimately need (if only emotionally) some idea of when the builders will deliver. But on a charitable reading there are already terms for what it describes -- expected, target, soft date etc.
In my first engineering job out of college I was manipulated into working (on prem) into the early morning night, after I'd been there a few years. I couldn't help but think of that when I read
> 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.
Just being a kid and having my boss, a former professor I looked up to, expect that I could pull it off was enough. You have to be really careful "challenging" engineering reports like this -- need to actually use "see what you can do" language, NOT "deadline" (even if fake) for a 1mo->1wk timeline compression. He certainly acted surprised when I quit sometime thereafter. Hopefully he learned from the experience as well, I still appreciate my time there, just needed more experienced / realistic management.
In my first engineering job out of college I was manipulated into working (on prem) into the early morning night, after I'd been there a few years. I couldn't help but think of that when I read
> 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.
Just being a kid and having my boss, a former professor I looked up to, expect that I could pull it off was enough. You have to be really careful "challenging" engineering reports like this -- need to actually use "see what you can do" language, NOT "deadline" (even if fake) for a 1mo->1wk timeline compression. He certainly acted surprised when I quit sometime thereafter. Hopefully he learned from the experience as well, I still appreciate my time there, just needed more experienced / realistic management.
I was hoping this was a parody, god I would hate to have a manager like that.
Or, here's an idea, how about you not drive your engineers crazy by not using fake deadlines?
In the end, engineers have to deal with actual reality. Don't shove random fake stuff at us - not to motivate us, and not for any other reason.
In the end, engineers have to deal with actual reality. Don't shove random fake stuff at us - not to motivate us, and not for any other reason.
As a manager, I have never found lying to my reports to be a good strategy.
Fake deadlines are lies.
Fake deadlines are lies.
The main point of this article is that you need fake deadlines so that people don't take too much time working on things—and that's simply not true. The best teams I worked on did not have fake deadlines but still moved fast (noticeably faster than peer teams in the same org) because we felt real ownership over what we were doing; intrinsic motivation is far stronger than extrinsic motivation.
If you actually trust the people doing the work—and if you fervently believe in Parkinson's Law, you don't—you wouldn't reach for fake deadlines, you would just ask people for what you need, and give them enough context to persuade them.
You can just go and ask: "how can we get something useful out faster so that downstream team X can start experimenting with our system?". As long as you trust the team and you've managed to get the team to trust you, why wouldn't they try to do that?
I mean, there might be some real reasons not to hurry in any specific situation, but if there are you would talk about it. And maybe those reasons are strong enough that you shouldn't be trying to get something out faster just then! Or maybe there's a mismatch in your understanding of the situation that needs to be sorted out. Or maybe the team really does need to change their approach to get something out faster, even if there are real costs to doing that. Getting to that conclusion bottom-up with the team is going to be way more productive, less stressful and less trust-destroying than imposing and then missing fake deadlines.
If you actually trust the people doing the work—and if you fervently believe in Parkinson's Law, you don't—you wouldn't reach for fake deadlines, you would just ask people for what you need, and give them enough context to persuade them.
You can just go and ask: "how can we get something useful out faster so that downstream team X can start experimenting with our system?". As long as you trust the team and you've managed to get the team to trust you, why wouldn't they try to do that?
I mean, there might be some real reasons not to hurry in any specific situation, but if there are you would talk about it. And maybe those reasons are strong enough that you shouldn't be trying to get something out faster just then! Or maybe there's a mismatch in your understanding of the situation that needs to be sorted out. Or maybe the team really does need to change their approach to get something out faster, even if there are real costs to doing that. Getting to that conclusion bottom-up with the team is going to be way more productive, less stressful and less trust-destroying than imposing and then missing fake deadlines.
I don't need take deadlines to motivate me to finish a project and stop it from expanding to fill all available time. I've been on one too many of those and I'd rather accomplish something with my time.
I was given my first real important project and asked how long it might take for me to complete it. I thought I could get it done in four months but I was scared. So I said six months.
After the project was done, I was told that management didn't believe my six month estimate and put down nine months for completion in their timeline.
I finished in three. Thinking I had three months to work on personal projects, good off, etc., I eventually gave in out of boredom and told them I was finished a few weeks later.
After the project was done, I was told that management didn't believe my six month estimate and put down nine months for completion in their timeline.
I finished in three. Thinking I had three months to work on personal projects, good off, etc., I eventually gave in out of boredom and told them I was finished a few weeks later.
You need to step up your goof-off game.
Deadlines have to exist, and yet the idea that some drone said something on a call and decided on a date for work they aren't knowledgeable about or have to do and now you bust your ass / maybe take some blame if an arbitrary date isn't hit ... just kills motivation / trust / faith in other people and the organization.
Dates are important, but even outside the work, bad dates can kill a workplace.
Dates are important, but even outside the work, bad dates can kill a workplace.
Seeing a a lot of very negative responses here, and I'm not sure they're entirely deserved. To steelman the argument, I presume the author means they are using fake deadlines, but critically, telling the team they are fake - in which case I can accept much of the article. If they actually mean lying to their team on purpose, that's pretty clearly not OK to me.
They shouldn't be "fake" though. That implies that the deadlines are meaningless
Telling a team that "the deadline is May 8th, but the _fake_ deadline is May 1st" doesn't do anything for motivation, and could actually backfire since it's arbitrary. Saying something reasoned like "we need this delivered on May 8th, but we need feature development to be complete by May 1st to allow for a week of testing and deployment rollout" gives meaning to the "fake" deadline and sets up some expectations for what will happen once the "fake" deadline is reached
Of course, with proper planning, these cease to be "fake", so I guess the point is moot
Telling a team that "the deadline is May 8th, but the _fake_ deadline is May 1st" doesn't do anything for motivation, and could actually backfire since it's arbitrary. Saying something reasoned like "we need this delivered on May 8th, but we need feature development to be complete by May 1st to allow for a week of testing and deployment rollout" gives meaning to the "fake" deadline and sets up some expectations for what will happen once the "fake" deadline is reached
Of course, with proper planning, these cease to be "fake", so I guess the point is moot
Estimates are not deadlines. They never were deadlines. Real deadlines are contractual or legal - these are externally imposed, and should be communicated honestly as such, also with a clear awareness of the hard consequences of not meeting them.
It your manager does not understanding that estimates are not deadlines, find one who does.
It your manager does not understanding that estimates are not deadlines, find one who does.
This should be the opposite. Rather than having fake deadlines, consider shooting for an MVP within the given timeframe. If the MVP is reached, the remaining time can be used for further development of that same feature (extended functionality, nice-to-haves, etc). And if not, the MVP should at least have been delivered
You give me a deadline and I find out it's fake then at least one of us is going to be looking for a new job.
Just call them "internal deadlines". That communicates what they are and the consequences for missing then. That's a better way to put it than "fake" - these are real deadlines, but engineers get annoyed when the people creating then don't take responsibility for them.
Deadlines exist for a reason; they’re not just random torture. Without them, nothing would get done when things need to get done. But faking pressure with artificial deadlines? That’s a dumb move. It just pisses people off, and rightly so.
If you using fake deadlines to stress employees and force them to go the extra mile and do crunch time to meet those deadlines then that's worker exploitation.
Advocating for fake deadlines means, to me, that you aren't an effective leader and don't understand knowledge work in the least.
When I did eng. manager work I had to put up with my managers giving us fake deadlines all the time. It was a mess. Absolutely political and had no real value. It simply stressed every one out.
And no amount of, but you weren't doing it right, will convince me.
Deadlines exist but they are a social construct. They combine an agreement, an optimistic prediction of the future, and the anticipation of punishment. There are cases where they are absolutely necessary... that chip foundry isn't going to be able to flash that ROM without the code you want on it and they have orders for the next couple of years, so you better deliver the final code on time! However they are also flexible. The world isn't going to end if you need to take another few weeks to ship the feature you've been planning.
Sales is one of the bigger sources of frustration for development teams when it comes to deadlines. They're used as a negotiating chip to make buyers more comfortable with their investment. And smart sales teams have learned how to manipulate software development teams by providing fake deadlines in order to keep up appearances.
I find it all works better if folks are simply honest.
And that's why I got out of management.
When I did eng. manager work I had to put up with my managers giving us fake deadlines all the time. It was a mess. Absolutely political and had no real value. It simply stressed every one out.
And no amount of, but you weren't doing it right, will convince me.
Deadlines exist but they are a social construct. They combine an agreement, an optimistic prediction of the future, and the anticipation of punishment. There are cases where they are absolutely necessary... that chip foundry isn't going to be able to flash that ROM without the code you want on it and they have orders for the next couple of years, so you better deliver the final code on time! However they are also flexible. The world isn't going to end if you need to take another few weeks to ship the feature you've been planning.
Sales is one of the bigger sources of frustration for development teams when it comes to deadlines. They're used as a negotiating chip to make buyers more comfortable with their investment. And smart sales teams have learned how to manipulate software development teams by providing fake deadlines in order to keep up appearances.
I find it all works better if folks are simply honest.
And that's why I got out of management.
"When managers imposed fake deadlines on me, I hated it. By experience, I know it sucks. Now that I am on the other side, I choose to forget about my experience and do it anyway".
Sounds like being beaten as a child, promising yourself you will never beat yours, and do it anyway.
It seems easy to me: if you call it "fake", then you should not do it. It's never worth working nights and weekends for something that is fake. As an engineer, you do that to me once, I tell you why it sucks. Do it a second time and I will never trust you again; you have just made our relationship adversarial forever. You're the manager of course, so I can't openly go against you. I can just make your life harder everytime it's possible. Every. Single. Time.
Now in a big organisation, you can agree with the team on internal deadlines. Those are not fake: maybe you want a milestone to present to the rest of the company. Probably it matters: your team needs to show results, everybody understands that. But this is definitely not fake, everybody understands that it is internal, and it is probably more flexible than an external deadline (as in: we won't work nights and weekends if we're late, we'll just postpone it).
Sounds like being beaten as a child, promising yourself you will never beat yours, and do it anyway.
It seems easy to me: if you call it "fake", then you should not do it. It's never worth working nights and weekends for something that is fake. As an engineer, you do that to me once, I tell you why it sucks. Do it a second time and I will never trust you again; you have just made our relationship adversarial forever. You're the manager of course, so I can't openly go against you. I can just make your life harder everytime it's possible. Every. Single. Time.
Now in a big organisation, you can agree with the team on internal deadlines. Those are not fake: maybe you want a milestone to present to the rest of the company. Probably it matters: your team needs to show results, everybody understands that. But this is definitely not fake, everybody understands that it is internal, and it is probably more flexible than an external deadline (as in: we won't work nights and weekends if we're late, we'll just postpone it).
I thought this was a late april fools!
in one of the startreck movies is a sceen with "Scotty" having improbably survived into the future durring a crash by suspending himself in the "data buffers" of a transprorter, where he gives advice to a young engineer, on how to manage the expectations of his comanding officers
"ach Captain she's gona blow"
> However, that situation occurring typically represents poor application, rather than issues with the methodology.
Isn’t that what they say about communism? And every other -ism?
It’s the “no true Scotsman” fallacy as applied to experimental results. The theory isn’t wrong! The experiment must be faulty!
Isn’t that what they say about communism? And every other -ism?
It’s the “no true Scotsman” fallacy as applied to experimental results. The theory isn’t wrong! The experiment must be faulty!
This is incredibly disheartening. I would be ashamed to do such a thing. You know what people call this? Lying. If my boss did this I would immediately stop putting in the extra effort because I am not a sucker. If you play games like this do not be surprised when your good coders stop respecting you.
artificial deadlines really don’t seem to mesh with hacker and startup culture.
also, the FAANGification of HN’s posts is really a bummer. lately this just seems like a mainstream news site for large silicon valley companies and culture instead of the culture that built those companies.
also, the FAANGification of HN’s posts is really a bummer. lately this just seems like a mainstream news site for large silicon valley companies and culture instead of the culture that built those companies.
Right, this content belongs on LinkedIn (and r/LinkedInLunatics)
ah, that’s what I was trying to describe. this is a linkedin post. i really wish mods came out hard and fast against this linkedin cruft that is taking up all the space on HN. i want to see people hacking on hardware and AI and telling us how they did it or demo’ing their HACKED project.
I have a theory. If most of the heavy lifting in your thesis is done by words like "right", "accurate", "correct planning", "right outlook", then you lack details and proper analysis. I have found this to be issue too many times to count. I am sure many others might have noticed this as well.
[deleted]
At one time I worked at Oldsmobile for a summer. You know Oldsmobile - the big car company. It was a battle ground, not a car factory. I worked on the bumper line where sheets of heavy steel were crushed by giant presses into bumpers. This was long ago of course, because Oldsmobile is gone and so are heavy steel bumpers.
But it was clear that there were sides from the beginning. Management thought workers were scum and treated us that way. We thought management was scum and treated them that way.
And now American car companies like Oldsmobile are gone.
The warfare was ongoing, but there was one time that made it clear to me. The bumper line was an old fashioned assembly line of giant presses, probably twelve or so. We started with a flat sheet of metal. The first press cut it into a rough shape, the next cut some hole, the next bent a part. Each person took the incoming part off one conveyor belt, put it on their press, stamped it, took it off and put it on the outgoing conveyor belt.
When a press would break the whole line would stop, the person at the press would push a trouble light, and eventually a mechanic would come, fix the press and off we go again.
One day we had gotten to the part where the mechanics had arrived. Everyone stood around and watched as the mechanics checked the press for about twenty minutes. Everyone of us watched, as the mechanics spent twenty minutes working on the wrong press. The wrong one. All of us knew and no one said a word.
Finally, the mechanics turned on the press and it worked and they told us we could start again. At that point the guy at the broken press asked about his press.
So why? Management manipulated us, treating us like we were not capable people and not to be trusted to do the right thing. And in turn we treated them like they were manipulative, dishonest chain gang bosses.
So when you use fake deadlines, this is the road you are going down. You are on the road to obsolescence because the people you are lying to will begin to expect you to lie. Then you will be frustrated because people don't believe you. So you will treat them like the scum they are. Been there done that.
Your job should be, but probably is not, to help a team of people accomplish a common goal. Because it takes a team to do software. Actually that is wrong, even slaves can write software.
The truth is that a good collaborative team will run circles around you. So it is not that you will fail, it is that someone will come along and start developing software in 1/2 the time that is twice as good.
Feel free to repeat the mistakes of the past. However, do not be surprised when the results are the same. sigh.
But it was clear that there were sides from the beginning. Management thought workers were scum and treated us that way. We thought management was scum and treated them that way.
And now American car companies like Oldsmobile are gone.
The warfare was ongoing, but there was one time that made it clear to me. The bumper line was an old fashioned assembly line of giant presses, probably twelve or so. We started with a flat sheet of metal. The first press cut it into a rough shape, the next cut some hole, the next bent a part. Each person took the incoming part off one conveyor belt, put it on their press, stamped it, took it off and put it on the outgoing conveyor belt.
When a press would break the whole line would stop, the person at the press would push a trouble light, and eventually a mechanic would come, fix the press and off we go again.
One day we had gotten to the part where the mechanics had arrived. Everyone stood around and watched as the mechanics checked the press for about twenty minutes. Everyone of us watched, as the mechanics spent twenty minutes working on the wrong press. The wrong one. All of us knew and no one said a word.
Finally, the mechanics turned on the press and it worked and they told us we could start again. At that point the guy at the broken press asked about his press.
So why? Management manipulated us, treating us like we were not capable people and not to be trusted to do the right thing. And in turn we treated them like they were manipulative, dishonest chain gang bosses.
So when you use fake deadlines, this is the road you are going down. You are on the road to obsolescence because the people you are lying to will begin to expect you to lie. Then you will be frustrated because people don't believe you. So you will treat them like the scum they are. Been there done that.
Your job should be, but probably is not, to help a team of people accomplish a common goal. Because it takes a team to do software. Actually that is wrong, even slaves can write software.
The truth is that a good collaborative team will run circles around you. So it is not that you will fail, it is that someone will come along and start developing software in 1/2 the time that is twice as good.
Feel free to repeat the mistakes of the past. However, do not be surprised when the results are the same. sigh.
Does it usually motivate people to work hard, when they know the outcome of the crunch is "more trust with the rest of the organization" and "now I can work on other things"? Sounds pretty dystopian to me, and not all what motives me to do good work.
I think if someone pushed me to deliver something urgently to hit a deadline, I'd expect that deadline to have some sort of meaning, not just "now others trust you more". If no one actually needed that thing at that date, why was I being rushed to finish that specific thing for that specific date?