How do you measure the output of an engineer within a software team?
Lines of code is not the right metric.
I once, as a programming exercise, wrote a tool that showed the contribution to the codebase of each team member, on the basis of the git blame for the head of main. It taught us very little. It taught us that I did more refactoring and reformatting than other team members, or had moved more code around.
So, you can’t measure the lines of code of a team member and discover something useful. Indeed, some of the gnarliest problems I’ve seen solved in a team took the right 3 lines of code, rather than many thousands in order to get right. Indeed, sometimes it’s code deletion that’s the biggest contribution to improvement, rather than addition.
It’s also unreasonable to think the people only contribute to the team in terms of just making software change.
I challenge anyone within any software team to avoid falling into the trap of thinking one’s input is equal to one’s output, though.
You may well be spending many many hours at your desk beavering away, but you need to ensure that that time is spent as profitably as possible. I think that may be measured against three outcomes. If you’re not achieving these outcomes, then perhaps the time is being spent, but the value is not being realised of that time.
- Deliver customer value/results
- Acquire knowledge for the team
- Provide support to the team
Let’s unpack those.
Delivery of customer value is the most clear metric of software development success. That value may take the form of features, or the form of things to protect the continuity of development at the expected level of quality and speed. If our actions result in things getting better for customer delivery, then we’re adding value.
Acquisition of knowledge, or sharing knowledge, is clearly another piece of value. By bringing knowledge to a situation, the team can do the first objective more effectively. There have been days where I’ve simply spent my time answering questions and mentoring people, and though I might like the pleasure of making some software myself, clearly providing the means for others to do so scales much better.
People in the team, who increase the amount of knowledge in the team, are adding value to the team. This is slightly distinct from people who acquire knowledge for themselves, if that knowledge is either not relevant, or not reaching the rest of the team.
Finally, providing support to the team is the most important thing. This is not restricted to leaders within the team. Sometimes someone needs a rubber duck to help them with debugging. Sometimes someone needs a friendly interaction to keep their energy levels up with a hard problem. The morale of the team is part of how people find the resources to deliver energetically on mission. Supporting team members involves being engaged with them and being positive about how the final result is always a win for the group, not the individual.
If you cannot claim to be making progress on at least some of the above criteria, then it’s worth reviewing where your efforts are going.
However, if someone comes along and tries to put numbers to the above, then it’s really tricky. A good team is measured by its output and its development, as a whole. Generally, if everyone in the team is motivated, happy and engaged with each other, then you’re getting it right.
The Coding Craftsman 