Why Deadlines Need to Drop Dead
Deadlines are incredibly destructive to team productivity and morale. The #1 challenge software developers face is unrealistic expectations. Can we motivate & push without arbitrary deadlines?
You can lead teams without deadlines. You can still deliver code quickly. You can still ship in time for Christmas. But you’ll be dealing with a different management framework. One that puts the deadline pressure on product managers rather than developers.
Before we get into that, though, let’s talk about why deadlines are so bad, and the flawed thinking behind them.
Why Do Deadlines Exist?
If deadlines are so destructive, why do we use them?
Cost Management
Some deadlines exist to try to manage production costs.
The flawed logic goes something like this: Every minute developers are spending playing ping-pong instead of sitting at the desk is money flittered away. If your developers know that you’re trying to ship a critical update next Tuesday, they won’t be playing ping-pong.
The problem with this logic is that proper rest & relaxation is absolutely essential to developer productivity. Without it, you’re in for potentially severe impairment of cognitive abilities that are vital to software developers. Too much work can even lead to a complete shut-down that may require a leave of absence or medical treatment. The dreaded burnout.
As it turns out, there’s a good reason lots of offices have things like ping-pong tables, video games, napping cots, and music rooms.
You can’t avoid R&R using any management technique, and if you try to push your team too hard, you’ll end up with team-wide burnout. There are multiple collections of developer burnout stories across the web. You don’t want your team featured in them.
If you think churning through employees is a viable option, remember that your employees can share their experiences with potential recruits on Glassdoor. Hiring is already hard. Don’t make it harder.
The human body is going to get its rest whether you like it or not. Whether the timing is convenient or not. If you don’t deliberately schedule R&R, your body will shut down and take it — probably during a critical moment when you need to be really focused.
If you think everything will be OK after a long recovery weekend, forget about it. Burnouts can be extremely dangerous, leading to potentially life-threatening health problems, including heart problems, depression and in the worst cases, suicide.
The downtimes triggered by severe burnout can last up to a year — assuming that recovery and rejoining the team is even possible. Chances are, you’ll just lose them.
According to a survey by StackOverflow, unrealistic expectations are the #1 challenge developers face. It’s also a common reason why developers leave. When a developer leaves, you don’t just lose that developer. You also face the expense of hiring and training a new developer.
It can take months to find a qualified replacement, and it typically takes about 2 more months for a new developer to acclimate to your project and start to contribute as a fully productive member of the team. That’s a lot of expense and opportunity cost.
Can you afford to manage those costs?
You’re kidding yourself if you think deadlines are saving you money. They’re costing you dearly.
Marketing Calendars
Aside from cost management, sometimes it’s really important to hit critical seasonal marketing dates. That means releasing products in time for black Friday. It’s good to keep goals like this in mind. Sometimes it’s crucial to the survival of your business to hit shipping goals before your runway runs out.
In other words, some deadlines seem to be more uncontrollable, external forces rather than arbitrary, internally agreed-on ship-dates. Those circumstances are more rare than you think. Companies generally have other assets they can leverage to move things around.
Do you really need to hit a delivery date before your runway runs out, or can you boost sales of existing products or raise more money, instead? Of course, I’m oversimplifying, but when you get really creative, true drop-dead deadlines are rare.
For those cases when deadlines really are external forces that simply can’t be helped, instead of putting deadline pressure on your developers, your key stakeholders (business, product, engineering, design) need to put their heads together and work out the absolute minimum valuable product that can easily be made within a fraction of the time remaining before the real drop-dead-deadline. (You may have heard of MVP defined as the “Minimum Viable Product” — yes, that, except that to be viable, a product must also be valuable.)
If you’re planning to launch a car, scale it back to a skateboard. If you’re planning a trip to Mars, scale it back to a weather balloon. Be brutal. Carve features away until it really does represent the absolute least amount of work required to produce a product that your customers would love.
That doesn’t mean cut corners. Make the best damn skateboard or weather balloon on the market. Commit to quality engineering, stunning design, and a quality and customer-focussed engineering process.
The point here is that instead of trying to build out the CEO’s ideal vision of the product you’re bringing to market, you build out a beautiful stepping stone on the way towards that vision. In place of arbitrary deadlines, you deliver consistent, steady progress.
Elon Musk wants to colonize Mars. To do that, we need better solar technologies, better robotics, and better rocket technologies. To make this long-term vision sustainable, he had to bring products to market that represent stepping stones toward his long-term vision.
That’s why there are Solar City roof tiles, Tesla’s self-driving electric cars, and Space X launching commercial satellites into orbit.
Stepping stones on the way to Mars.
Plan your stepping stones — a gradual progression from the product you have now (even if that’s no product), to the product you eventually want to produce.
Then iterate, moving in small steps from one stepping stone to the next, until eventually, you achieve the vision.
Here’s the strange bit, though. Almost certainly, that vision will evolve and adapt in response to market forces, or in response to things you learned along the way, and what you end up building may be very different from the thing you set out to build.
And that’s OK. That’s totally cool.
What you end up building may be very different from the thing you set out to build. And that’s OK.
The Secret to Never Missing A Deadline Again
The best way to manage marketing calendars is to set your marketing hype cycle one cycle behind your development cycle.
That means if you need to release something in time for the holiday season, you promote the thing you finished in the previous development cycle. You build up to the big launch hyping the thing you’ve already built, and tested, and is ready to launch at the flip of a switch.
Market only finished products: No missed deadlines. No cut corners. No exploding products. No bad press.
How Do you Answer “When Will it Ship?”
From now on, the answer is simple. Get used to saying it a lot, because people are going to ask, again and again, and they expect an answer:
“When it’s done.”
That doesn’t mean that you’re shipping nothing for a long time. That’s a sure path towards vaporware hell. Remember those stepping stones?
If you produce software, you can build your skateboard in a couple weeks and then start shipping incremental improvements daily.
Instead of “When will it ship?” the new questions are “what did we ship this week, and how do we want to market it?” Do you hold the new features behind a feature flag system and wait for a marketing calendar event to roll them out to the masses? Do you enable the features right away?
These are much more fun questions to deal with. Even hardware systems can use continuous delivery when there are software components. In the age of IoT, that’s just about everything, from toys to toasters.
Implement continuous delivery, and when somebody asks you when your product will ship, you can tell them, “we shipped this morning. We’re shipping again tomorrow. When will we ship a specific feature?”
You know the answer to that one, right? “When it’s done.”
Want me to visit your team in-person for a 2-day workshop covering engineering management, The Two Pillars of JavaScript, and the principles of modern client architecture?
Bring the High Velocity Development Team Workshop to your team.
Eric Elliott is the author of “Programming JavaScript Applications” (O’Reilly), and “Learn JavaScript with Eric Elliott”. He has contributed to software experiences for Adobe Systems, Zumba Fitness, The Wall Street Journal,ESPN, BBC, and top recording artists including Usher, Frank Ocean,Metallica, and many more.
He spends most of his time in the San Francisco Bay Area with the most beautiful woman in the world.
