Tracking Developer Productivity Isn’t Productive. How Do We Fix It?
My name is Jeremy! I am working with StartupLandia to help build the best startups in the world. Please, reach out if you thought this was helpful or have any questions!
The idea of tracking productivity on an engineering team isn’t new. We have been trying with varying levels of success since the creation of the personal computer. So, why are we still talking about it? Shouldn’t it be solved already?
I am going to try to cover a few topics here, including what productivity is, some common methods of tracking it, and how we can change to meet the weird new world of remote work.
Productivity isn’t just one thing, so what are you trying to track?
If you search for the word productivity, you won't have to go far before you see a dozen articles about SPACE. In short, SPACE is a framework aimed at measuring several dimensions of productivity, including satisfaction(Important later), activity, collaboration, and Flow. It documents how “productivity” should be measured as a collection, and leaving any of these out, or failing at them all together could lead to false negatives.
For instance, if you measure satisfaction as lower than normal, but fail to track or encourage collaboration, you could enact policies to improve satisfaction and never see an improvement. The two are tied together, and any solution to one might just mask another issue.
If we look past SPACE, we can start to talk about things we can actually DO.
But, first!
Our KPIs seem fine, but we still missed a deadline and two people quit!
Turns out, a KPI like “increasing the number of deploys” doesn’t cover all the needs of your engineering org. I would go as far as saying it hurts more than it helps.
In a worst-case scenario, your leads focus solely on increasing the number of deploys. This caused a few issues early on, so you decided to enforce QA on each deploy. Now, your QA team has gone quiet. You are seeing them online at weird times, and they aren’t responding. A bug takes down production for 2 hours.
For some reason, in cases like these, I see people double down on their goals. They get some sort of Stockholm syndrome and look anywhere else to place blame.
In reality, the KPI alone didn’t have a chance. Not without considering other aspects such as collaboration.
What can we do then?
Something as simple as encouraging early testing, or an “ask first” policy where people can raise programming questions publicly before spending hours solving them might work, but I think the real answer is to look holistically.
Look at how your org is responding to your changes. If your slack has turned into a ghost town, or if your failure rate has significantly increased, you might need to give it a push start. Do your best to identify these issues early and allow your team to be a part of the solution.
What are your thoughts on tracking and increasing productivity? I would love to learn from you all, so feel free to leave a comment or email me at jeremy@startuplandia.io
Thanks again to StartupLandia for allowing me to share my experiences. If you want to see how we can help you and your company grow, come on down to StartupLandia.io
