Using fake deadlines without driving your engineers crazy

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

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

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.

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

>Deadlines aren't for tech teams.

Uh, that's just wrong. You may have contractual deadlines for delivery that are real and meaningful, for example.

>When someone asks for a deadline, the answer should be "it gets done when it gets done."

A refusal to engage in meaningful discussions about forecasts does not free you from the obligation to meet one. You must might not like the one you get imposed on you if you refuse.