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

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.

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

> Once I became a manager, I finally saw why they were needed, but felt guilty about using them.

The "why they were needed" is some guy with exponentially more university connections than sense trying to squeeze the engineering department for his bonus.

Don't lie to your employees, you snotball.

If you draw a picture, you can spend 20 minutes, 2 hours, or 1 day and the quality will vary. Budgeting time should be a process of achieving team consensus about which level of effort will be applied for a particular job.

You don’t need to lie to have that conversation.

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.

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

[0]: https://www.etymonline.com/word/deadline

Wow, this hits close. When I was managing teams, I put a lot of effort into making deadlines clear, measurable, fair, etc. I personally use Deadlines for everything, maybe is the ADHD coping I have the reason I like dates a lot, but is not the same when I work with others in a team

I thought I was helping my team with structure, clarity, direction. But looking back, even though we all wanted to do good work and move forward, and genuinely care about each other, something always felt off. There was this tension around "dates". I felt it. The team felt it. And we quietly resent them

Years later, I stop managing and become part of a team again, and I saw another manager approach deadlines totally differently. She talked about deadlines as "things that happen" you wanted or not, almost like happy accidents. The real focus was on creating an effect. That shift in language unlocked something for me. Deadlines became markers to check if we were moving forward, making the impact we wanted, not pursuing goals. That change made everything feel sane and more honest, and give more room to be ambitious. The day to day was the same but different, we checked whether what we were doing was aligned, and deadlines where just times to "measure" how things were going, so deadlines was something we wait for, and they were easier to negotiate, because if you have the effect or goal in mind, you move deadlines to match the outcomes we wanted, and not just avoid the deadline themselves

It's not directly on the post, but the idea is similar: it's better to use deadlines as measurement tools rather than a time to do judgment. Better to build trust through alignment and purpose.

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

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.

I was hoping this was a parody, god I would hate to have a manager like that.

Or, here's an idea, how about you not drive your engineers crazy by not using fake deadlines?

In the end, engineers have to deal with actual reality. Don't shove random fake stuff at us - not to motivate us, and not for any other reason.

As a manager, I have never found lying to my reports to be a good strategy.

Fake deadlines are lies.

The main point of this article is that you need fake deadlines so that people don't take too much time working on things—and that's simply not true. The best teams I worked on did not have fake deadlines but still moved fast (noticeably faster than peer teams in the same org) because we felt real ownership over what we were doing; intrinsic motivation is far stronger than extrinsic motivation.

If you actually trust the people doing the work—and if you fervently believe in Parkinson's Law, you don't—you wouldn't reach for fake deadlines, you would just ask people for what you need, and give them enough context to persuade them.

You can just go and ask: "how can we get something useful out faster so that downstream team X can start experimenting with our system?". As long as you trust the team and you've managed to get the team to trust you, why wouldn't they try to do that?

I mean, there might be some real reasons not to hurry in any specific situation, but if there are you would talk about it. And maybe those reasons are strong enough that you shouldn't be trying to get something out faster just then! Or maybe there's a mismatch in your understanding of the situation that needs to be sorted out. Or maybe the team really does need to change their approach to get something out faster, even if there are real costs to doing that. Getting to that conclusion bottom-up with the team is going to be way more productive, less stressful and less trust-destroying than imposing and then missing fake deadlines.

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.

Reminds me I need to do something with the domain: incompetent.management

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.

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

You give me a deadline and I find out it's fake then at least one of us is going to be looking for a new job.

Just call them "internal deadlines". That communicates what they are and the consequences for missing then. That's a better way to put it than "fake" - these are real deadlines, but engineers get annoyed when the people creating then don't take responsibility for them.

Deadlines exist for a reason; they’re not just random torture. Without them, nothing would get done when things need to get done. But faking pressure with artificial deadlines? That’s a dumb move. It just pisses people off, and rightly so.

If you using fake deadlines to stress employees and force them to go the extra mile and do crunch time to meet those deadlines then that's worker exploitation.

Advocating for fake deadlines means, to me, that you aren't an effective leader and don't understand knowledge work in the least.

When I did eng. manager work I had to put up with my managers giving us fake deadlines all the time. It was a mess. Absolutely political and had no real value. It simply stressed every one out.

And no amount of, but you weren't doing it right, will convince me.

Deadlines exist but they are a social construct. They combine an agreement, an optimistic prediction of the future, and the anticipation of punishment. There are cases where they are absolutely necessary... that chip foundry isn't going to be able to flash that ROM without the code you want on it and they have orders for the next couple of years, so you better deliver the final code on time! However they are also flexible. The world isn't going to end if you need to take another few weeks to ship the feature you've been planning.

Sales is one of the bigger sources of frustration for development teams when it comes to deadlines. They're used as a negotiating chip to make buyers more comfortable with their investment. And smart sales teams have learned how to manipulate software development teams by providing fake deadlines in order to keep up appearances.

I find it all works better if folks are simply honest.

And that's why I got out of management.

"When 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).

I thought this was a late april fools!

in one of the startreck movies is a sceen with "Scotty" having improbably survived into the future durring a crash by suspending himself in the "data buffers" of a transprorter, where he gives advice to a young engineer, on how to manage the expectations of his comanding officers "ach Captain she's gona blow"

> However, that situation occurring typically represents poor application, rather than issues with the methodology.

Isn’t that what they say about communism? And every other -ism?

It’s the “no true Scotsman” fallacy as applied to experimental results. The theory isn’t wrong! The experiment must be faulty!

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.

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.

[dead]

[dead]