As development managers, our business is systems, including software-based systems and people-based systems. For software systems, we create, evaluate, upgrade, and maintain them. You can apply similar strategies to your people system: your project team.
Building a system out of people is similar to building a software system in that development managers create, evaluate, and upgrade both. But many managers tend to be far less aggressive when it comes to maintaining their teams.
Like a complex software system, your development team may sometimes be less than robust. A heavy-duty cycle can expose weaknesses; temporary clutter can accumulate and corrupt results. Reorganization is sometimes called for, and purging is occasionally necessary. As with a large software system, we often wait until the last minute to implement the team maintenance we know is required to keep things running smoothly.
How to defrag your team
The human problems that call for this kind of people maintenance are many. The major issue involves a loss of focus, which follows fatigue and boredom, and a lessening of positive feedback as initial enthusiasm for a project gives way to inevitable drudgery.
Contemporary project methodologies give some relief. The “agile programming” (or XP) practice of teaming programmers is a good start. Working closely with another team member does much to keep a programmer out of a rut, and team members find their thinking stimulated in new ways on a daily basis.
Now consider doing a reorganization, as you do when you defragment a hard drive. Is your team’s efficiency dropping as the project stretches out? Stimulate the process by making some switches. Recombine your programmers into new teams. Do so with care, of course, making sure that the new teams are as synergistic as the old ones, but seek matches that make the most of differences and facilitate cross-training. Now may also be the time to move a restless team member into a new area: a veteran programmer may be ready to move out of applications coding and into systems work, for instance. Or your GUI expert may be ready to do some team leading, and one of your junior programmers may be able to tackle the project’s GUI modifications. The point is to keep the work and enthusiasm fresh, not by changing the work itself, but by reorganizing your team members in relation to one another.
Identify the source
Often, if a project is lagging or team members are slipping, it’s because project or task focus has slipped. Reasons for the slippage include the onslaught of modifications and adjustment in scope that inevitably creep into a project plan. Individual team members can become uncertain of where their piece of the project fits into the overall scheme, or (worse) of its relative importance. It’s hard to put your best effort into code that feels, rightly or wrongly, peripheral. We all like to believe that our contribution is as important as anyone else’s.
We, as managers, never intend to imply otherwise. But it’s often prudent to gather everyone together and get on the same page again. To this end, consider giving an afternoon over to a project review meeting—not for the purpose of disseminating changes or communicating shifts in scope, but simply to allow each member of your team time to talk about what they’re working on. Since the idea is not to put anyone on the spot, but to emphasize the value of each piece of the project, give your team carte blanche in terms of presentation. Some love to talk about what they’re working on, some are natural explainers, some are indifferent—and one or two probably hate speaking in public (let them make up a handout). The point of this meeting is to give everyone a chance to stress the importance of their work, and to remind the entire group of how everything fits together. As a bonus, meetings of this type often reveal a hidden bottleneck or two, so you'll walk away with lots of useful feedback.
Scan every sector
When fatigue or disillusionment set in, you may have seen that it is often not confined to a single individual. While there are times when a lone team member is having problems, it is more often the case that an entire project needs a boost of enthusiasm or clarity. For this reason, it’s important to always make any people maintenance effort a group-wide task. Whether you’re dishing out kudos or restoring project focus, it’s best to be certain that your effort impacts every team member.
For instance, if you counter malaise with an early round of praise for good work, be sure you offer a good word to every team member, whether their contribution is exemplary or not. There is something good to be said about everyone’s effort, or they shouldn’t be on the team in the first place. It’s not so much that everyone needs a pat on the head, as it is the fact that if you don’t make the praise universal, someone may feel unappreciated.
Generate logs but go the extra mile
The cold, hard text of an e-mail or printed report does much to dispel ambiguity. If your team has found its focus knocked askew by unclear priorities or scope changes, there’s nothing like a blunt status report to sweep aside rumor and uncertainty.
But go an extra mile here. A periodic status report is probably something you’re doing anyway, and while this is a positive step in reestablishing focus and restating objectives and schedule detail, it still puts the team in a reactive posture.
Restructure your report so it isn't the typical edict handed down from you to your team, with the will of senior management underlying it. The report should be from your team, passed through you to the powers-that-be. That is, instead of a status report that says to your team, “Here’s what is now expected of you,” write a report from your group that says to senior management, “Here’s where we are, and where we’re headed.” In both cases, you’re restating objectives and noting deadlines. In the latter case, however, your team is at the forefront. It’s a subtle distinction, but one that enhances your sense of team camaraderie without compromising the point of the report—clarification.
These are subtle practices, certainly, but then the problems they address are likewise subtle. The best aspect of team maintenance is that it is more a mindset than anything else. With a little effort, you can realize significant gains in performance.
Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence and social informatics, primarily in the health care and HR industries.