Live data from Hacker News

Using fake deadlines without driving your engineers crazy

newsletter.manager.dev

61–70 of 98 posts

Re: Using fake deadlines without driving your engineers crazy

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

Re: Using fake deadlines without driving your engineers crazy

#62
post #7

> 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 pre…

[deleted]

Re: Using fake deadlines without driving your engineers crazy

#64
post #25

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 complex…

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 und…

You want milestones and progress over estimates and deadlines.

The value equation of a software development team isn't a product of their time and salary compared to the code/features/whatever-unit they produce. It's the theories and knowledge they build in their heads and share through the process of understanding problems and developing solutions. You can't optimize that process in a Taylorist fashion.

If there is a process called Agile that's still useful, it's built on this manifesto that eschews management in the Taylorist sense. The principles are built on a preference for organizations driven by the workers rather than the managers. It was perhaps too radical and too naive.

"It gets done when it gets done," is a glib way of saying that progress is more important than deadlines. The idea that systems take time and what's important is that people know where we're at and where we're heading more than threatening punishment for not delivering what we estimated at an agreed upon time.

Re: Using fake deadlines without driving your engineers crazy

#65
"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).

Re: Using fake deadlines without driving your engineers crazy

#66
post #4

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

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.

Re: Using fake deadlines without driving your engineers crazy

#67

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 complex…

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 shoul…

To add, coming from a research environment (industry AI researcher turned community college professor), there are deadlines in industrial research labs and academia, too. All of my industry research projects had to fit within management-defined schedules. Back in grad school I was well knowledgeable of the “call for papers” deadlines of all the major conferences of my field, and my professors also were well aware of the various deadlines for applying for NSF grants.

I hate project estimation with a passion, especially when doing research, but I recognize that funding isn’t infinite and funders want to assess their own risks. This, we as researchers and engineers have to try our best when it comes to project estimation, even though there are so many “unknowns.”

The only situations that I could think of that are free of deadlines and estimation pressures are projects that are not on the “critical path” of a business or organization, such as a tenured professor working on a project where the outcome doesn’t negatively impact job security, or a student’s side project (like Linux circa 1991) where the only constraint is time.

Re: Using fake deadlines without driving your engineers crazy

#68

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

Re: Using fake deadlines without driving your engineers crazy

#69

Earlier quoted context omitted.

>Crunching makes you tired, and your brain slows down when you're tired. Sure, but management doesn't care about the health of the workers, they care about line going up, for them workers are replaceable cogs. If people are too slow and tired from crunch, then it's their problem, so you put them on pip then fire them and replace them with fresh hires. Rinse and repeat. It is only a problem for them, if they manage to…

Not sure why this got downvoted, management really does not care about your health. They may say things out of social niceties, but they really do not care. Maybe if it causes their cost share of your healthcare plan to go up they might, but not really.

>Not sure why this got downvoted

Because HN doesn't like comments that are blunt about harsh realities, they like a warm tone that coddles and softens the facts.

>They may say things out of social niceties, but they really do not care.

My favorite part is when companies pretend to tackle burnouts with giving their workers subscriptions to yoga or mindfulness apps, instead of you know, the sane thing that actually works, which is less workload and a less toxic work environment.

> Maybe if it causes their cost share of your healthcare plan to go up they might, but not really.

Would be nice if that were the case. I live in a country with universal healthcare, so all the externalities of burnouts get socialized from the private system to the state healthcare and welfare systems, not to the employers. It's incredibly rare that an employer here is reprimanded against stress induced onto the workers. Only if there's hard evidence proving the employer is the cause, or an employee kills themselves you might see the state looking into it and fining the employer.

Re: Using fake deadlines without driving your engineers crazy

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

Post reply on HN