Comment by onion2k | Hacker News Reader

Comment by onion2k | Hacker News Reader

It's the job of a manager to know what their reports are up to, and whether they're doing a good job of it, and are generally effective.

That's true, but it's not what employee metrics tools tell you. If you're using metrics tools to measure productivity then you're not really being a good manager. Metrics tell you are the quantitative details (eg a count of how much output there is), but as a manager what you actually care about in your day to day work is the qualitative details (eg how good the output is), how happy the team is, where the conflict is, etc. Metrics won't tell you that.

But...

Being a manager is about more than just getting people to do their job well. You also need to plan things, you need to know what's changing over time, you need to test whether your processes are working. I use metrics to measure the aggregate impact of my influence on managing my teams, not that of any IC on any of my teams. Employee metrics are useful for a big picture view.

> 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

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.

> Being a manager is about more than just getting people to do their job well. You also need to plan things, you need to know what's changing over time, you need to test whether your processes are working. I use metrics to measure the aggregate impact of my influence on managing my teams, not that of any IC on any of my teams. Employee metrics are useful for a big picture view.

The point of the article is exactly that such metrics don't give you any kind of a good signal unless you are really into the fine details. And if you are, then you don't really need them in the first place.

> quantitative details (eg a count of how much output there is)

For example I recently spent a week producing several thousands of lines of tedious trivial code that parses some configuration out of JSON file in pure C. Then I spent a month writing less 1k lines of very dense low-level packet parsing code and the main loop also in C. So the metrics would show you the big picture of me slacking and my performance tanking which obviously wasn't the case. You can't substitute actually knowing and understanding of what your reports are doing with some tools providing you with trivia like number of commits, lines of code changed or tickets closed.

Being a good manager is taking in all the metrics (+other information), assigning the appropriate weights to them and making informed determinations.

If the worker changing your code style from snake case to camel case does 500 commits in a day they are not a 100x programmer vs the worker solving world peace who did 5 commits. If their commits drop to 1 a day then maybe reach out and see how things are going, solving world peace has a lot of dead ends and bottlenecks.

Reply on news.ycombinator.com