The Developer NPS — Why are you not measuring this?
--
My first instinct was to write this post completely click-baitey: try this one weird trick to improve the happiness of your engineers :)
Organizations measure NPS score of their products through standard surveys. Customer support organizations measure tNPS (transactional NPS) and CSAT (customer satisfaction) regularly. Organizationally, Employee Engagement is measured and analyzed.
There is one additional measurement that most organizations miss out on, that is a must. This is an NPS measurement based on the following question
Would you recommend this code base to a friend?
Why is this NPS score important? It helps leaders understand what the relationship between developers and the code base is. When they start developing, are they scared? Excited? Stressed? My experience is that if you have a code base older than a decade, you will have an NPS score less than -20. In other words, horrible. Engineers dread making changes to this code base. In monoliths, it is the proverbial ball of mud. You make a change here, and something else is going to break.
I use the NPS score — sectioned by teams — to understand where the need for change is the greatest. The NPS score, combined with a code churn score (where is the code base changing the most?) points you the area of the code most in need of reduction of technical debt. (I was going to write about technical debt, but this blog captures it better than I ever could)
The most important thing about developer NPS is to track trends and not be too concerned about current scores. I like to measure it every quarter — if the score is not improving gradually, you are either not spending enough on tech modernization or you are focused on the improving the wrong part of your tech stack.
