minware reposted this
Reviews that “don’t use data” really just rely on the manager’s memory, which is often biased. Quantitative metrics are essential for writing a fair engineering performance review with the greatest impact on career growth. Previous abuses like stack ranking engineers by lines of code have unfortunately created a stigma against metrics in performance assessments. Metrics should assist and enrich a manager’s understanding, **not replace or supersede their judgement.** This article looks at several metrics I’ve used to better recognize contributions, assess the pace of work, and evaluate work quality for engineers on my team. If you want to attract and develop the best talent, you need to know what the numbers say and where they disagree with your intuition.
Sounds like an open challenge to hack your metrics without delivering real work. Are you sure you want to turn your entire engineering team into adversaries fighting a system they can outsmart? Or maybe it’s better to give them real business challenges where they can create actual value and grow?
Nick Lusk
1mo
Performance reviews have nothing to do with reviewing performance. They're always about something else if they last more than two minutes.
Nicholas Smith
2mo
If you're ranking engineers by lines of code, I would win. I haven't written a line of code in hours.
Kevin Borders, balancing qualitative insights with quantitative metrics is crucial. this will improve both evaluations and growth opportunities! 📊 #performancereview
Chris Morrison
2mo
I enjoyed the section of your blog post about recognizing contributions. Lots of engineers contribute in less-visible ways and I think systems that track and therefore incentivize those contributions are likely to be a good thing.
Autumn Patterson
1mo
correct- was just musing on this with my so
.NET full-stack developer | ETL | Kimball Data Warehousing Passionate and determined software developer. Not Dan Aykroyd, the Canadian autistic actor.
1moI'm trying to understand your relationship to observability as part of the development process, since that seems like the unspoken prerequisite for the generalities or specifics of engineering metrics. I would prefer to have metrics be part of my evaluation, but I have trouble imagining them being applied in practice within my team - so I'm left to craft narratives when I'd rather my work speak for itself. Do you have any thoughts on how to promote greater "measurability" of work?