Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Designing an Engineering Performance Management System from Scratch

blog.gitprime.com

Post reply on HN
Print view View original

21–30 of 70 posts

Re: Designing an Engineering Performance Management System from Scratch

#21

Post by megous »

emtel wrote: post #13

Formal performance reviews are the worst method for evaluating your workforce that has ever been tried, except for all the others. For me, performance reviews are the single most demoralizing aspect of working at a large company. They are doubly demoralizing because I can see so many things wrong with them, but also can't imagine any system that would work better. So what's wrong with them? 1. Over the long term, the…

I haven't worked for a corp yet, but wouldn't another problem be that you're a team/system, but perf. review is focussed on the individual, and assumes that's where the problems or the success of the team arises from? So it's a bit reductionist.

Re: Designing an Engineering Performance Management System from Scratch

#22

Post by kelnos »

Cookingboy wrote: post #15
johnrob wrote: post #12

Fundamentally, are performance systems done objectively or "on a curve"? Meaning, if 100% of the engineers are operating at say Staff Engineer level, do they all end up with that title? Or does the Staff Engineer title really come down to some sort of percentile in a stack ranking?

>if 100% of the engineers are operating at say Staff Engineer level Then you need to re-evaluate your definition of "Staff Engineer" at your company. Those titles are all relatively defined internally in the first place, just like junior/senior/staff/senior staff. There is no industry-wide benchmark for those levels, so an internal curve is the only system that makes sense. In the imaginary case where everyone in the…

If everyone actually is operating at a high level -- or at least enough to make a curve difficult -- keeping people under-titled is just a great way to allow your high performers to become discouraged and leave the company.

Re: Designing an Engineering Performance Management System from Scratch

#23

Post by supergeek133 »

There are two aspects to any system like this: 1) The "carrot" - goals you set to rate yourself on to (in theory) get a raise at the end of the year. Or qualify for a promotion.

2) Career feedback.

Now I've found for both of these if any review with your manager take longer than 10-20 minutes, something is amiss. This usually means you don't see eye to eye on either the state of your goals, or your performance.

That being said, without the carrot, I think most people wouldn't execute these at all.

Re: Designing an Engineering Performance Management System from Scratch

#24

Post by timdellinger »

I think I missed the author's design goals for a performance management system: what it's supposed to accomplish.

Performance management systems have a natural tendency to degenerate into sources of toxic behavior... one of the most important design goals would be to avoid this, and one of the most instructive parts of a "how to" would be strategies in that vein.

As an aside: I've noticed that people who run performance management systems are under the impression that their system does a good job. After all, it chose them, didn't it?

Re: Designing an Engineering Performance Management System from Scratch

#27

Post by vonmoltke »

Cookingboy wrote: post #15
johnrob wrote: post #12

Fundamentally, are performance systems done objectively or "on a curve"? Meaning, if 100% of the engineers are operating at say Staff Engineer level, do they all end up with that title? Or does the Staff Engineer title really come down to some sort of percentile in a stack ranking?

>if 100% of the engineers are operating at say Staff Engineer level Then you need to re-evaluate your definition of "Staff Engineer" at your company. Those titles are all relatively defined internally in the first place, just like junior/senior/staff/senior staff. There is no industry-wide benchmark for those levels, so an internal curve is the only system that makes sense. In the imaginary case where everyone in the…

> But obviously that scenario won't last long as the company grows, and that's why titles/levels are gradually introduced.

For better or worse, Bloomberg does not have this. There are no formal levels or titles for ICs, despite having thousands of them. I thought it worked fairly well there.

Re: Designing an Engineering Performance Management System from Scratch

#29

Post by shadester88 »

I find the obsession with performance reviews interesting. I manage teams of developers in a large organisation, and I have been doing so for many years now.

I hate performance reviews. I think they do not achieve what people think they do, they take up a lot of time and effort to decide and perform, and they often have quite a negative effect on the staff member.

I think performance reviews and KPIs for individuals just need to go. Get rid of them. If someone isn't performing, you can manage that without a KPI system. If someone is performing well, you can provide that feedback without a KPI system. We need to start having meaningful conversations, not scoring people.

People, like in this article, seem to double down on them and make them more complex and intricate in an effort to make them effective. They are going in the wrong direction. Just get rid of them altogether.

Re: Designing an Engineering Performance Management System from Scratch

#30

Post by donavanm »

deegles wrote: post #11

"When a measure becomes a target, it ceases to be a good measure." In this case, the measure is your position on the career ladder, not e.g. the success/failure of your product or company as a whole (unless that is required to advance). I feel that because of this, performance management at big companies leads to unnecessary product churn. Think about how many messaging apps Google has released, or how every product…

The phrase at my current work place is Promtion Oriented Architecture. Ive seen three general approaches, that I like.

First the role descriptions & leveling guidelines have deemphasized complexity. Words like complex, large, feature, or new have been reduced or replaced where possible.

Second there an emphasis on (business) value delivered. Fixing a broken system can provide as much or more long term value than building an additional or replacement system. Building a baroque ivory tower is actually a negative. This also ties back to point one.

Third all senior role promotions include target level peer review, alongside the manager/candidate “promo doc.” The candidates potential peers perform an assessment of the body of work, leadership contributions, and results delivered. This is not limited to the most recent delivery/project/team. There are typically two assessors; one organizationally “near” the candidate and one “far.” For senior staff/principal/distinguished engineer positions theres also a mandatory peer review board.

Post reply on HN