I’ve been programming for more than a decade and what seems to be a sore point for other software engineers is deadlines. This can be because a Product Manager set an unrealistic deadline in the past and they had to go on a death march to deliver. If you’re a Product Manager, these tips should help you set better deadlines in the future:
Avoid them completely
If you can avoid a deadline all together, that can be ideal. Instead of a deadline you can establish the most important thing to work on next, work on that until it’s done, then repeat. There’s actually a #NoEstimates movement that’s gaining traction right now. You can google for more information and this is a pretty good introduction video.
Avoiding estimates can be tough or impossible if you’re integrating with other companies that schedule work in traditional ways.
Don’t make artificial deadlines
Never make an artificial deadline. A lot of PMs do this as a motivation technique. Without a deadline, the programmers will take as much time as they can to finish their features, right? Actually, I find that most programmers try to do the best job they can and when rushed, they’re forced to cut corners and build poor quality software. A culture of artificial deadlines is going to lower code quality and the end result will be slower delivery on features in the future.
Any good developer will ask why the deadline is set at the date that it’s set. When a good developer does ask you’ll have to admit the deadline is fake and lose credibility on everything you say in the future. Or, you could lie about the deadline but sooner or later you’ll be found out and lose even more credibility.
“Buffers” for the real deadline are also artificial deadlines. If something needs to be delivered in March, don’t tell developers it needs to be done in January so you have enough time leftover if the deadline slips. You’ll lose credibility for doing this for the same reasons as above.
You should avoid this completely by only setting real deadlines.
Deadlines must be planned with developers
Deadlines must be planned with developers. This is worthy of its own article, and I have written one on the topic. In summary, developers have a better idea of how much time it will take to build a new feature than anyone else at the company. When you exclude them from deadline planning you’re either going to get unrealistic deadlines or you’ll need to be incredibly lucky.
Remember, telling everyone, “I want nine women to make a baby in a month” doesn’t make it more likely to happen. The amount a team can deliver over time should be projected to get realistic deadlines. An aggressive deadline might temporarily increase the amount the team will deliver over time but at the cost of morale, trust, and code quality. Sustainable pace is a better strategy and for that you need developer input.
Don’t plan deadlines in a vacuum
A common mistake is to plan a track of work and set deadlines around that track of work without considering everything else. e.g., you want to do three things in a month, but you only build a gantt chart for one of those three things. That’s ok to do if you’re going to work on the other two things after the first thing. But, if you assume that all three will be worked on in parallel, your gantt chart should include deadlines for all three.
Delay telling external parties as long as possible
When developers are involved in planning deadlines, they are giving estimates. Estimates are just guesses. Some things will take longer than planned, especially if the deadline is far out in the future. It’s difficult to tell an external party about a slipping schedule. But, if you never told them a solid date for when it would be done, you don’t have to tell them about the slipping schedule.
This goes back to the #NoEstimates topic. If you can avoid telling the external party about the deadline, do you really need one? Instead, you can prioritize the work as the most important thing to be done. Then you can tell these external parties that it will literally be the next thing we do. That can be satisfactory in some cases, and it’s a lot easier on the development team.