Introduction
This post is the forty-eighth part of a ramble-rant about the software business. The current posts in this series can be found on the series landing page.
This post is about Performance-Based Management (PBM).
Almost…
In Mere Christianity, C. S. Lewis refutes an argument with the following statement:
It has every amiable quality except that of being useful.
I feel the same way about PBM.
I am a metrics person. I thrive – intellectually, emotionally, and economically – on business intelligence and KPIs and dashboards. I love data mining and predictive analytics. Measurement, analysis… this all appeals to my engineer’s nature and “instrumentation-eer‘s” heart. When it comes to Performance-Based Management, you’d expect me to be all in. And I was, almost.
There I Was…
… sitting in the cat-bird seat. We were a team of five charged with expanding a successful data warehouse. We had a person who wrote special one-off applications for data mining, an awesome business analyst, a great report-writer, a guy who knew the source system like the back of his hand, and me – the SQL Server database guy. The company had implemented a 20-60-20 PBM scheme after someone who’s title began with the letter C read a book and thought: “Why are we wasting all this time thinking and leading and managing when we could just lump people into one of three buckets and be done with it! Think of all the time we could spend reading more cool books!” Ok, I’m not sure why it was implemented; that’s just my theory. But I digress…
With five people on the team the math worked out perfectly. We would have one “top 20” person, one “bottom 20” person, and three “middle 60” people. Awesome. Except how do we determine who goes where? By luck of the draw, I happened to solve the big-problem-du-jour the week before the managers were to submit their suggestions for rankings. I won the PBM lottery, as it were. The person who had been in my position earlier, and who had contributed to my success substantially, was ranked last. The other three were lumped into the middle 60.
Here’s my first question: If we are a team and we each have vastly different roles and we are each good at our job, how do you determine who outperforms the others? PBM has a smarmy answer for this scenario, and that answer has every amiable quality except that of being useful.
What really happens in this scenario? It turns out that it takes a village to build and maintain a successful and useful data warehouse project. In other words, a team. When everyone contributes to the success of the project, a positive spiral is created. Everyone realizes they are their brother’s keeper; that the success of all hangs on the success of each. What’s more, teamwork is easier. It requires real effort to produce anything of value single-handed.
But wait there’s more! Because more eyes are on the work, quality improves. The quality percentage for a useless data warehouse – the ratio of good data / bad data – is a surprisingly high number. This is due to how the data is used, mostly in aggregation. Constraint Theory teaches us that losses accumulate, gains don’t. In a data warehouse project, the impact of incorrect data or the incorrect application of data is exponential. If you don’t believe this before your first data warehouse project, I bet you will afterwards. It turns out this “friendly competition” kills teamwork faster than anything else. Good people feel less motivated to help because they are punished for the success of others.
Punished? How?
I’m glad you asked. In the version of PBM through which our team suffered, the top 20 person got everything they wanted. The bottom 20 person was basically ignored until they quit or were fired. The middle 60 were alternately tolerated and encouraged to be more like the top 20 person. But we were all good at our jobs!
That didn’t matter. Only the buckets mattered.
And this is one of the reasons PBM stinks: It kills teamwork.
My Question
Upon learning the mechanics of PBM, I asked the following question: “Are we hiring the wrong people or are we mismanaging the right people we hire 80% of the time?” I think that is the right question.
Conclusion
I have witnessed many peers subjected to Performance-Based Management. To a fault, everyone suffers. PBM is an application of the manufacturing mindset to modern business and it fails to recognize important facets of creating technology. The goal of PBM is equally noble and unachievable.
It. doesn’t. work.
The only metrics that count are shipping and delighting consumers. Good luck breaking those metrics into measurable steps. You can waste time with PBM or anything else that is-not-creating-art. It’s your call.
:{>
Excellent post, Andy! I’ve been enjoying reading the series. I have seen PBM from many angles (having written software used by Industrial Engineers to develop metrics to having a small say in how metrics are derived for teams I’ve been on). These days, I find myself asking the question, "by instituting these policies, what true motivators are we putting in place?" For example, in your situation by encouraging the "60" to be more like the "20", is management encouraging them to strive for perfection? Or, more likely, is management engendering a kind of false competition for a goal that doesn’t exist (i.e. there can only be X members of the "20", which means the "60" works hard to alienate the weak while lying, cheating & stealing their way into the "20"). The approach I tend to prefer is dealing specifically with individuals and working towards getting their goals aligned with our business needs.
I must say I agree Andy.
I’m happy to say that my current employment uses role based performance for its raises and promotions.
If you meet the qualifications for the next level up in your technical or management path you’re promoted. This gives incentive to those people whom want to take on more responsibility and perform well.
From what I see it is quite effective, although I haven’t been here quite a year as of yet.
I almost got tossed for being a manager in this type of system. We were told to rank people from 5-1 (highest-lowest) and that we should end up with a ratio that was somewhat pre-determined for our department. Each manager might have a skewed distribution in their 5-12 people, but if the department (100-200 people) didn’t fall into the ratios, we’d have to "adjust" rankings.
I said something unflattering in a large meeting of managers and none of the directors or VPs broke the silence to fire me. Eventually someone told me we’d have to live with it.
I had a team of 10. I learned I couldn’t rank anyone a 5 without substantial justification. Ones were easier to give out, but they would result in an improvement plan, and if the person got a 5 the next period, they would be let go.
I ended up with too many 4s, and had to move a person to a 3, and had to put someone as a 2 since I didn’t have any. In a relative sense, I picked the weakest individual as a 2, but in an absolute sense of what they were doing for the company and in their position, they were clearly doing what was expected and should have been a 3.
I walked away thinking I’d never work in that type of environment if I could take care of my family another way. It was silly and resulted in a dysfunctional group that is much like what you describe.
As an HR person who sits on the other side of this PBM process, here’s my 2 cents worth…often we are as much of a victim of C suite people reading a business book on the plane or taking an executive leadership course and coming back to the office with a great new idea!
HR people don’t necessarily always agree with the ‘flavour of the month’ business theories but we are expected to support it and make it work.
I believe the idea behind performance management is a good one and I’ve seen it in action with excellent results.
Hear me out…. No, I’m not talking about the 20-60-20 model. I’m talking about when an employee doesn’t seem to be meeting expectations, sit down with them and have a conversation to see what’s going on and if there’s something which can be done to fix the issue. I find that often being really clear about the job expectations can solve a lot of problems. I’ve seen guys go from being on a performance program to being solid, happy employees when we’ve taken the time to talk and be supportive.
So there ya go, an HR perspective. Sure there are HR folk who don’t see it this way, maybe they’re not courageous enough to mention that the employer has no clothes or maybe they’ve drunk the cool-aid too. But at least you know lots of HR professionals agree with you.
Thanks for your comments and insights, Bobby, David, Steve, and CM.
CM, I sincerely appreciate your insight. HR is difficult enough. It has to be even more difficult in technical operations. It *has* to be satisfying when you impact someone’s career in such a positive manner.
:{>