Live data from Hacker News

Using fake deadlines without driving your engineers crazy

newsletter.manager.dev

31–40 of 98 posts

Re: Using fake deadlines without driving your engineers crazy

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

Re: Using fake deadlines without driving your engineers crazy

#32

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.

Not your point, but setting and managing deadlines on when a picture from a professional artist will be delivered is an art in itself.

Re: Using fake deadlines without driving your engineers crazy

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

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.

Re: Using fake deadlines without driving your engineers crazy

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

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

But they actually aren't leaving productivity on the table. This isn't an assembly line. Crunching makes you tired, and your brain slows down when you're tired. You wind up doing the same work in a 10-hour day that you would have done in an 8-hour day.

Extreme programming (XP) was all about going as fast as you can. One of the rules was, "Never work overtime for more than one week in a row." Why? Because when you're tired, you slow down. When you're tired, stop. Go home. Get some sleep. Come back tomorrow with a brain that isn't tired.

Re: Using fake deadlines without driving your engineers crazy

#35

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.

Yeah I think management / product / even engineers underestimate how much of time budgeting is "level of doneness" as much as "what should be done".

Re: Using fake deadlines without driving your engineers crazy

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

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

Re: Using fake deadlines without driving your engineers crazy

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

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.

Someone should make a modern day boy cried wolf story except it’s with software engineers and fake deadlines.

Re: Using fake deadlines without driving your engineers crazy

#38

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.

Stronger: You need to not lie to have that conversation.

Re: Using fake deadlines without driving your engineers crazy

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

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.

Re: Using fake deadlines without driving your engineers crazy

#40

Earlier quoted context omitted.

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

But they actually aren't leaving productivity on the table. This isn't an assembly line. Crunching makes you tired, and your brain slows down when you're tired. You wind up doing the same work in a 10-hour day that you would have done in an 8-hour day. Extreme programming (XP) was all about going as fast as you can. One of the rules was, "Never work overtime for more than one week in a row." Why? Because when you're…

>Crunching makes you tired, and your brain slows down when you're tired.

Sure, but management doesn't care about the health of the workers, they care about line going up, for them workers are replaceable cogs. If people are too slow and tired from crunch, then it's their problem, so you put them on pip then fire them and replace them with fresh hires. Rinse and repeat. It is only a problem for them, if they manage to burn through all their cogs and have no more replacements. But then there's immigration and visas.

I've seen this twice already where I worked.

Wasn't Japan the country where people even die from overwork? If management saw this as a problem, surely they would have put an end to it by now and give workers there a French/Danish work-life balance instead to increase their productivity, but it seems like that's not how companies view productivity.

Post reply on HN