After teaching a class on software peer reviews at a client site recently, I asked the development manager about his plans for implementing these practices in his group. He confessed a reluctance to set ambitious expectations for his team. His concern was that, in today’s tight job market, a developer who rebelled against what he perceived as unreasonable process formality would simply jump ship for another company. This small development group couldn’t tolerate much turnover, so the manager wanted to leave the decisions about whether and how to implement peer reviews up to the team members.
I’ve seen this fear — or threat — of staff turnover put the brakes on process improvement efforts before. It makes me nervous.
Although all individuals can choose to improve the way they work, steering an organization toward sustained higher performance requires leadership. Leadership includes admitting there’s a gap between current and desired performance and committing to actions to close that gap. It means understanding the root causes of the performance gap, identifying practices that can help, and enabling your team to adopt them successfully. Sometimes, leadership means showing individuals how the way they work affects the performance of others and encouraging them to stretch beyond their comfort zone.
When a leader attempts to steer a group toward better practices, team members will react in one of three ways. The early adopters will say, “Great! What took so long? How can I help?” These allies can help the leader by piloting new methods on their own work and advocating for better approaches with their peers.
The second group — usually in the majority — will be skeptical. They’re concerned about trying to apply new approaches while coping with their current overwhelming work demands. Perhaps they had previous encounters with unsuccessful or poorly managed change initiatives. Management can only make one or two failed change attempts before the team members decide that it’s a waste of time and just proceed with their work as usual. Most of these people will get onboard when they understand the impact the changes will have on their own lives and see the benefits for the project, the organization, and the customers.
A few diehards will lie across the railroad tracks of progress, trying to keep the train from coming through. They’ll skip the training, refuse to try new techniques, insist that their old ways of working are more than adequate, and bad-mouth the change initiative to their colleagues. These resisters might take a passive-aggressive approach, paying lip service to the change effort as they don’t really play along. They might even threaten to leave. And maybe you should help them pack.
Last year, I delivered some training at a development company whose managers were very serious about adopting better software practices to address some clear points of pain. Two of their developers fit in the kicking-and-screaming market segment for process change. Because of the damage these developers were doing, both to the change effort and to the project work, their managers were happy to see them make good on their threat to quit. Naturally, this left the managers having to replace people who had some valuable technical skills. On balance, though, the managers viewed the departure of those few obstructionists as a net positive outcome for team effectiveness and morale.
I’ve worked in organizations where it seemed that no one could make a decision unless anyone who was affected in any way by the decision concurred completely with every aspect of the decision. You can’t always run an effective business or development team by consensus. You can’t avoid correcting a deficient software process simply because the necessary changes might make someone in the group unhappy.
Leadership demands the courage to set strategic directions and provide convincing arguments as to why changes are needed. Change leaders must themselves apply the new practices, thereby leading by example and pulling their compatriots toward the intended objective.
Anytime people are asked to do something different, their instinctive reaction is, “What’s in it for me?” That’s a reasonable response, but it’s the wrong question. The correct question is, “What’s in it for us?”
Sometimes, there isn’t an obvious, direct benefit to an individual developer for doing something different, such as reviewing a teammate’s requirements or code. However, the hour you spend reviewing a colleague’s code might save five or six hours of downstream work for the team as a whole. So maybe there isn’t anything directly in it for you, but consider the collective benefit — to the team, the organization, the customers, the world — before deciding you aren’t going to do it. If you’re a change leader and someone asks you what’s in it for them, you should have a convincing answer.
Development managers and process improvement leaders must include developers when evaluating current practices, identifying valuable improvement areas, and designing strategies for adopting improvements. Change only works when those affected understand the need to make changes and how the changes will affect them. However, don’t be held captive by recalcitrant developers who try to blackmail you into letting them do whatever they want simply because they have plenty of other job opportunities.
I’ve known some developers who wanted to work only in their own preferred way, consequences to the rest of the team, customers, or future maintainers be hanged. People who intimidate managers by threatening to quit if they have to follow a process remind me of a five-year-old who says he’ll take his ball and go home if the other kids won’t play by his rules.
Fortunately, I’ve also known many software professionals who sought out jobs where they could benefit from the application of sensible processes and known effective practices. Which behavior do you want to be a hallmark of your group?