On one hand, you want to (in my world) empower developers and let them take ownership of ... whatever. On the other hand, you want to learn, as a group how to do better. On the gripping hand, you want to be able to tell the customers (and investors) what to expect and when.
It seems as if you can do the combination of #1 & #3, somehow, without tracking what you are doing and how you are doing it, but that #2 requires us to baseline what we are doing and try to brainstorm about what we can try in an attempt to, as a functional group, do better.
In your world, measurement is "bad" for an individual's autonomy. And it may well be. How does an organization accomplish goal #2 (and #3) along with #1?
Anecdotally, I found that the self-directed process improvement (PSP - https://en.wikipedia.org/wiki/Personal_software_process) helped a great deal. I didn't go overboard with formalism, just jotted myself some notes along the way during the week that I spent 20 minutes compiling on Friday, but I found that I had to record what I was doing to even know what I was doing. And that's just me. Maybe I'm an idiot, but I really didn't know. And my own estimates of what I was doing were ... surprisingly off.
> In your world, measurement is "bad" for an individual's autonomy.
It isn't actually the measurement itself. It's when the metrics end up tied to rewards and penalties that people start to game them. [1]
What you could do is measure things and then, when unit 15 is above average and unit 9 is below average, figure out why and let everybody know what works and what doesn't.
Which also has the side benefit of improving your metrics. Because if you see that unit 15 has the best numbers and you treat this as an undifferentiated "unit 15 is better and we don't know why but let's reward them" metric, you can miss things like, unit 15's district has a higher population density and they're actually below average after you take that into account.
Investigating the sources of success and failure without assigning personal consequences to them allows people to be honest about why they succeeded or failed. And then if anybody has actually found the secret to success you can share it with everyone else.
[1] Although you do have to be careful not to make "collecting metrics" a thing that eats half of each employee's work time.
You aren't alone in your realization. I did the PSP for a while and found the same.
We are about one month into a three-month experiment where we are asking people to track time on their activities (mix of IT and developers). For some, it is a struggle with all the complaints when you try to make a small group "corporate". For others, they are having huge revelations of where their time is going that (I think) has been valuable.
What I've been trying to communicate is that the time tracking data has nothing to do with the individual, and is not being used as a measure of performance (it really isn't, and it isn't on anyones performance plans). What it IS being used for is a way for us to communicate with senior leadership to better demonstrate our value to the organization (in terms they are more familiar with). Basically, the "IT needs to better speak to the business" conversation that's been going on for ~15 years or so now. I suppose you could also tie it into the topic of when a startup grows beyond x people, with x in the range of 30-50 people.
On one hand, you want to (in my world) empower developers and let them take ownership of ... whatever. On the other hand, you want to learn, as a group how to do better. On the gripping hand, you want to be able to tell the customers (and investors) what to expect and when.
It seems as if you can do the combination of #1 & #3, somehow, without tracking what you are doing and how you are doing it, but that #2 requires us to baseline what we are doing and try to brainstorm about what we can try in an attempt to, as a functional group, do better.
In your world, measurement is "bad" for an individual's autonomy. And it may well be. How does an organization accomplish goal #2 (and #3) along with #1?
Anecdotally, I found that the self-directed process improvement (PSP - https://en.wikipedia.org/wiki/Personal_software_process) helped a great deal. I didn't go overboard with formalism, just jotted myself some notes along the way during the week that I spent 20 minutes compiling on Friday, but I found that I had to record what I was doing to even know what I was doing. And that's just me. Maybe I'm an idiot, but I really didn't know. And my own estimates of what I was doing were ... surprisingly off.