Prepare For Disappointment When You Throw Deadlines Over the Fence To Your Teams

Deadlines in software development are usually incredibly disappointing. They leave everyone miserable.

Why does this suffering happen, and what can we do about it?

Let me start by telling a story illustrating the hardship you may face by throwing deadlines over the fence to your development teams.

I once worked at a company where it was decided to rebuild the whole product. What was the deadline for completing the entire rebuild? Surprise, surprise! It was the CEO's birthday, less than a year away.

You might be wondering: Why the CEO’s birthday? Well, why the hell not? Don’t you want to make the CEO happy? It makes for a fantastic birthday present, don’t you want to help make that possible? Don’t be so grumpy. Let’s put our shoulders under it and make it work!

Unfortunately, that birthday date was the only link between the deadline and reality. The decided timeline had zero bearing on the amount of work that would need to be completed before the deadline.

What happened afterward? Well, by now, you can connect the dots. You don’t need to be a rocket scientist to figure out what happened. It was the same thing that always happens: misery from start to finish.

The developers were set up to fail from the start. The problem isn’t having deadlines but the insanity with which these deadlines are often produced, especially for massive undertakings like a product rebuild.

All developers worked their butts off to meet that timeline — and they failed. Everybody was unhappy. The stakeholders were sad because we didn’t deliver, and the developers were unhappy because they gave everything to make it happen, and nobody appreciated their efforts. Because they had failed, after all.

How did we end up in this tragic cesspit of deadline misery?

Not All Deadlines Are Bad

Who was involved in setting the deadline from the group responsible for doing the actual rebuild? Not a single individual contributor was involved in setting the deadline. It all went downhill from there.

And what’s crazy is that this is how many deadlines are set. Some people high up get into a meeting room, talk about the work that has to happen, and slap a date on it that sounds nice and not too far away for their taste. *Poof* the pleasing and agreeable date turns into a deadline. Everybody hears about the deadline and it’s no longer possible to put that date back in the bottle, despite everyone complaining about it.

Somebody rubs their crystal ball, and suddenly, an evil genie is released that makes everybody accountable for meeting said deadline, even though it’s firmly rooted in conjecture and disconnected from reality.

Why is this approach of throwing deadlines over the fence so common, why doesn’t it work, and what should we be doing instead?

Talking to Developers About Big Deadlines Is Frustrating

The moment you start asking for a timeline for a complete rebuild to developers, they’ll begin asking questions. They will ask you high-level questions like “Why are we doing this rebuild? What are we trying to achieve?” but also detailed questions like “Should that legacy feature work exactly the same way as before?”

They demand answers, and the answers must be precise because coding it is precise. They are not doing it to be a pain in the ass. They have to know how it works. You can code only when you know how it is supposed to work.

Without satisfying answers, they can’t do their job, and they can’t estimate. They have to design a complex system, after all. They’ll ask you for all the information you cannot provide, and then they’ll exclaim: “How can you expect us to provide a precise timeline if you don’t even know what you want us to do?”

Ouch. Fair call. You respond by saying:

“It should work exactly as the old product, but without all the technical debt.”

Thank god, now all these pesky questions can finally disappear and they can get cracking.

Finally, they have all the answers they need, and when they don’t have them, they know how to play around with the old product to figure it out. Management is relieved and absolved from answering annoying and detailed questions. But there are a few slight hitches they’re unaware of.

All the people who knew exactly how the old product worked left, and nobody knows how the old product works. If you’re lucky, these people are still there, but even in this case, nobody knows how the whole product works in every scenario.

Developers now have to reverse engineer how the old product works into requirements. This means they’ll lose a lot of time they could spend coding, which slows everything down.

The end result is that they won’t get all the answers to their pesky questions, and when they don’t have answers, it’s difficult to say how long the rebuild will take.

The developers don’t get the information they need or enough time to make a forecast they feel comfortable with. As a result, after a month, there still is no forecast. Management becomes agitated, and it feels like people are intentionally stalling.

At some point, somebody high up gets so frustrated that they pull a white rabbit out of a hat: the deadline we’ve all been asking for.

Nobody supports the deadline. Nobody knows if it is realistic, but at least now we all have a date to suffer from.

But here’s the beauty of it all: even if the developers had all the answers to their questions, they still would not be able to produce an accurate timeline. It’s because you can’t estimate and forecast what you don’t know before starting the work.

So even if you are armed with all the answers to the questions you thought to ask, the things you didn’t know before starting derail your forecasts and estimates.

Okay, it’s easy to bitch about these situations, but what should we be doing instead?

Collaborate With Your Developers Instead of Treating Them As Contractors

Work with your developers instead of against them. Don’t put yourself in the position you’re the one who has to provide the answers. How will we do this together?

The problem isn’t getting the information they need for a full rebuild; it’s impossible, and you will never provide all the information they need. Even if you would be capable of doing that, when you build a complex system, it will have behaviors of its own you didn’t perfectly anticipate upfront. And that’s why rebuilds are incredibly risky and scary, as often you end up both fixing things and making things worse.

You shouldn’t start talking to developers about a rebuild, as that’s a solution to a problem. What’s the problem we’re trying to solve with the rebuild? And if you’re doing a big project instead of a rebuild, what are we trying to achieve with this big project?

Don’t make the big project or rebuild the goal. You will set yourself up for failure. Make what you want to achieve the goal, not what you intend to deliver the goal. Work on setting a clear goal together that provides intent: What are we trying to achieve, and why does it matter?

You can’t reverse engineer what you’re trying to achieve from the decision to rebuild or someone who asks for a specific feature. Reverse engineering outcomes from features is plain silly. Start with what you’re trying to achieve, and then ask your developers: How can we best accomplish that? What’s the simplest thing we could build to make progress in that direction?

Put yourself in their camp. Don’t treat them like a factory that has to produce something before a specific deadline. Instead, ask yourself: Given our constraints, how can we work together to design a system that meets those constraints?

It’s not us vs. them. How can we get this done together? And with the decisions we’re making, what are the trade-offs, and are those acceptable from the various perspectives that matter? This means you need diverse perspectives. Only considering the technology or the business isn’t good enough.

The problem is that developers are often treated like assembly line workers who have to provide a timeline for delivery. But it’s not about the features we deliver but what those features make possible for the users or our customers. And if they don’t know what those features are making possible, how can they deliver the results we want?

In short, artificial deadline pressure usually results from not knowing what we want to achieve. We then settle by putting pressure on a proxy: let’s deliver something by a specific time based on the misguided belief that it will provide the results we want.

What we do only matters to the extent it produces the results we want to have. Doing more things or working harder isn’t what matters. It’s the progress toward the results we want to achieve that counts.

If you want results, it’s not the deadline that matters, but how we can work to quickly see if we’re making progress towards the results we want. In progress we trust, and not the initial plan we came up with at a point in time when we had the least understanding of what we were trying to achieve.

Progress is what matters, not delivering based on a plan that provides the illusion of progress with a timeline that feels agreeable.

We’re in this together. The question you should ask is: Do you want to be in control by actually working together, or do you want the illusion of control by putting pressure on everyone through an artificial timeline?