I often ask the question “How can we properly work out pay for performance?” For some teams it sounds pretty simple. Sales, for instance, has some relatively simple metrics. How many encounters? How much did you sell? It’s a little more difficult for Engineering. Here’s an example that I often see:
A great product team gets together and builds an amazing product or service. Product Marketing provided valuable customer feedback. Product Design uses that feedback to designed a great product that removes customer pain. Development builds it on-time and under budget, and QA ensures a high-quality product. All of these teams work together to build an awesome product — often with long hours and a few miracles along the way. As a result of these efforts, sales go through the roof. Unfortunately, all that means is Sales gets the most benefit (monetarily anyway) from the the other teams efforts because their commissions go up.
The question is how does this work it’s way back to the other teams? Should it? Unfortunately, there is no easy answer because there isn’t any way to figure out how much an individual contributed to a product. At first, I thought we could come up with a scheme to reward a team for their contributions, but even that doesn’t always work. In the world of Agile and Scrum, there is a concept of BVI (Business Value Index). I often use BVI to help prioritize stories for completion. In a nutshell, BVI is the percentage contribution a story has to the overall value of the release. So, if a release is projected to bring in $1M in revenue, and a story has a BVI of 0.25, then that story’s Business Value (BV) is $250K. In theory, you could then use the combined BV of a scrum team’s story output to come up with that team’s contribution to the final value. Unfortunately, the reality is not that simple. Often, stories have a BVI of 0 even though other stories can’t happen without it. A story to refactor a class to make it more maintainable has no impact on the customer and, therefore, no BVI. It does impact cost, so maybe we could add a CVI (Cost Value Index) to those stories without BVI.
To some extent, CVI can have even more impact long term. A story with a BV of $250K will always be far less on the company’s bottom line. However, a story with a Cost Value (CV) of $250K goes straight to the company bottom line. Plus, developer’s spend less time on maintenance and more time developing, and that makes everyone happy.
Cost Value sounds like a great idea, but it is extremely difficult to calculate. In fact, very few organizations pay much attention to it. “We can’t spend 80 hours automating that process. There isn’t time.” The part that people forget is not having the process automated is costing 10 hours per week. Let’s say one developer takes the two weeks (80 hours) to automated it, then your total cost is 100 hours (you still have the 10 hours/week without automation). For your 100 hours of cost, you saved 480 hours over a year (48 weeks * 10 hours/week). That’s 480 more hours to spend on actual product development.
CV = Net savings per year
CVI = Percentage contribution to the whole
I need to think about this some more, but I’m curious what people think. The biggest problem with this is a breaks one fundamental rule in Scrum. That is to properly calculate CV, you have to track how much time people are spending not doing their tasks, and we know we should only be tracking how much time is left.
What do you think? I don’t like the idea of tracking time, but I do like the idea of being able to prioritize a story that reduces costs along with a story that generates revenue.
I will leave you with a great quote. I don’t know who said it, but it is so very true.
“Organizations don’t get what they want. They get what they measure.”
Leave a Reply