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.
:{>