[diggan]

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

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

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

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

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

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

[AnimalMuppet]

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.

[franktankbank]

No you'd just outsource to India and cycle through as many billions of souls needed.

[AnimalMuppet]

You'd still have to bring each new hire up to speed. Still not a smart plan.

[steveBK123]

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.

[FirmwareBurner]

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

[steveBK123]

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.

[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

[jasonm23]

Frankly the correct answer to the post's headline is an emphatic:

DON'T