Using fake deadlines without driving your engineers crazy
95 comments
·April 2, 2025diggan
frakt0x90
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.
deadbabe
Someone should make a modern day boy cried wolf story except it’s with software engineers and fake deadlines.
m463
don't they do it with wait-i-didn't-mean-it-layoffs and fake job interviews?
BuggieSmalls
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.
atoav
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.
mroche
[flagged]
memhole
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.
mystifyingpoi
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.
mylons
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
palata
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.
stronglikedan
We call that "hurry up and wait!" around my parts.
aantix
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.
steveBK123
The pressure to deliver and complete dereliction in giving feedback is what breaks the loop for engineers .. completely demotivating
FirmwareBurner
>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.
AnimalMuppet
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.
steveBK123
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.
FirmwareBurner
>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.
null
jasonm23
Frankly the correct answer to the post's headline is an emphatic:
DON'T
jph
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.
josfredo
I think the pragmatic consensus is: feel guilty about it; then do it anyways.
mytailorisrich
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.
alwa
> 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.
lanyard-textile
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.
alwa
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.
steveBK123
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.
lenerdenator
> 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.
grandempire
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.
makeitdouble
Not your point, but setting and managing deadlines on when a picture from a professional artist will be delivered is an art in itself.
steveBK123
Yeah I think management / product / even engineers underestimate how much of time budgeting is "level of doneness" as much as "what should be done".
AnimalMuppet
Stronger: You need to not lie to have that conversation.
Spivak
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.
game_the0ry
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.
Hasu
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.
agentultra
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.
Hasu
> 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.
hn_throwaway_99
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".
Spivak
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.
hn_throwaway_99
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.
linguae
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.
ubermonkey
>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.
aleph_minus_one
> 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.
roland35
"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.
mariocesar
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.
stryhx
yes thats one way of looking at it!
tyleo
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.”
flowerthoughts
> 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.
woopsn
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.
> It’s completely ok to not have anything external happen when the deadline arrives! That doesn’t mean the effort to meet it was wasted. You built trust with the rest of the organization and you freed yourself to work on other things.
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?