Of Deadlines and Due Dates
[Author's Note:I originally published sometime in 2000. I wrote 3 articles that year on managing development teams. I'm going back and revisiting them because we are moving into another upswing in the technology sector. I see some of the same behaviors saw in the "Bubble". The rush to be first, "Ship Happens" mentality, etc. (I even had one colleague who was very proud of the the fact that his company shipped crap but then fixed it. That mentality is so wrong that it requires a blog of it's own.) Anyhow, I felt it was time to bring this one out of retirement to remind managers and developers alike that no salary buys more than your limited attention span. But to have a life, sometimes you have to take a stand.]
I love deadlines, especially the whooshing sound they make as they go by.
– Douglas Adams
Do not commit to a deadline you did not help set.
The Marketing department (the butt of most Nerd jokes) loves to set aggressive deadlines.
“Over commit” goes their battle cry, “and over deliver!”
The problem is that it’s usually not their butts behind the keyboard at 2 AM trying to “over deliver” on their “over commitment”. Don’t let this get started in your shop. Fight it with every fiber in your body. Barricade yourself in the data center behind your O’Reilly books and refuse to come out until you have a voice in the process! Well, ok, maybe you don’t have to go that far. But you might want to count your “Animal” books, just in case it becomes necessary.
You can be firm but polite when you tell your boss “I don’t think that date is attainable.” Most of the bosses I’ve had in my career want realistic goals. Don’t set goals that are so conservative that it appears that you are padding the date for “slack time”. On the other hand, don’t be so liberal with your sanity that you set a due date that is all but impossible for even all of Microsoft’s Minions to hit. (Not that Microsoft is a gold standard for shipping products on time. It’s just that with as many developers as they have they should be able to hit any deadline.) Bosses are as motivated as you are to set goals that can be hit. They get bonuses too, you know.
In the current software development environment, with everyone trying to outrun the competition, software developers are under constant pressure to get it done faster, Faster, FASTER! Quality takes time, always will. Pick your deadlines carefully and stand by them. If your boss insists that the date be moved (usually up), make sure you have a paper trail explaining that you and your team respect her decision and will strive to hit the new dates but that you do not believe that they are attainable. Then do your best to hit the date!
WARNING: Marketing people work in marketing because they are good at influencing people to do things. Regardless of the hype they are peddling, stick to your guns. If you know your dates are solid (not padded) and attainable, stick to them. No matter how many times you are told to “Find A Way” or “Get It Done”, you are the one who will be held responsible for the date. Pick it and stick with it.
Do your homework!
Never commit to a date until the requirement phase of the project is complete. If your boss asks you to commit to a deadline based on a 1-2 page/paragraph description of the project, don’t do it. This is like taking a team of General Motors automotive engineers, putting them in a large warehouse, and saying “Build me a airplane.” What you get might resemble a plane — heck, it might even have working engines — but chances are slim that it will ever leave the ground, and even slimmer that it will return safely. (No offense to any GM engineers that read this and no fair if GM has an Aeronautics division!)
You have to understand the problem before you can tell how long it’s going to take. You can not fully understand the problem until you have spent the time to design the requirements. No matter what methodology you use to gather the requirements, you have to walk and talk through the entire problem before you can know how long it will take.
It’s the team, stupid!
Unless you manage and code (something I’ve never been able to master), you are not going to be directly influencing whether you hit the deadline or not; your team will. Have a team meeting to go over the requirements and let everybody voice his opinions. They have to think it’s an attainable deadline or you have zero chance of hitting it. It’s vital that everybody on the team feel that her voice is heard and his input considered before the deadline is set.
Once everybody has been heard (as the manager, you shouldn’t do much talking in this meeting), all of you should pull out your calendars, Palm Pilots, or stone tablets and agree on the date and the major milestones. Print a time line as soon as you can and paste it all over your offices. Make sure that everybody knows and remembers what is due when.
It’s you, stupid!
I always tell my teams that if we succeed, we succeed as a team; if we fail, it’s my butt! If you hit the deadline, no matter how many times you tell everyone it was a team effort, your manager is going to see that you hit the deadline. (Do make it a point to share the glory, though.)
More importantly, this holds true if you fail to hit your deadline. You are the manager; if the team fails, regardless of the reason, it is your responsibility. Step up and take your licks. Do not be falsely humble; a good boss can smell manure. Be genuine and sincere. In most circumstances, your boss will respect the fact that you have taken ownership of the missed deadline and will be more concerned about how you can prevent this from happening again than in punitive punishments. If you are lucky enough to work at a company (like ones I have worked for) that considers failure to be a learning process, make sure you identify the problem and work to correct it. However, failure the second time, for the same reasons, is not a lesson; it’s a red flag.
Deadlines ARE important! (just not THAT important)
I do not mean to minimize the importance of deadlines, road maps and milestones. They are critical for all but the most trivial software development projects. However, they are not, nor will they ever be, more important than the lives/sanity/health/well-being of your developers. Setting impossible or even improbable deadlines for software development means that you have chosen to let your developers “eat and sleep” the project. Don’t get me wrong, for the right project, if you have chosen your team wisely, they will commit and go. But it will take it’s toll. What good is hitting a deadline if you lose a good developer in the process. And unless everyone on your team has stock (not options, STOCK) in the company, what is their longterm payout? Why is it important to them? As we move back into a cycle of “War for Talent” good developers are going to be hard to find and keep. Keeping your development cycle in check will help keep your developers on staff.
End Game.
Every time I write, I hope that my experience is helpful to someone else. But remember: this is what worked for me; it may not work exactly the same for you. Use the ideas, but make them your own. And when you improve on them, share them with me and others.
February 3rd, 2006 at 9:17 am
Wise as always. ;)
February 3rd, 2006 at 9:26 am
ty G.
Ladies and Gentlement of the blogsphere, allow me to introduce gpaht. G was on my team when I originally published this article.