Well, productivity measures how fast you deliver new value. Fixing a bug is about repairing value that you thought you had delivered but actually did not. Counting bugs as "value" would be double counting.
Interesting to note that two of your decision points are on "shipping product improvements at a regular cadence" or "shipping so slow that it's negatively impacting customers". Both relate to a productivity discussion, ie "how to define what it means to 'ship' as an engineering team". In that sense, we're aligned on why it's important to measure productivity.
It would however be a mistake to try to optimize for maximum productivity in a vacuum, but note that this is not what this thread is about. This thread is about the unit of measurement that people use in their teams. In that sense it's purely a research / curiosity question
I agree 100%, you need to have a strong product foundation to turn good output into good business outcome. A productive team that delivers features no one wants is pointless. Both go hand in hand, but as far as engineering management goes, it is still a challenge to find a good productivity metric. What’s used in your organization @przeor and what do you think of it?
Your comment got me curious, so I've just asked one of the best developers at Google. If you want to tag along and make some noise: https://twitter.com/FlavianHautbois/status/15972300521436733... (he has not replied yet)
[FYI, I sent this comment to another thread as well]
Don't get me wrong, pairing has merits. Let me give you an example. I'm in the middle of going through type challenges in Typescript (https://github.com/type-challenges/type-challenges). If I knew absolutely nothing about types, pair-programming would have helped me get started. But some of these challenges teach me important insights about the Typescript typing system that take time to wrap my head around. You don't get this amount of system 2 focus when pair programming because pair programming is (to a large amount) communication.
1. Yes, that's the point. 10x doesn't say "compared to what", but hints at "compared to now"
2. For sure. My 3 former companies let people spike while working, and I've seen mediocre engineers (lots of bugs, rework) become ok (barely any rework, a few bugs from time to time)
You're right in a way, but you're missing the "10x compared to what?". Consider the 1x baseline as being the median productivity of your development team (which is definitely hard to approximate, but for the sake of the exercise let's take 'value-added tickets per developer' [which excludes bugs/rework]). Then the goal is to do 10x on this median in a reasonable amount of time. Rince and repeat.
I assume some of the skills you're trained on are technical too. Your organization sounds like it does a lot to develop engineers, do you think it's paying off regarding competition or other tech companies?