this post was submitted on 04 Nov 2023
33 points (80.0% liked)
Technology
58137 readers
5630 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
My experience has been management is too stupid to properly employ metrics. If you let them pick, they pick the easiest ones. If they don't get a choice, they just try to cheese the numbers to the detriment of the company. If you present options that make sense, they don't understand them.
Maybe I've just worked for dumb companies, but they sucked hard with respect to metrics.
As an engineering manager who's tasked with manually gathering a whole lot of metrics in the hopes that something jumps out that can then be improved, what would you say are the metrics that make the most sense?
As a former coder, I would say PR size (the smaller the better), automated test coverage, number of prod bugs, toil level (unplanned work, dealing with tools and environment issues) but also things like knowledge of the code base, level of collaboration, ownership of the process, org-wide collaboration and learning... Much of which is hard to measure but can be set as goals regardless.
Apologies if I misled you a bit. My experience is in manufacturing, not coding. My advice would be to identify issues in terms of cost. That's what the company truly cares about. Talk to your people and find out what their biggest pain points are. Then order those issues in terms of effort to rectify vs return on investment. Problems that are low effort but high return get prioritized. Then just whittle the list down.
This takes a broader approach to metrics. But as I mentioned, metrics can be cheesed. It's hard to cheese overall cost. If you prioritized number of bugs, I'd assume the time would go up. If you prioritized time, I'd assume bugs would go up. Prioritizing either doesn't really solve the problem. You want the root cause of those bugs. Are certain bugs more prevalent (can bugs be categorized even?). Then work those down.
I'd be more then willing to flesh out some more details if you'd like. I genuinely love that kind of stuff. Unfortunately I don't have coding specific experience.