Why You Should Measure Productivity
10 May, 2018
There are a lot of reasons that can feed into whether a team is productive or not. One of the bigger barriers I see is that most engineering leaders think that understanding and evaluating productivity is bad.
Productivity in Engineering has become a bit of a bad word and even measuring it can be frowned upon. However, if you don't measure productivity you won't have as much ability to improve, and as a leader, one of your main jobs is to help your team to be as productive as they can be. Productivity can be a really helpful indicator. Always start from a team or project level and expect that whatever metric you come up with will be, at best, directional. The point of a metric is to give an indication of when you should raise a conversation about what could be done better to help productivity. The specific metrics I find most useful are volume metrics (e.g. stories, story points, tickets) and how often the team hits milestones they set. These metrics help you to detect anomalies. For example, if the number of tickets you close dips for a couple of weeks you can then investigate what is going on. Usually, there's an obvious reason for these types of anomalies. If there isn't an obvious reason, that usually provides you with an opportunity to improve something - e.g. your tooling may be breaking down or the number of distractions may have gone up.
A lot of the stigma around measuring productivity comes from people who don't understand engineering asking for arbitrary metrics and from unskilled leaders not knowing how to use the information and using it to penalize teams. Metrics of productivity are really useful. However, when using them, just keep in mind that metrics don't tell you the story, they just tell you that there's a story there.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
This was not a high point in my career. It's a story of single metric bias, how I let one measure become a 'source of truth', failed to manage up and ended up yelling at one of the most respected engineers in my team.
Chief Technology and Product Officer at Hive Learning
Supporting principles on why being data led (not driven) helps with the story telling.
Head of Engineering at Xero
When you grow fast, its normal to focus on Value delivery aka "Feature Releases". Too many releases too soon will inevitably lead to piling tech debts and before you know, inefficiencies creep in, performances goes down, and ultimately any new release takes too long. Sounds familiar? Then read on..
VP - Engineering at ITILITE Technologies
Teams have tremendous impact on the products on they build. T.E.A.M definition - Together Everybody Achieves More is true. A collaborative and empowered team builds great product versus the good ones.
Senior Software Engineering Manager at Anaplan
Tommy Morgan, VP Engineering at Crystal Knows, recalls a time in his career when his values didn’t align with his superiors and shares his insights on preventing this outcome when taking on a new role.
Head of Software Engineering at Tidelift