An honest performance appraisal will keep things on track.

Review Your Tech Team

An honest performance appraisal will keep things on track.

• By Greg Neilson
• 10/01/2000

Rather than having Greg and Steve answer one of your questions this month, we invited them to choose a key career topic that they haven’t been asked yet in this column, but that they’ve been burning to talk about.—Ed.

Greg Neilson says: First, I want to tell you about a situation that I hope will illustrate that technical skills alone have a relative importance on the job. A couple of years ago, I had a leadership role in a team that managed the LAN environment for the whole company. This included a central administration team and onsite staff in cities across the country.

Many members of the team were re-deployed from other areas of the company and had to learn everything from the ground up. But one member stood out from the others. A former marketing person now in a technical role, he never seemed to understand many technical concepts. What he did learn took ages to sink in. Technically, he was a long way behind everyone; I doubted whether he’d ever catch up.

Yet he would work long and hard to keep the users at his site happy and often relied on his technical contacts throughout the company to get him through. From his marketing background, he really knew how to cultivate useful contacts throughout the company. That’s in distinct contrast to most technical people I know who often like to keep to themselves. The people at his site absolutely loved him, yet because of his lack of technical knowledge, I wanted to have him removed. My manager at the time disagreed furiously with my assessment. As long as the customers were delighted (and they were), she didn’t care how he did his job.

It took me a number of years to be able to look back at this situation and realize that my manager was right all along. The key was what this team member was able to do, not how he did it. If he could use his contacts rather than his technical abilities to get the job done, so be it. The bottom line usually isn’t how someone works, but what he or she produces.

Another lesson: A few years ago, I was team-leading a group of contract developers. I had high hopes for one of the programmers; since he had more experience than the others, I was paying him more. But after two days, it became evident that he didn’t work as quickly as the rest of the team. I felt obliged to call him in and tell him that I’d have to end the contract unless his productivity improved. He made a concerted effort but never reached the productivity level of the rest of the team.

Shortly after that, he began to prove his value. We had a data corruption problem in our system that no one was able to solve. This consultant had the patience to sit down and methodically determine the source of the problem (another system) and the mistake that had caused it. From then on, I assigned him to all of the difficult problems that no one else could get to the bottom of; as you can guess, he did well in this role.

From that experience I learned to be careful in comparing developers (or anyone, really) strictly on the basis of productivity. Some people naturally want to get a job done as quickly as possible; others want to take a considered and methodical approach. Just because someone’s approach doesn’t match yours, don’t jump to conclusions.