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
Using fake deadlines without driving your engineers crazy
51–60 of 98 posts
Re: Using fake deadlines without driving your engineers crazy
#52Wow, 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.
Re: Using fake deadlines without driving your engineers crazy
#53"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.
Re: Using fake deadlines without driving your engineers crazy
#54> 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!
Re: Using fake deadlines without driving your engineers crazy
#55Fake 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.…
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.
Re: Using fake deadlines without driving your engineers crazy
#56Fake 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.…
I think the pragmatic consensus is: feel guilty about it; then do it anyways.
Re: Using fake deadlines without driving your engineers crazy
#57> 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, 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 dead…
The pressure to deliver and complete dereliction in giving feedback is what breaks the loop for engineers .. completely demotivating
Re: Using fake deadlines without driving your engineers crazy
#58artificial 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.
Re: Using fake deadlines without driving your engineers crazy
#59Earlier quoted context omitted.
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…
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.
Re: Using fake deadlines without driving your engineers crazy
#60Just 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.