> During my early career, I was a big fan of engineering metrics, but nowadays, I prefer to prioritize people's well-being…
These needn’t be mutually exclusive at all.
The Pragmatic engineer/ Kent Beck response does a good job of pulling apart effort and output; which are poor measures of engineering productivity, from outcome and impact which DORA and SPACE bring more attention to.
Great summary, exactly the right depth (and history) needed.
2 things resonated with me: Keep at simple, and use team metrics.
We have a single metric - Done / Promised, on a TEAM level. So people have the incentive to help their friends, and nobody gets the blame if his/her tasks weren't completed.
It seems we are still in the 90s, but by the look at DORA we are doing very good :) (everything in the 'elite' column). Aren't the standard there a bit low?
Anton, regarding DORA I thought the same and I was also happy to be in the Elite group. That being said I prefer to look further to SPACE, DevEx and what will come next!
Thank you Nicola. I absolutely agree that active listening is a key, without it you cannot identify if spike in metrics is outcome of positive or negative experience that developers had (more deployments as a result of a better process or a rapid bug-fixing?)
It seem that all frameworks in the past years help us to identify if engineering as a business function operates in productive matter or not, which is reasonable expectation. At the same time, I think most engineers dislike productivity metrics because they feel that those numbers don't reflect reality and they will be used to compare them with other engineers, and as a result, turn unfair. EM's assure not to do it (business is less interested on this topic), but they also want to be objective while callibrating engineers performance so they will give promotions and right grades to the right people. I don't think DORA or DevEX have answer for that because they focus on group performance. SPACE touched individual performance topic but just briefly. I like where DevEx turns the industry, but I guess it won't help EMs be more objective during callibrations and performance reviews - because DevEX solves different problem, or different level of engineering productivity (as a function, or as a group).
Sorry for the long comment, but if you have any thoughts on this Nicola, let me know.
Trying to measure how much work is being done will never give a good result. It's easy to be busy with meaningless work. If you measure your impact on the busniess, products, customers, then you can shift people from being a cog doing what's asked to caring about the overall business, not just the code.
Thank you Nicola for the great articles, I enjoy reading your work.
I wonder what software you use to produce the drawings in your articles? I've been a happy Excalidraw user, but I've found your drawings very cool so I was compelled to ask. Thanks in advance!
Nice write up. One thing I wondered though:
> During my early career, I was a big fan of engineering metrics, but nowadays, I prefer to prioritize people's well-being…
These needn’t be mutually exclusive at all.
The Pragmatic engineer/ Kent Beck response does a good job of pulling apart effort and output; which are poor measures of engineering productivity, from outcome and impact which DORA and SPACE bring more attention to.
https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity
Great summary, exactly the right depth (and history) needed.
2 things resonated with me: Keep at simple, and use team metrics.
We have a single metric - Done / Promised, on a TEAM level. So people have the incentive to help their friends, and nobody gets the blame if his/her tasks weren't completed.
It seems we are still in the 90s, but by the look at DORA we are doing very good :) (everything in the 'elite' column). Aren't the standard there a bit low?
Anton, regarding DORA I thought the same and I was also happy to be in the Elite group. That being said I prefer to look further to SPACE, DevEx and what will come next!
Thank you Nicola. I absolutely agree that active listening is a key, without it you cannot identify if spike in metrics is outcome of positive or negative experience that developers had (more deployments as a result of a better process or a rapid bug-fixing?)
It seem that all frameworks in the past years help us to identify if engineering as a business function operates in productive matter or not, which is reasonable expectation. At the same time, I think most engineers dislike productivity metrics because they feel that those numbers don't reflect reality and they will be used to compare them with other engineers, and as a result, turn unfair. EM's assure not to do it (business is less interested on this topic), but they also want to be objective while callibrating engineers performance so they will give promotions and right grades to the right people. I don't think DORA or DevEX have answer for that because they focus on group performance. SPACE touched individual performance topic but just briefly. I like where DevEx turns the industry, but I guess it won't help EMs be more objective during callibrations and performance reviews - because DevEX solves different problem, or different level of engineering productivity (as a function, or as a group).
Sorry for the long comment, but if you have any thoughts on this Nicola, let me know.
Trying to measure how much work is being done will never give a good result. It's easy to be busy with meaningless work. If you measure your impact on the busniess, products, customers, then you can shift people from being a cog doing what's asked to caring about the overall business, not just the code.
Thank you Nicola for the great articles, I enjoy reading your work.
I wonder what software you use to produce the drawings in your articles? I've been a happy Excalidraw user, but I've found your drawings very cool so I was compelled to ask. Thanks in advance!