The shifting manager: How can I measure the productivity of my software employees?

Hello to all of you, especially the ones who are managers and are struggling with this question!

In two of the last three organizations I've worked for, this question was raised. The same two out of the three were the ones under an agile transformation process. I don't think that's random, but let's not jump to conclusions just yet.

Here's my attempt to clarify the actual problem and solve it, but to do that we'll need to brainstorm together a few things:

What is being unproductive? (Might these be some of your assertions?)

"Takes too long to get what I want."
"Things are never 100% done."
"Nobody seems to feel the pressure."
"They don't look busy."
"Stories take longer than estimated."
"Delivered on time but full of defects."
"We used to do things faster."

How does a developer look like when he's staring at nothingness and losing time?	How does he look when he's solving a really complex issue?
Well more or less like this:	Very likely he looks like this:
So... we might need to drop measuring by appearances.

What is productivity and how is it measured?

"The number of features"
"The function points per release / The velocity"
"The amount of people in the office at 9 am / at 6 pm"
"How busy people is"
"Amount of stuff getting done"

Well you are not quite there yet.

Maybe outputs (value) / inputs (cost) ?

That's closer. But what's value then? If we measured the outputs then we would miss the actual outcome.

We should aim to measure outcomes vs inputs. Now if I sit on my assigned space doing nothing for 9 days out of my 10 days iteration, and on the 10th I create a feature that gets the company to save 1 million dollars, was I productive?

With software you don't "do" a thing, you get a solution, a variation in how people works, hopefully an improvement.

In a factory, the thing you create let's say mattresses for analysis purpose in this case: The worth is more or less the same as the last one Fairly clear value The order doesn't matter much Outcome is a more or less equivalent to outputs. More mattresses, is directly related to more productivity.

Now with software is no longer physical motion producing goods. Wildly varying worth, equal time spent on two features does not grant me an equal benefit out of those two. Much less certainty about the needs Order of delivery significantly affects the value Outcomes are no longer the same as outputs. 60% of the features we produce are never or seldom used ¹.

"Programmer", as with some other particular employments, is not something a person chooses because of the payment -at least not at the beginning- but because you like being able to create, to solve what's in front of you. I remember being in a organization already working with agile values in mind, where they had a more Californian perspective of work, and they had a Foosball, and a PlayStation among other entertaining items. Being there, I once overheard a "new blood" manager, concerned, talking to a more seasoned one:
     "My guys are working on something important" - said the seasoned one.
     "But your four guys are playing a lot of Foosball in the week" - answered frowning.
     "Then it must be really difficult to tackle".

The Helium balloon theory says that people goes to work because they want to be productive, and they'll try to be as productive as they can, until they are stopped by uncertainty on what to do next, meetings, bureaucracy, lack of permissions. They do take breaks, but that's because the brain overheats. 

So you shouldn't measure programmers the same way you measure non-programmers.

Each of the developers owns a single brain. And there's not much you can do with just one, so the best way to destroy your productivity is to measure it by tasks per person. If you want things done well and quickly, add enough people to that task so that it gets as partial brains per task as the team considers they need, instead of people per task. That way you can get things done that matter, and more importantly filter out the things that don't matter, by having more brains involved on the task.

This is counter intuitive with the previous system. You produce here by combining, sharing the learning. The goods are intellectual. So wrapping up, as a manager is understandable that you expect to measure something like this, however the short answer is that if you are looking into productivity of your employees individually as a measurement towards the end product, you might be looking in the wrong place. The outcome is created by the group and not a couple of individual brains, so you should instead find a measuring of the outcomes, of how this impacted the users, of how this fulfilled the goal it meant to achieve, to compare it against the inputs, as a unit of measurement.
The measuring unit will depend on the goal the product is trying to achieve, but here I share you at the top of my mind a few ideas: try to look for metrics like money you've earned with this product,  or user's feedback on it.
These are things that sadly you won't get right away by measuring something in your issue tracking tool of preference, but under this world shift that started in the information age, where the intellectual capital is the new value, you'll need to pivot as well to start getting the right metrics. (see measuring success in companies pivoting to agile).

What if I don't trust a particular employee's performance?

(Source)

Now if this question you had was raised by your concern that "there's an employee that is not performing well within his team, and might be dragging his teammates down to a non-working sinkhole", then rest assured that it will be addressed by your team. Trust that your team will try to help that guy move forward.
 If their efforts prove unsuccessful, do not despair, I know it's hard to be a manager and having the obvious power, not take direct action to solve the problems, but since this is no longer command and control, this is not in your scope until the self organized team involves you to help them, and they will involve you eventually.
No one likes to be dragged down. The most effective way to administrate this situations is to delegate them to the ones struggling with this, until they ask for help. Be dynamic, you can always ask if you are needed, and also you can evidence with them the facts you are seeing, to trigger actions from the team, but avoid overstepping their self-organization empowerment. This will make your teams aware that they are the real owners of their problems, as you'll show your trust on them to act accordingly.

If you still feel that that is a way to let the developers roam way too free, then I might get something else to brainstorm specifics on what can be measured in my next entries, stay tuned and let's keep working towards finding the path together!