Hacker News Reader

Comment by bigiain | Hacker News Reader

> Employee metrics are useful for a big picture view.

Which "employee metrics" do you find useful for that?

Because in my experience, it's pretty much guaranteed to be someone who isn't anywhere near leading on the type of metrics these discussions are talking about - that's making the biggest impact and amplifies _team_ productivity. Those people don't close a dozen Jira tickets before lunch, they are the people who spend two weeks actually finding and fixing the root cause of that one annoying ticket that 15 other people have closed only to find the problem re occurs. They aren't top of the leaderboard in git commits, because they actually read the RFCs or dependancy source code while working. They sure as hell don't always write the most LOC in a week - I want the "minus 2000 lines of code" guy, not the one who's best at gaming whatever metrics you use.

https://www.folklore.org/Negative_2000_Lines_Of_Code.html

View on HN

I don't even look at the metrics for ICs. If a team has an underperformer I expect the lead to be handling that, with my support if necessary.

The metrics I find useful are things like trends before and after a change. For example, if lots of PRs are taking a long time to get through review because the descriptions don't get filled in well, I want to look at the time code spends in review before and after updating the PR template. Or before that, I want to see which teams have code in review for less time so I can look at their PR process and suggest changes to slower teams that the faster teams have already implemented. If a team is doing the same stuff as other teams but their typical PR size is much bigger I want to know if they have fewer stories that they should be breaking down further. And so on.

None of this is data I don't have a gut feel for, but having real numbers is useful for making a case for change. People don't always believe instinct. It's harder to argue with a well-designed graph.

It is also super hard to look at trend of "gut feeling" or "instinct".

Seems like lots of people discuss here false dichotomy and I really like onion2k explanation because it is much more nuanced and basically explains the same thing I was trying to convey in other thread on similar topic.

How do you collect & display these metrics, manually, internal tools, or a product?

I'm often asked to provide employee metrics but my product is just an automated time tracker for contractors & devs, who bill by time. I've avoided it being used as employee metrics, but we recently built a separate product for these trends and team insights that you're using.

May I email you to the address listed in your HN profile? Just for an informal chat.

You can reach me at alan@wakatime.com.

I use Jellyfish. Happy to have a chat. Fire me an email. :)

I feel very seen.

I’m at my happiest when being grease or glue; when I unstick the stuck, or stick the unstuck. I like to “walk the property”. Find the bugs that are under rocks.

I’m not at my best as a mere construction drone piling on work for work’s sake. That’s soul-killing, for my soul, at least.

hello my fellow troubleshooter:-D

> it's pretty much guaranteed to be someone who isn't anywhere near leading on the type of metrics these discussions are talking about - that's making the biggest impact and amplifies _team_ productivity

It would be great if everyone on the team had different strengths that contributed to team productivity "A smashes out small features like nobody's business", "B is great at debugging", "C is great at planning and seeing through big long-term features", "D is great at helping teammates" etc.

However in practice I find you have a minority of team members who can do _all_ of A, B, C, and D's tasks well, and a mediocre majority who deliver between 20% and -10% the productivity of the talented minority.

> They aren't top of the leaderboard in git commits, because they actually read the RFCs or dependancy source code while working. They sure as hell don't always write the most LOC in a week - I want the "minus 2000 lines of code" guy

Yes, these engineers are invaluable. But the "minus 2000 LOC" engineer is rare.

In my ~25 years of experience at several top companies, I've seen that --more often than not-- the most impactful coders are writing the most LOC. And they're not gaming it either. They are simply writing a ton of high-quality code: features, bug fixes, optimizations, cleanups, etc. Yes, occasionally there is a crazy heisenbug that takes 3 weeks for a one-line change, but that is rare.

Note that I deliberately use the word "coder" (which I don't usually do) instead of the more generic "engineer." Because I'm not talking about those critical senior engineers whose job is mostly to prevent others from writing bad code.

Agreed. At the end of the day - the end user of the software probably wants something other than technical debt reduction, so it's not surprising impact and LOC can roughly be correlated.

Taking the LOC metric too far, in either direction, is trying to read too much into a single metric.

Reply on news.ycombinator.com