Today’s topic is a bit abstract so I’ll start with a concrete example:
Earlier this year Michael Mallete gave this lovely talk at Agile Singapore:
It’s well worth an hour of your time, but if you can’t spare it, at least skim through the slides.
Here’s the gist: performance reviews are being used for six different purposes: improve company performance, provide career guidance and coaching to employees, improve feedback and communications, manage salary and benefits, facilitate promotions and justify terminations. Since it’s stretched it six different directions, it does a very poor job supporting each of the purposes.
A typical case of “jack of all trades, master of none” / “a bird in the hand is worth two in the bush” / <insert your favorite proverb here>. I’ve seen this pattern enough times to give it a name: functional overloading. Another common area where you often see it is the product roadmap: is it a planning tool? a marketing tool? an alignment tool?
We usually end up in these situations while having the best intentions in mind. In an attempt to keep overhead/bureaucracy to a minimum, we try to use existing practices and tools to solve new problems by slightly tweaking them. But in the process, we end up stretching them too thin and overloading them.
In the case of performance reviews, Mallete advocates for an extreme approach: go back to the basics and tailor the most effective tool/practice to each one of the different purposes that we were using the original one for. I think this may be too aggressive at times, but some fragmentation of the existing tool/process, even if it’s not to its most basic components, is probably in order.
Your turn: what are the most common tools and practices that you’ve seen get functionally overloaded?