the hardest problem in engineering delivery metrics, is convincing engineers that measuring the team is helpful and not going to be held against them individually.

any semblance of "data driven" goes completely out the window once it's about measuring the team, and not computers

i get it, we naturally mistrust managers and past exercises like stack ranking and other terrible ideas like measuring lines of code have ruined trust.

but, this is just another example of how software isn't just about systems of computers.

this is also my biggest concern in regards to some of the companies that are over-indexing on individual metrics and not collective ones.

the research is about groups, not individuals. and delivering software is a collective excercise

one of the tools I used had this weird "hours coded" metric. and it totally ignored the time spent designing systems, or making decisions.

as an industry we value the time spent programming way to much and have to let go of the idea that to build software programmers are best left alone, with no meetings.

writing open source software and building technology companies/businesses are two very different processes, and when we tangle expectations we really hurt the progress we can make together