> Whether you’re a C-level leader or a frontline manager, there is no denying that measuring developer productivity—whether to understand performance or guide improvement—is a daunting challenge.
good
Focus on the stuff that matters, not on tormenting the people that make you money.
Yes, I’ve worked in companies that use DX. Generally you get a survey once a quarter, and you can see some basic stats like how many PRs/code reviews are happening.
My company leadership does not use these as a one size fits all metric. In fact, the code review & PR stats never even show up in performance reviews. Mainly, they are used to improve systems around dev productivity. Like, we see that generally, we’re shipping less PRs and the survey shows people think it’s getting slow to merge changes. That is an opportunity to look at where our systems are holding us back.
I think broad stats are also probably still useful too. For example, there have been times that I’m reviewing more code than everyone on the team combined. I WANT my manager to know that’s happening and figure out how to even the workload. Or, why is my team shipping like 2-3 times as many PRs as a similar team with similar headcount? It’s not immediately a PIP or something, but it’s highly likely something odd is happening. Could leadership improve direction & focus, make priorities more obvious?
It is called "not wanting to work in a company that is insulting me with measures like metrics, spying on screens, squeezing every drop of sweat and exploiting its
workers for already huge profit.
My last job change was exactly due to company acquisition by USA company that started to exploit everything work related, removing wfh, ruining life-job ballance,... And who leaves first? Those who can.
So you are not really measuring developer productivity but helping company get rid of most productive people, while all others stay.
Developers don't like being measured for good and bad reasons. The good reason is that there is lots of effort that we expend that isn't always captured in metrics like long pieces of design or training others etc. The bad is that we don't being told that we aren't as productive as other people even if we are!
My experience is that these are only useful over a long enough period and across enough people that we can spot genuine outliers. For example, your average across the last 6 months is "15" and the average of everyone else is "25", can you help me see whether you are being given too much off-target work or are there any other issues that are blocking you getting stuff done?
The problem is that there are so many people involved in software development who have never developed anything but still somehow are in the position to manage others who do.
That's why there are so many stupid ideas floating around.
I don’t think the product is all bad; my co is using it and I feel like it is giving us some useful signals about our internal dev UX that my team can action on; we own the base level dev tooling.
my current place uses DX and it's well received, if done transparently and for the right reasons. there's a lot of very interesting research in these areas (e.g. EngThrive) where the focus is on measuring things that if gamed result in better outcomes
there's strong correlation when onboarding an engineer between the time to first/tenth/fiftieith PR and their PR throughput two years later, so the answer is make it really easy to do PRs when onboarding, and they saw the same outcome even if those initial PRs were trivial
through DORA/SPACE/DevEx they also found that asking your engineers if they feel productive is generally as useful and reliable than trying to measure every possible dimension - which is why DX is based largely around the survey with subjective responses. if you actually use those responses to address friction and frustration, from my experience you end up with more, better, easier work getting done
it's possible to work in a team that cares about measuring their effectiveness, and using those measurements to understand how to be more effective. most/all engineers will have an idea of how they could improve their work, but the reality when you actually spend time to measure often shows a lot of different things you might not have been aware of
With all of these developer productivity metrics, perhaps developer teams can also measure productivity metrics of management up to the top.
When it is decided that a management resource such as a line manager, director, or even C-level exec are causing detriment to organizations they can be put on performance improvement plans —which involves developers simply ignoring anything and everything that person says until they stop speaking nonsense.
For many countries in Europe DX is a dead product because we aren’t allowed to monitor individual contributor performance in this way, only performance monitoring at a team level, and the only if those teams are large enough that you can’t distinguish IC’s.
I think that’s a good thing, and I say that as an engineering manager.
Having been an IC, I’m acutely aware that developers, when aware of monitoring via performance metrics, will game that system.
I never understood what Atlassian saw worth $ 1 billion in this company (DX). That's even more than what they paid ($700m) for Loom. Loom is at least useful as a screen recorder, and its notetaker (in Zoom calls) is pretty good as well.
24 comments
[ 0.25 ms ] story [ 33.8 ms ] threadgood
Focus on the stuff that matters, not on tormenting the people that make you money.
My company leadership does not use these as a one size fits all metric. In fact, the code review & PR stats never even show up in performance reviews. Mainly, they are used to improve systems around dev productivity. Like, we see that generally, we’re shipping less PRs and the survey shows people think it’s getting slow to merge changes. That is an opportunity to look at where our systems are holding us back.
I think broad stats are also probably still useful too. For example, there have been times that I’m reviewing more code than everyone on the team combined. I WANT my manager to know that’s happening and figure out how to even the workload. Or, why is my team shipping like 2-3 times as many PRs as a similar team with similar headcount? It’s not immediately a PIP or something, but it’s highly likely something odd is happening. Could leadership improve direction & focus, make priorities more obvious?
It is called "not wanting to work in a company that is insulting me with measures like metrics, spying on screens, squeezing every drop of sweat and exploiting its workers for already huge profit.
My last job change was exactly due to company acquisition by USA company that started to exploit everything work related, removing wfh, ruining life-job ballance,... And who leaves first? Those who can.
So you are not really measuring developer productivity but helping company get rid of most productive people, while all others stay.
My experience is that these are only useful over a long enough period and across enough people that we can spot genuine outliers. For example, your average across the last 6 months is "15" and the average of everyone else is "25", can you help me see whether you are being given too much off-target work or are there any other issues that are blocking you getting stuff done?
That's why there are so many stupid ideas floating around.
Those are horrible incentives.
Sounds like the name of a new CPU/GPU.
there's strong correlation when onboarding an engineer between the time to first/tenth/fiftieith PR and their PR throughput two years later, so the answer is make it really easy to do PRs when onboarding, and they saw the same outcome even if those initial PRs were trivial
through DORA/SPACE/DevEx they also found that asking your engineers if they feel productive is generally as useful and reliable than trying to measure every possible dimension - which is why DX is based largely around the survey with subjective responses. if you actually use those responses to address friction and frustration, from my experience you end up with more, better, easier work getting done
it's possible to work in a team that cares about measuring their effectiveness, and using those measurements to understand how to be more effective. most/all engineers will have an idea of how they could improve their work, but the reality when you actually spend time to measure often shows a lot of different things you might not have been aware of
When it is decided that a management resource such as a line manager, director, or even C-level exec are causing detriment to organizations they can be put on performance improvement plans —which involves developers simply ignoring anything and everything that person says until they stop speaking nonsense.
This is the way.
I think that’s a good thing, and I say that as an engineering manager.
Having been an IC, I’m acutely aware that developers, when aware of monitoring via performance metrics, will game that system.