5 ms·
My company uses quarterly reviews. Here are the metrics my company uses to review each developer: 1. We have an in-house developed tool that tracks git and mer
by rootlocus 9y ago
My company uses quarterly reviews. Here are the metrics my company uses to review each developer:
1. We have an in-house developed tool that tracks git and mercurial commits and calculates the test coverage and code quality for each individual developer.
2. We use jira to track the number of points each developer burns (points are shared between developer, reviewer and QA). We also track the number of bugs each developer introduces because closing a bugfix is not possible without first assigning the developer who introduced the bug to the jira task.
3. We use peer reviews where each team member rates each other team member on a scale from 1 to 5 (3 being considered sufficient) on aspects like availability, communication, reliability and result orientation.
4. Team leaders offer subjective input on each team member.
Of course, many of the metrics will be skewed or won't reflect the reality, which is why the team lead has the right to make adjustments to the final mark.
This being said, one of my colleagues and friend was "forced" to quit the company because he scored really low on the jira burn rate metric. He was given a tremendously huge task which nobody cared to properly estimate and break into smaller tasks. As a result he spent 6 monts working on the equivalent of 2 weeks of estimation points. The management (including the team lead which is otherwise a great leader and an awesome person) didn't want to assume any blame for this.
- kkanojia 9y ago"one of my colleagues and friend was "forced" to quit the company because he scored really low on the jira burn rate metric" This sounds totally insane. I Cannot believe this happens in real world.
- humanrebar 9y agoIt sounds like justification for a decision made for less quantitative reasons. Managers don't say, "So let's see who's the worst performer... it's Tom! Weird, he seems to be one of my best developers. Oh, well! The metrics say he's the worst. Off to fire Tom!"
- msingle 9y agoNot in general, but I'm sure there are some that might.
- baldfat 9y agoYou don't know many people who worked for Microsoft? They would let go the bottom 10% of their staff every year. "Best to Worst Ranking" is the most toxic and destructive environments. Manu Cornet famous organization chart is the best example of this. https://upload.wikimedia.org/wikipedia/commons/e/e1/%22Org_charts%22_comic_by_Manu_Cornet.png https://upload.wikimedia.org/wikipedia/commons/e/e1/%22Org_c...
- humanrebar 9y agoI was under the impression that those rankings were created through a series of let's-sort-everyone meetings rather a pedantic application of metrics.
- softawre 9y agoYes they are, you are right. My company does them too, somewhat. If you have to let go 20% of your staff, how do you do it? You have to rank people...
- cema 9y agoIt sounds like justification for a decision made for less quantitative reasons. Yes. And the perception of objectivity from the first two points (of the parental article) helps in hiding this.
- pjc50 9y ago"[manager] didn't want to assume any blame for this" This happens depressingly often. "6 monts working on the equivalent of 2 weeks of estimation points" It's really the fault of the manager for not changing something after the first 3 weeks of this.
- throwaway413 9y agoThis exact thing has happened to me before - you have to be strong enough to stand up for yourself and communicate the real problem or else, yeah, no one will want to take responsibility and it ALWAYS falls back on the dev team. Sometimes it's tough to be that ass and say "hey, these weren't estimated properly PM!"...but if it's your job or theirs...
- beejiu 9y ago"successfully escaped" is probably more accurate than "forced to quit"
- sidlls 9y agoIt does. I've worked at two places that implemented the first two items in one degree or another. One place my manager assigned me a project to automate the commit counter for each developer and wanted to implement a standard template for the commit message developers would be required to use and that could be used to identify the particular feature or project so that commits / dev / project could be measured. Software development in the Bay Area and other tech hubs with similar (or aspiring to be similar) company profiles can be depressing.
- humanrebar 9y agoThat's a fundamental misunderstanding of the purpose and value of story points. I hope that comes up in retrospectives. Aggregating them for an individual developer over a long enough period of time might work, but I wouldn't trust it without some statistical hypothesis testing backing the idea up. But using them to evaluate productivity on a small scale violates the collaborative culture (people over processes) that agile is supposed to foster. I've also seen them misused by: * mapping them explicitly to hours or days * thinking they are estimates of value produced instead of work required * having project managers point and pull in things for developers I'm not sure what an individual contributor can do about that kind of cultural issue. Insisting on using story points properly seems academic or pedantic, but the second- and third-order effects are an expensive-to-maintain product, a decrease in velocity, and probably developer retention problems. But, no, I've never heard of agile mistakes coming up in a performance evaluation or a 180 review for a manager.
- sidlls 9y agoThat sounds like a terrible process. With that kind of process I wouldn't want to work there. It's a great example of how developers are treated as second class grunt workers.
- sytse 9y agoI don't think that is a useful way to measure developer productivity. GitLab offers contribution analytics to get a good overview https://gitlab.com/help/analytics/contribution_analytics.md https://gitlab.com/help/analytics/contribution_analytics.md We find it a useful tool to have a data driven conversation between a manager and a report. But it should not form the basis of the performance review. That is why everyone should report to exactly one manager who understands what they do. The Gitlab performance review process is described on https://about.gitlab.com/handbook/people-operations/performance-reviews/ https://about.gitlab.com/handbook/people-operations/performa... (it is over 100 lines so I won't paste it here).
- godelmachine 9y agoMay I ask the company name?
- JustSomeNobody 9y agoWould like to know also as I would never wish to work there.
- bencoder 9y agoAfter reading points 1 and 2, I thought your post was satire. This sounds awful.
- deleted 9y ago[deleted]
- ck425 9y agoThat last part happened to me at one point. Thankfully me and another colleague it happened to fought against it consistently until it managers stopped using it openly as a metric.
- tboyd47 9y agoIs there an absolute minimum score, below which employees can assume to be under consideration for termination? Or is it purely a comparative measure?
- cube00 9y ago"He was given a tremendously huge task which nobody cared to properly estimate and break into smaller tasks." This is why the person doing the work must be involved in the estimation process, that way they have ownership of the estimate and are personally accountable for it.
- mabbo 9y agoWhy do you still work at this place? Like, this sounds insane to me, especially your friend being fired over management being bad.
- cema 9y ago"This being said" sounds like otherwise the metric works. I wonder how. The first two points do not seem right (measuring code commits! Punishing bugs, tracking the burn rate as the person's measure of progress!) The last two points are subjective, but the objectivity of the first two points is likely misleading. At the same time, because they are perceived as objective, they are likely to lead the overall measurement of progress. So the example you gave in the last paragraph (of people avoiding blame) does not sounds as an exception, more as a consequence of the choice of progress measurement tools and criteria.
- deepaksurti 9y ago>> The management (including the team lead which is otherwise a great leader and an awesome person) didn't want to assume any blame for this. Not assuming any blame is a trait neither of a great leader or an awesome person. But given the hell hole of a review process, I am not surprised the company has most likely imposter great leaders!