Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using fake deadlines without driving your engineers crazy

newsletter.manager.dev

Post reply on HN
Print view View original

41–50 of 98 posts

Re: Using fake deadlines without driving your engineers crazy

#41

Post by agentultra »

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.

Re: Using fake deadlines without driving your engineers crazy

#42

Post by Spivak »

Hasu wrote: post #25
game_the0ry wrote: post #5

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…

I think the person you replied to would consider your description of agile to be === "it gets done when it gets done." Despite the term "deadline" used to describe "expected completion date" in agile they're not actually deadlines--you don't throw the work away because it's useless if it's not completed in time.

Re: Using fake deadlines without driving your engineers crazy

#43

Post by stronglikedan »

mylons wrote: post #36
diggan wrote: 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

We call that "hurry up and wait!" around my parts.

Re: Using fake deadlines without driving your engineers crazy

#44

Post by memhole »

diggan wrote: 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…

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.

Re: Using fake deadlines without driving your engineers crazy

#46

Post by SadnessComplete »

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.

Re: Using fake deadlines without driving your engineers crazy

#48

Post by steveBK123 »

AnimalMuppet wrote: post #34
FirmwareBurner wrote: post #15

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…

Yes, and I'd add further - this is knowledge work. Creating a mentally/emotional safe environment is going to enhance productivity more than shouting at people.

Shouting at a team is a good way to burn a day of productivity and months of built up good will. This should be obvious, and yet I still see about 20% of managers do it.

Re: Using fake deadlines without driving your engineers crazy

#49

Post by wheybags »

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.
Post reply on HN