Thursday, November 01, 2007

Enabling the Success of a Software Team

There are three "must haves" for excellent managers, which I look for when I work for a manager, and which I try to live up to when I work as a manager.

I thought I'd write down these thoughts, after seeing Jeremy Cole's blog this week with some great advice about ways to attract, motivate, and retain expert MySQL DBA architects, and earlier this summer Cal Evans' podcast Attracting Talent on the PHP Abstract site about attracting talent.

This brings me to my ideas about how to manage excellent software developers. There are many things a manager has to do to be effective at leading a team, but to boil it down to a single principle, I like to say that the manager's job is to enable the success of their team.

Here is my list of three management responsibilities to support the success of the team:

1. Give clear and achievable assignments

The first step to making your team successful is to tell them what you want them to do. What is the goal of the project? What does the resulting software need to do? Are there constraints on schedule or technology? Who is the audience? Who approves the final deliverable? These and other high-level questions must be answered, even if all the fine details are still in "discovery phase.".

Counter-example: in a classic Dilbert comic strip, the boss asks Dilbert to work on a new project. Dilbert says, "great, I'm ready, what's the project?" The boss says, "It's not all worked out yet, so you just start coding, and I'll stand here looking over your shoulder. If you do something wrong, I'll scream."

The assignment must be achievable. Not softball -- giving a developer a challenge is a good thing. Many people thrive on this, and sometimes they can pull a rabbit out of a hat and surprise everyone (including themselves). But it does no good to give someone a task that is truly impossible, this just sets them up for certain failure.

Also, the assignment must be consistent, or at least acknowledge clearly when it changes. We all know that project requirements tend to evolve and we are okay with that. But a manager who implies that the developer should have anticipated the change is being disrespectful. Or worse, I've seen managers claim that the changed requirements were what was "intended" (though not stated) from the beginning, and that it's the developer's fault for not inferring this information. What can one say about this behavior? Let's just say that the manager is not fulfilling his or her responsibility to make the team successful.

2. Provide the resources needed to be successful

I have a pretty broad definition of "resources" in this context, including hardware and software tools, enough time to complete the assignment, access to people who are needed such as IT support staff or subject matter experts, any existing technology or research that is part of the desired solution, etc.

Counter-example: I once was told to set up a testing environment, but we had no server on which to install it. The VP's solution was to tell me to use VMware and then I'd have as many servers as I need. But we still needed a real server on which to run the VMware software, and we had none. This is an example of being told to make bricks without straw.

Another counter-example: a manager who won't authorize a $250 expense for a commercial-quality code-analysis tool, but they'd rather let their highly-paid developers spend weeks debugging elusive issues. That's not a smart use of time or money. Sure, one doesn't want expenses to get out of control, but being either too stingy or too frivolous are both likely to put the team's success at risk.

3. Give constructive feedback

The manager must communicate clearly and deliberately, instead of assuming "no news is good news."

Feedback doesn't need to be full of hollow affirmations or cheerleading; it should let the developer know how close he or she is to the goal of success. Also, if the developer is off-target, it's important to communicate about this and correct it as early as possible. Most people naturally want to do a good job, and being allowed to do the wrong job for weeks is sure to discourage them once they learn the truth.

Ultimately, when the team completes an assignment, a manager should tell them they did so, and how well it meets expectations. An important part of enabling a team's success is letting them know when they have done it.

No comments: