We built this to:
1. quickly test all the sources we create, and
2. to make it simple for our users to send data to our SaaS product for sources behind firewalls
Reading the comments here, I see 2 things most of us seem to agree on:
1. team metrics are more useful than individual metrics; that makes sense because a team is an expression of a shared context while people come and go, so team metrics are inherently more valuable to the company in the long term
2. PR cycle time and some version of lead time (time to reach production) are often cited as 2 important metrics; also makes sense because those are the main critical, serial steps in software delivery
Now, I would contend that the rest of the productivity metrics depend on what the team and its parent structures are trying to achieve, and should be DIFFERENT over teams and over time. Maybe a team with a spaghetti-like legacy project will want to track LOC or cyclomatic complexity for a while. Maybe some other team will want to track the amount of transitive dependencies. Maybe some will want to optimize for onboarding (time-to-10th-PR or something like this). 1 size will not fit all, and the team and its management must work to figure out what success looks like w.r.t productivity based on the context at hand.
