Using fake deadlines without driving your engineers crazy
newsletter.manager.dev
newsletter.manager.dev
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?
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.
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.
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.
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 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've basically never seen this happen in my career (although I live in hope).
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.
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.
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.
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.
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.
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.
DON'T
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.
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.
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.
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.
“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.
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.
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.
You don’t need to lie to have that conversation.
Ya know, basic manager stuff.
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.
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.
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.
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.
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.
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.
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.
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
This is what I call hitting deadlines.
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.
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.
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.
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.
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 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.”
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.
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.
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.
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 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.
Fake deadlines are lies.
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.
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.
Dates are important, but even outside the work, bad dates can kill a workplace.
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
It your manager does not understanding that estimates are not deadlines, find one who does.
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.
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).
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!
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.
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.