X
Business

Deadlines and developers

For developers and their managers, only one thing is worse than delivering buggy code, and that’s missing a deadline. Here're seven tips to keep developers on the right time track.
Written by Jeff Davis, Contributor
For developers and their managers, there’s only one thing worse than delivering buggy code, and that’s missing a deadline. Team morale can plummet as individuals and teams point the finger of blame at one another.

So how do you manage through a missed (or nearly missed) project milestone and keep your development team on track? Here’s some advice from your peers for keeping the team and the project on the right track.

1. Nip problems in the bud
Pete Schickler runs Button Systems Inc., a Vermont-based software development company specializing in custom software solutions for the healthcare industry and government agencies. “You can’t get blindsided by a missed deadline,” Schickler said. “If your team is in danger of missing a deadline, [you should] see it coming.”
And when you see it coming, what action should you take?
“The key is knowing how to react,” he said. “And the way you react depends on the composition of the team. If it’s a 40-person team with 10 levels of pay, you handle [deadline stress] differently than if it’s a three-person team and they’re all making essentially the same pay.”

2. Give "the speech"
In large organizations, deadline stress can cause a development effort to devolve into a blame game. “In large organizations, where there are six levels of project submanagement, you’ll have a System Analyst III who’s mad at the Senior System Designer IV, who’s pointing the finger at the QA Analyst….” The key is to put a stop to this finger-pointing and moving on to something more productive.
To do so, Schickler said, “I try to identify the key players and take two or three, or maybe five or six of them, put them in a room, and give them ‘the speech.’“
Schickler’s speech goes like this: “This project is bigger than all of us. Getting the work done is the most important thing. Not you, not me. The project will go on long after we are gone. That being the case, the problems you have today don’t mean anything in the grand scheme of things. So let’s remove them now.”
“Most of the time,” Schickler said, “they’ll work out their problems, and they’ll come back to me and say, ‘This is how we’ve decided to fix things.’“

3. Lunch and listen
Schickler’s approach is decidedly different when it comes to managing a smaller team with fewer differences in job titles and levels of pay. “I take them all to lunch, give them some positive strokes, and then let them vent,” Schickler said.

While his team vents, Schickler listens for specific suggestions and then makes virtually instant decisions to act on as many suggestions as possible. “I want them to come back from lunch and say, ‘He listened to me. I made some suggestions, and he’s going to let us do it!’“

Schickler is quick to point out that he’s looking for project-related items, not suggestions about enterprisewide policies. “Developers will stress out and let little things get in the way of finishing the project. When they vent, you find out what those little things are, and you can deal with them.”

4. Motivate the troops
But there’s more to managing your team’s deadline stress than problem-solving. If you want your developers to make an important deadline, “you’ve got to work their long hours,” said Mike Larner, a Midwest-based executive IT consultant. “Even if you’re not doing the work, you need to be there supporting your team.”

Larner believes in letting developers choose their own hours, as long as they’re productive. “Maybe you can’t be there all day, every day. But if your people are working weekends, you’d better be there on the weekends too.”

If your developers are worried about making a project deadline, “take something else off their plates,” Larner said. “Maybe you extend the deadline to get a review done or you reschedule a nonessential meeting. Again, even if you can’t pitch in and help with the code, you can reduce some of their stress by restructuring their workload.”

5. Ask the right questions
“If [developers] miss a deadline, you never point the finger and assess blame,” said Greg Gorman, a consultant with Blue Chip Consulting Group. “You have to ask, ‘What were the causes of the slippage?’
“If the hardware didn’t come in, and it’s truly out of the control of the development group, then the team shouldn’t be disappointed, because they still did a good job.”
Larner agreed. “If the developers are blaming another department, saying we didn’t get what we needed in time, I ask why we didn’t get what we need, and what can we do to get it.
“Sometimes, the manager can solve those issues by assuming greater ownership in the project,” said Larner. “If another department or group is holding up the developers, the manager needs to intercede and find out what the holdup is.”

6. Know the personality types
Larner thinks it’s also important to get to know each developer personally and find out what his or her “hot buttons” are. “All developers are not the same,” he said. “Some developers really enjoy what they’re doing and exalt in their contribution they’re making for the company. Others are just doing what they’re told.”

For developers in the latter group, Larner said, “you have to document exactly what those people are supposed to do, because if it’s wrong—or if it causes you to miss a deadline—they’ll say, ‘I did what you told me to do.’”

7. Encourage confession
If the developers are upset because fixing a mistake caused a deadline to slip, Gorman tells the team that it’s “okay to make new mistakes; just don’t repeat old ones.”

Gorman encourages his team members to "fess up" whenever they know they’ve made a mistake. “I tell the developers, look, when you screw up, I’m not going to kill you for it. Just tell me what happened.”

The key for managers, Gorman said, is simple: “Don’t kill ‘em when they screw up.”

A bit of patience and an honest chat could prevent your team from jumping ship when the going gets tough.




Editorial standards