People management

The pattern of six-monthly reviews as used at Mastersoft does not mean managers can adopt a set-and-forget mentality between cycles: Krishnan often runs monthly informal reviews to make sure people are clear about what they are supposed to be doing and that their efforts are on track. This does increase the administrative load, so it is not always possible to go into detail on every point with every person.

The best developers are extremely productive because they understand the coding process, can abstractly visualise the problem, and they have domain knowledge that allows them to understand what users need. Combining these skills between one pair of ears eliminates the communication problems that are otherwise likely between different functions, said Krishnan, and so the best developers are "many times" more productive than their lesser counterparts.

"We have no doubt who our best developers are -- it's very apparent," said Harrison, so he believes further metrics are unnecessary. The best developers are five to 10 times more productive than their average to low counterparts, he said.

The company tends to look for empirical data on employee performance only after an individual is judged to be a problem, for example when they persistently miss bugs that someone else finds. This is partly for legal reasons, as it is necessary to show the person concerned what they need to do to reach a satisfactory level before they can be dismissed for poor performance.

But the real goal is to create an environment where top developers can flourish and build great products. Allowing everyone to reach his or her potential is not done through measurement, said Harrison.

Managers need to "look after the talent" and put up with a degree of "attitude" if necessary, said Krishnan. It should be possible to cope with one or two prima donnas in a team. Unfortunately, there is a tendency for the most productive developers to be egotistical, dogmatic and with little respect for their colleagues.

"For cutting edge development you need people like that," he said, adding that while they are valuable, they do need careful management. Organisations certified to CMM level 5 and similar standards do not want bright people like these, as they tend not to follow processes.

Small teams

Like Harrison, Brady favours small groups of skilled developers, which he calls "virtuoso teams." They typically comprise four or five handpicked developers plus a project manager. The use of virtuoso teams is important for high-risk (ie, fast and difficult) projects, he said.

A team focus is important, so KPIs or metrics should reflect that, rather than concentrating on individual activity, said Batt. While it is relatively easy to set KPIs and rewards for sales staff (eg, sales revenue and bonuses), it is harder to arrange for developers, but Batt believes his approach is well received by employees. "People like the opportunity to put more work in and get more out," he said.

Brady's teams are judged on software quality (measured in terms of the number of bugs, memory footprint, recognition rates and so on) as well as timely delivery. They are also kept aware of the company's margins, costs and revenues. "It certainly makes a difference," said Brady, as it makes them feel part of the outcome, as well as helping promote innovation and creativity "which I think are squashed in a lot of development houses."

Individual and group KPIs are not mutually exclusive, so Batt's approach does not mean there are no individual KPIs. Specific targets are written into individual contracts, along with the rewards for achieving them.

For example, Smartpath uses test-driven development. This cried out for automated testing, so a new staff member was given the job of setting up an appropriate environment. "We now have it, and it's fantastic," said Batt.

Other functions implemented this way include internal database management and patch management. One of next year's projects will be to build a new database administration tool, and the corresponding milestones will be among the KPIs for a staff member.

Rewards need not take the form of bonus payments. VeCommerce sometimes recognises developers who meet KPIs by sending them to major overseas conferences, said marketing manager Martin Riddle.

Testing

On the face of it, testing is a more organised process than design and coding, and therefore more amenable to metrics such as the number of bugs detected per thousand lines of code, but as at Smartpath, Quest's approach is to increasingly automate the testing process so that QA people become developers of test suites rather than testers.

Schofield leaves testers and his or her manager to take care of day-to-day aspects, but does correlate field reports of modules failing with the staff that tested them, as well as rating the quality of feedback provided by testers to developers. "[Testers] are very much part of the development process," he said, so they may be involved in discussions about the right approach for the user interface, for instance.

Regular review

Krishnan's approach is similar to Batt's in some respects. Very clear job descriptions are important, setting out among other things key result areas (which may be technical or people-oriented) and specific tasks, along with indicators that show whether the desired outcomes have been achieved.

The six-monthly reviews he favours are to check on previous performance and to set quantifiable goals in each result and task area. This should be a collaborative process, one of "aligning mutual interests", not an opportunity for managers to impose goals on their staff.

This approach means people know what they are supposed to be doing, and it also identifies areas where further skill development is needed. Furthermore, it gives an opportunity to recognise and reward those who have achieved the agreed goals, providing positive reinforcement.

There is a place for qualitative measures in the review process, and Krishnan points out that one objective is to encourage the individual to exceed his or her brief. For example, one key responsibility area is the contribution of good ideas. While it is possible to count the number of ideas floated and accepted, the quality of ideas is more important than their quantity.

Similarly, initiative, leadership and customer service are all aspects that Krishnan wants to encourage and therefore builds into position descriptions, but they are not amenable to quantitative measures.

How do employees react?

"Finding the right people to work in a software development team is very important," said Batt, and once you've got them, incentives work better than a big stick. People then work hard and build quality products, he said.

Krishnan concedes that some people may find his approach too restricting and that it in some cases may contribute to turnover. He suggests a staged implementation can help, beginning with an explanation of the benefits, stressing that it is about performance management rather than performance measurement, and that any skill gaps revealed will be addressed through education. It may be a while before people actually believe this.

In time it becomes a self-management tool, he said, with staff identifying what they have and have not achieved.

Once people are onboard with the idea, more specific metrics and more explicit financial and other rewards for achieving agreed levels of performance can be introduced.

For developers, "it's not all about the money," said Brady, so managers need to tap individual motivations.

KPIs should be used to develop individuals, not to punish them for failure, Krishnan insists. "It has to be done in that positive manner, or it fails."

He believes most of his staff recognises his approach as being mutually beneficial. It did take time to build their trust, but providing positive reinforcement helped.