Wonderful! You have such a talent for cutting to the heart of the issue. Productivity is dollars in divided by dollars out -- full stop. Every group at the company has a right to a peice of that metric, they all contribute their part. Any other productivity metric is likely to be a poor proxy for that, and suspectable to abuse.
The only measures where I work are at a business level and company-wide: new member registrations, revenue (initial and repeat purchase), number of support tickets raised by members, etc. There's a clear sense that we're all responsible for the success (or failure!) of the company and that we all work together across all departments toward that success.
I think much of the productivity issues stem from the languages, frameworks/libs, tools patterns and processes of full stack NOT being designed HUMAN first. and a general lack of understanding of distributed async architectures, web security and discovery standards, and just in time fractional composition of client/device/web/cloud code. backend and frontend developer knowledge and practices are lagging far behind infrastructure capabilities in browser architecture and capabilities. and in the backend container systems like k8 are poorly designed for federated system and cluster lifecycle given end to end capabilities of modern web standards. (I.e., config and analytics observability mess - with no financial incentives to re-architect given the $$$ billions in play). The EdgeCloud is where change and disruption will happen in the next few years. Fueled by cost, privacy, security.. And that left shift will change developer productivity.
Realistically, how do you measure an individual software developer performance? Reality is that there are people underperforming, being consistently slow, dragging the entire team down.
As an example, a mid engineer, a few years in the role and with the business, consistently delivering less cards than their team average over a large period of time. No other significant contributions to outcomes, such as brilliant ideas, mentoring others.
I believe productivity and speed metrics have a time and place in performance conversations, definitely with the right context and understanding the full picture in which an individual might add value to the team
The first time you deliver negative consequences based on numbers is the last time you get honest numbers. So the next time you deliver negative consequences based on numbers it’s based on numbers that have been gamed . What’s that gonna do for your team’s productivity?
Well said, thank you. I agree on the productivity front though I still think that metrics have their place. Not in the sense of "We need to identify the low performers by this metric and cut them" but rather in the sense of "what are the canaries in the coal mine that help identify issues before they blow up".
I know a couple things to be absolutely true:
1. Developers are most productive when they getting shit done
2. How you feel at the end of a day is usually a good indicator of how productive the day was.
I've had days when I didn't get any coding done but had good, deep meetings that resolved thorny problems and got us set up for success and felt great about them. I've had days when I got a bunch of little tickets done and out the door but it felt like a waste because I knew there were much more important things I could and should be doing.
Fundamentally, I think we need to optimize for flow. How do we get the right people the right context and the right tools and support to work on the right problems and feel like they understand why it is important and that their hard work, growth, and intelligence is seen and celebrated?
The closer you get to that state of flow and make it feel sustainable, the closer you are to optimal productivity.
I realize that management's fury toward software developers results from developers knowing something the manager may never/will never know. Treating them as work centers in manufacturing is their "Procrustean Bed," whereby they force developers to fit into their perfidious interpretation of their belief (or more correctly, their desire) of what software developers do.
Management creates a jig, built of processes and frameworks ordained by other managers (going back to Winslow Taylor), and then chop or stretch the development exercise to fit it. Just like when Procrustes chopped or stretched, the victim dies from the abuse.
What is "value delivery?" Yes, I've heard of the phrase, but nobody can tell me what it means. "Deliver value, not tasks." Don't we do that by delivering tasks? So I get confused.
I don't have a buzzword for it. I call it automating a solution to a problem. As developers, we're rarely allowed to question the problem, or even the definition of the solution. We're simply told to automate this pre-defined solution. That makes us order-takers. I think we're more.
Software developers happen to possess the greatest store of domain knowledge and passion in the organization. Of course we must know our "tech," but even more, we must know the domain of both tech and of the business. By the time we get the call, though, we're reduced to coders. Does this cause the disconnect?
The most effective large teams have small groups that are all focused on their own unique priorities. Offense focuses on Offense. Defense focuses on Defense. They all bring their unique talents together to perform as a (hopefully) winning team. Same thing should happen with engineering. If the team is only focused on delivering value, who is focusing on quality engineering?
I'm all for economies of scale & people doing what resonates with them. Take build pipelines for an example, though. A programmer should be able to tune their own build pipeline. When they do, though, they have to realize they have a larger responsibility than just themselves. They are doing work that affects many others.
Totally agree. Software engineer's work is happening inside their brains, it's not Ford assembly line. The only way I see to get reliable metrics is to hook a bunch of wires to said brain)
I LOVE this! I'm on a fractional CTO mailing list and every so often the question comes through about developer productivity but it always stops at the developers.
Thank you for pointing out that there is a whole stack of folks that need to cooperate in order to make $1 invested into more that $1 return for your business.
Wonderful! You have such a talent for cutting to the heart of the issue. Productivity is dollars in divided by dollars out -- full stop. Every group at the company has a right to a peice of that metric, they all contribute their part. Any other productivity metric is likely to be a poor proxy for that, and suspectable to abuse.
The book Drive by Dan Punk really highlights how important intrinsic motivation is for developers.
Programming is generally a creative art 🎨
It's better rewarded using autonomy, mastery and purpose.
Daniel Pink, but I really hope he gets called Dan Punk sometimes! :)
And, yes, fabulous book and great recommendation.
In software “more is not always more”. At some point “less becomes more “. This complicates output productivity measurement as you well articulate.
Inputs, otoh, are not elastic/distortable. Understanding how inputs can be allocated reveals room for improvement and progress.
The only measures where I work are at a business level and company-wide: new member registrations, revenue (initial and repeat purchase), number of support tickets raised by members, etc. There's a clear sense that we're all responsible for the success (or failure!) of the company and that we all work together across all departments toward that success.
I think much of the productivity issues stem from the languages, frameworks/libs, tools patterns and processes of full stack NOT being designed HUMAN first. and a general lack of understanding of distributed async architectures, web security and discovery standards, and just in time fractional composition of client/device/web/cloud code. backend and frontend developer knowledge and practices are lagging far behind infrastructure capabilities in browser architecture and capabilities. and in the backend container systems like k8 are poorly designed for federated system and cluster lifecycle given end to end capabilities of modern web standards. (I.e., config and analytics observability mess - with no financial incentives to re-architect given the $$$ billions in play). The EdgeCloud is where change and disruption will happen in the next few years. Fueled by cost, privacy, security.. And that left shift will change developer productivity.
For years my biz coach kept telling me I needed to use metrics so I could track developer productivity. He never understood.
Realistically, how do you measure an individual software developer performance? Reality is that there are people underperforming, being consistently slow, dragging the entire team down.
As an example, a mid engineer, a few years in the role and with the business, consistently delivering less cards than their team average over a large period of time. No other significant contributions to outcomes, such as brilliant ideas, mentoring others.
I believe productivity and speed metrics have a time and place in performance conversations, definitely with the right context and understanding the full picture in which an individual might add value to the team
The first time you deliver negative consequences based on numbers is the last time you get honest numbers. So the next time you deliver negative consequences based on numbers it’s based on numbers that have been gamed . What’s that gonna do for your team’s productivity?
Well said, thank you. I agree on the productivity front though I still think that metrics have their place. Not in the sense of "We need to identify the low performers by this metric and cut them" but rather in the sense of "what are the canaries in the coal mine that help identify issues before they blow up".
I know a couple things to be absolutely true:
1. Developers are most productive when they getting shit done
2. How you feel at the end of a day is usually a good indicator of how productive the day was.
I've had days when I didn't get any coding done but had good, deep meetings that resolved thorny problems and got us set up for success and felt great about them. I've had days when I got a bunch of little tickets done and out the door but it felt like a waste because I knew there were much more important things I could and should be doing.
Fundamentally, I think we need to optimize for flow. How do we get the right people the right context and the right tools and support to work on the right problems and feel like they understand why it is important and that their hard work, growth, and intelligence is seen and celebrated?
The closer you get to that state of flow and make it feel sustainable, the closer you are to optimal productivity.
I realize that management's fury toward software developers results from developers knowing something the manager may never/will never know. Treating them as work centers in manufacturing is their "Procrustean Bed," whereby they force developers to fit into their perfidious interpretation of their belief (or more correctly, their desire) of what software developers do.
Management creates a jig, built of processes and frameworks ordained by other managers (going back to Winslow Taylor), and then chop or stretch the development exercise to fit it. Just like when Procrustes chopped or stretched, the victim dies from the abuse.
In brief, you get offal, not software.
I don't see how this is a helpful framing. Developers have done plenty to deserve not to be trusted--prima donna behavior, lying, corner cutting.
We have a dysfunctional relationship, with responsibility on both sides. We both have to change to create a more functional relationship.
My apologies. Sometimes I don't feel like compromise, even if I should.
Agreed…
I’m curious if everyone being focused on value delivery would help?
My belief is that any code/tech is a means to that end. I know many developers who focus more on the tech itself.
Is that focus on tech, which management may not see as valuable, one of the things that causes that disconnect?
What is "value delivery?" Yes, I've heard of the phrase, but nobody can tell me what it means. "Deliver value, not tasks." Don't we do that by delivering tasks? So I get confused.
I don't have a buzzword for it. I call it automating a solution to a problem. As developers, we're rarely allowed to question the problem, or even the definition of the solution. We're simply told to automate this pre-defined solution. That makes us order-takers. I think we're more.
Software developers happen to possess the greatest store of domain knowledge and passion in the organization. Of course we must know our "tech," but even more, we must know the domain of both tech and of the business. By the time we get the call, though, we're reduced to coders. Does this cause the disconnect?
You bet it does.
The most effective large teams have small groups that are all focused on their own unique priorities. Offense focuses on Offense. Defense focuses on Defense. They all bring their unique talents together to perform as a (hopefully) winning team. Same thing should happen with engineering. If the team is only focused on delivering value, who is focusing on quality engineering?
I'm all for economies of scale & people doing what resonates with them. Take build pipelines for an example, though. A programmer should be able to tune their own build pipeline. When they do, though, they have to realize they have a larger responsibility than just themselves. They are doing work that affects many others.
Totally agree. Software engineer's work is happening inside their brains, it's not Ford assembly line. The only way I see to get reliable metrics is to hook a bunch of wires to said brain)
You and John Cutler are on a similar wavelength this week: https://cutlefish.substack.com/p/tbm-305-stop-the-goal-cascade-madness
I LOVE this! I'm on a fractional CTO mailing list and every so often the question comes through about developer productivity but it always stops at the developers.
Thank you for pointing out that there is a whole stack of folks that need to cooperate in order to make $1 invested into more that $1 return for your business.