There are a myriad of methods IT managers use to try and increase their team’s productivity, some are good and some are terrible. One of the best ways to increase productivity is to maximize the team’s sense of personal ownership of its goals.

1) Have the team make its own estimates all the time, and be very careful not to pressure them into modifying those estimates. If you’re curious about the reasoning, ask for elaboration, but never indicate you disagree. If you’re in a position of authority they may not have the courage to argue with you (they should, but that’s another discussion).

2) Promote pride in the product by letting the team set and enforce the quality standards they agree upon. Have a damn good reason for discouraging refactoring if the team thinks it’s necessary, and always schedule it with high priority for the near future if it can’t be done now. There’s ALWAYS time for unit testing, and be proud of a team that demands high standards, even if you think it’s negatively impacting the schedule (it’s probably not, but, again, that’s another discussion.

3) Allow for time-boxed investigation of alternative ways of accomplishing a goal. This goes along with point number two; it helps the team feel like it is invested in its own technology decisions, thus increasing their sense of ownership. It sucks when you feel like you’re wedded to a technology or approach that you were rushed into and, in hindsight, was obviously not the best solution. Eventually you’ll disengage and feel powerless.

4) Make sure everyone gets involved by forbidding the flipping of the bozo bit. Make it abundantly clear that there are no stupid ideas or questions and actively encourage both from every team member. Have a culture of politeness and respect. The more confident a team member is that they are contributing, the more pride and ownership they will feel in the solution.

5) Limit panic and mass hysteria. Most of the time your software delivery schedule is not life or death. Excess pressure and forced weekend work is the black plague for software teams, it festers into disengagement and burnout much quicker than you think, then you’re hosed. Better to slip a deadline and reestablish expectations early. Plus, if you’ve got a highly invested team, they’ll sense the urgency and place the pressure upon themselves.

6) Unless there’s an overwhelming reason not to, give the benefit of the doubt to the technology preferences of the team. A team enjoys using new and exciting technologies and tools. Sure, there’s some risk that needs to be understood, but don’t forget the non-obvious advantages to using the latest and greatest. Team members appreciate getting exposure to the latest technologies, it’s good for morale and they’ll be better engineers as a result. A team is always more productive when they enjoy their work, and working with the technologies they’re interested in will help accomplish that.

7) All problems are the teams problems, don’t play the blame game. When a production issue comes up that becomes the team’s top priority, the first step is not to figure out who’s fault it is, the first step is to fix the problem as a team and understand that stuff happens. After the problem is resolved, the next step is to figure out how to improve your standards and processes so that you can decrease the likelihood of such problems recurring (finger pointing and passing the buck should not be one of the steps). Any problem with the system becomes the team’s problem, not an individual’s problem.