When you are evaluating how people are doing, it seems reasonable to focus on the business results they deliver. In my previous team, we called this the relay race model. What matters in a race is finishing, and finishing with the fastest time. Nobody cares whether your running form was good or terrible – you are measured solely on the results you deliver at the end. In most work environments, this is appealing, intuitive, measurable … and wrong.
A diving competition is almost the exact opposite of a relay race. After all, everybody is going to hit the water, and it will take about the same amount of time no matter what you do. The score is based on your form – how difficult a set of moves you undertake, and how gracefully and perfectly you do them.
Why the Diving Competition Matters
So what does this have to do with measuring job performance? It’s the difference between assessing the pure business results that somebody delivers vs. the way they delivered those results.
It’s easier to measure (and talk about) the results that were delivered. Did the product ship? How much revenue did it generate? Did you hit your sales quota? Was the code quality where it needed to be? Is the product performance hitting the ship goal? It depends on your job, of course, but in many cases it’s relatively straight-forward to tell whether the person and/or the team achieved the goals that they were striving towards.
But there is another side of things – the way you behaved in pushing towards that goal. Did you help build up the team? Do people find you a good person to work with? Do you help make the whole team better, smarter, and more capable? I’ve worked with a lot of aggressive young engineers, and they sometimes are very impatient when I bring up these questions. “Hey, I wrote the code, the product shipped, and it’s good. I didn’t have time to humor those other idiots – we were on a tight schedule. And I was right, wasn’t I?” Often, yes. But you are still going to get dinged on your review, because you may have been right about the issue, but you didn’t handle it the right way. By running roughshod over the other person and leaving them feeling dismissed and mistreated, you blew it. Why?
Well, for one thing, you are only responsible for part of the project. Checking high quality code into the build is important, but the crucial thing we need to do is solve the customer’s problem. Which means we need to understand their problem holistically, build a complete solution that meets their needs, test it, explain it and then sell it to them, support it, and integrate with other products. That calls for a group of people to work effectively together.
Also, a particular deliverable is just one in a long succession of business results that we have to achieve together. Sure, we shipped the product .. but that was just the beginning. Even with packaged software, we have to ship patches. We immediately start building the next version. If it’s a service, shipping is the beginning of the hard work, not the end – now we have to run it 24/7 and manage the business that is based on it.
All of these ongoing business deliverables rely on the team working smoothly together. When you are working on a problem that involves groups of people, no single person’s work alone can make the whole group successful. If you achieve the goal you are focused on but leave a path behind you strewn with dead bodies, you can easily do more harm than good even if you do achieve what you set out to do. Every team member has as much of an obligation to help ship the team as they do to help ship the product. Given our ongoing responsibilities, the team is often the more important deliverable. In the software business, if we create an unpleasant working environment and everyone leaves, we’ll be left with a big pile of code and no ability to run it, fix it, evolve it, support it, and sell it.
So for very hard-headed business reasons, I think it is necessary to evaluate people based on both the relay race model (the explicit results they achieved) and the diving competition model (whether they work effectively with others). If you only focus on one, you aren’t encouraging and rewarding the behavior that yields the most value for the organization. And on a more personal note, who wants to be on a team that’s unhappy and mistreats each other?