> 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?
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.
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'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.
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
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.
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.
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.
> 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 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
> 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.
"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.
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 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.”
> 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.
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.
> 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.
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.
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.
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.
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.
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
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.
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
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.
"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).
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"
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.
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.
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.
diggan|11 months ago
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|11 months ago
memhole|11 months ago
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|11 months ago
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.
mystifyingpoi|11 months ago
mylons|11 months ago
aantix|11 months ago
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.
unknown|11 months ago
[deleted]
jasonm23|11 months ago
DON'T
jph|11 months ago
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.
mytailorisrich|11 months ago
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.
josfredo|11 months ago
alwa|11 months ago
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|11 months ago
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.
steveBK123|11 months ago
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|11 months ago
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|11 months ago
You don’t need to lie to have that conversation.
Spivak|11 months ago
Ya know, basic manager stuff.
makeitdouble|11 months ago
steveBK123|11 months ago
AnimalMuppet|11 months ago
game_the0ry|11 months ago
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|11 months ago
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.
hn_throwaway_99|11 months ago
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.
ubermonkey|11 months ago
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|11 months ago
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|11 months ago
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
mariocesar|11 months ago
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|11 months ago
tyleo|11 months ago
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|11 months ago
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.
markerz|11 months ago
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.
hackable_sand|11 months ago
dogleash|11 months ago
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.
woopsn|11 months ago
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.
matt-p|11 months ago
AnimalMuppet|11 months ago
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.
ubermonkey|11 months ago
Fake deadlines are lies.
tikhonj|11 months ago
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.
morkalork|11 months ago
dboreham|11 months ago
stryhx|11 months ago
assimpleaspossi|11 months ago
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.
SpaceNoodled|11 months ago
Tumlomu|11 months ago
[deleted]
duxup|11 months ago
Dates are important, but even outside the work, bad dates can kill a workplace.
wheybags|11 months ago
Minor49er|11 months ago
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
OutOfHere|11 months ago
It your manager does not understanding that estimates are not deadlines, find one who does.
Minor49er|11 months ago
thrill|11 months ago
thenoblesunfish|11 months ago
luhsprwhk|11 months ago
CrossVR|11 months ago
agentultra|11 months ago
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.
palata|11 months ago
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).
callamdelaney|11 months ago
metalman|11 months ago
shermantanktop|11 months ago
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!
SadnessComplete|11 months ago
mylons|11 months ago
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.
morkalork|11 months ago
nthingtohide|11 months ago
unknown|11 months ago
[deleted]
talkingtab|11 months ago
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.
oldpersonintx|11 months ago
[deleted]
drpossum|11 months ago
[deleted]