Measuring Platform Team success through Developer Happiness
Our platform team provides services underpinning the work of something in the order of 1,000 people spread across different roles - developers, architects, support engineers and so on. Each month, there are hundreds of thousands of interactions with our tools - almost all of which are automated through CI. As the Product Lead, I am often asked how i know what to prioritise next in delivery and the answer is simple - we measure Developer Happiness. now don’t get me wrong, i want our developers to be happy, but it’s not that i specifically care about developer happiness in itself. happy developers are great, but in this case what i’m looking for is things that are annoying them - i’m using Developer Happiness as a proxy for all the things which we’re not measuring (or simply can’t measure) but which annoy the teams on the ground as they try to get their job done.
