Value vs. Productivity In Software Development Teams
Most software development companies measure productivity of teams and individuals. Those measurements are then used to rate an individual’s or a group’s performance. Numbers are so nice, cozy and familiar. They make things simpler; and if someone’s productivity can be objectively rated with numbers, lucky is this person and lucky is the manager of this person. The person is lucky because the clarity of numbers backs the clarity of expectations, and if someone knows that they may get a raise if they hit a certain number of whatever, that’s great. Managers are lucky because they are spared the need of figuring out how the heck to rate people, so they can be given or refused a raise, or a promotion, or a reward. However, in some cases mapping the actual value of an individual’s productivity to numbers might be challenging, if not at all unattainable.
Let’s look into the reasons why individual productivity is measured by counting things, historically. This practice can be traced back to material production, that is, to any activity that produces tangible things. If a farmer picks 100 vs. 50 cabbage heads per day, just an abstract example, this is surely good. One can not let a cabbage that is ready to be harvested sit for too long out in the field; it may fall prey to pests, etc. With cabbages it surely makes sense to move fast, if we’re concerned with harvesting solely. By the same token, a baker who runs a bakery on a busy street is more productive if he or she bakes & sells more croissants. The logic is flawless: more croissants, more customers served, more profit.
With this measurement model looking so clear and simple, it’s very tempting to copy-paste the practice of “more is better” to knowledge work. The non-material production. They used to measure productivity of developers by lines of source code produced per certain amount of time. I wonder if someone still uses this metric. One smart person has something to say about it.
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”
Other equally poor attempts to measure productivity include: count of bugs discovered by a QA (what if this person tests the heck out of a feature, making sure it’s clean, and finds no bugs?); the count of words in a written piece, or the count of graphic icons designed per day. These are abstract examples, and, thank God, it looks like most of the software development companies have moved away from those naive metrics. The less is more adage is grasped better now, when we seem to live in the age of super-abundance of everything. Which doesn’t save us from the chronic shortage of value.
That’s the word. Value. How much shippable, valuable, finished work has this person done? Working many hours is far from being equal to super productivity and, after a certain point, indicates inefficiency. What I call “productive” is when one uses time wisely, rather than works around the clock. Then, the individual work aside, which contribution is this person making to the group? What does he or she do to improve the workflow, or to keep the integrity of the team in a non-shippable way? Naturally, being a group contributor removes bits from the individual contribution. What if this person contributes at a larger scale, beyond their core skill? Then, how to factor in the subtracted individual performance when measuring productivity?
With these intricate nuances, I wonder if someone is ever able to quantify them as a numerical measure of productivity. Surely, the kingdom of AI, data, tests and grades has its doors always open, as it attends to the needs of busy managers looking for fast and clear ways to rate a person’s performance. But, as often is the case, the flip side of fast is slow. Individuals concerned with the team’s success are the keepers, and if a numerical grade fails to code the value of this person correctly, they might be demotivated. We all are human, and managers are human as well, in case someone doubted that *ironic*. The managers want to rate the performance of teams and individuals faster, especially if a company is large. But how can stakeholders be 100% sure that they can trust the scoring — or data-driven — methods? In many cases, it might make more sense to stick to the old-school ways: observe people, what they do, and see if their activities, shippable and non-shippable alike, bring value to the company.
It sometimes takes years for judges to be ready with their rulings. It might take what appears to be an eternity for a snail to figure out what’s inside this bubble. A rainbow or gas stains? But the time spent on deciding is well worth it.
This article has been re-written from its earlier version.
