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

61–70 of 70 posts

Re: Designing an Engineering Performance Management System from Scratch

#61

Post by User23 »

babesh wrote: post #51
pbecotte wrote: post #36

Earlier quoted context omitted.

Titles, in my mind, reflect duties and responsibility rather then level. Not everyone can be in charge of the same things and have leadership responsibilities...therefore they cant all be staff engineer. They CAN all be top performers at their responsibility list...

Salary isn't the only thing people covet. Titles and responsibilities are also coveted since they increase future earning potential. When people don't feel that they can get them, they leave.

Neurotypical humans all crave social status. The higher expected future compensation is a nice bonus, but it's the status that draws people to higher titles.

Re: Designing an Engineering Performance Management System from Scratch

#63

Post by wpietri »

geofft wrote: post #58
wpietri wrote: post #54

Earlier quoted context omitted.

> not all the work that needs to be done is senior-level work Personally, I'm very suspicious of this theory. Whenever I've worked with a team that's all pretty senior, we work to automate away the boring stuff.

Is automating away all the boring stuff actually the highest net business value approach you can take? It might be necessary to let people do it to retain senior people and keep their morale up, and I've certainly seen companies be successful by letting good people overengineer things simply because it lets them attract good people and have them around when they're needed, so if that's your strategy, go for it. But y…

You seem to have two arguments here: training people up and short-term economics. The former is irrelevant to your point. Yes, if you have junior people, it's good to find things for them to do that are at their skill level. But that doesn't mean that there's no high-skill way to do the same work.

I don't think the short-term economic perspective really means much in the long term. Sure, if you spend $6x automating something a junior person can do for $5x, then your apparent extra cost is $x. But that's only true if a) the problem never comes up again, and b) no problem particularly like that one comes up again. Given the history of our field, that sounds like a poor bet to me.

Re: Designing an Engineering Performance Management System from Scratch

#64

Post by pdimitar »

With the risk of getting roasted, here are my top three impressions of the article:

(1) The guy is very deep in the management / higher-level business bubble and is extremely disconnected from the day-to-day work that enables his lifestyle. He seeks to optimize things that are mostly managerial / consultant lingo and don't have much connection to things in the real world. That's not 100% true of course but it mostly strikes me as such.

(2) Instead of de-formalizing the process he seeks to find more and more micro ways to measure people. This can probably work long-term, maybe, but many people have tried and failed many times in the past and I think it's arrogant to not take that into account in your supposed solution.

(3) He is not accounting for humans, like at all. I knew programmers that worked quietly for 3 weeks and then showed us all a gem that made us go "wowwwwww". In traditional systems like Scrum and any agile-based nonsense this is severely frowned upon. Truth is however, people are different and as long as you are happy with the average ($result / $month) of somebody then you should leave them the hell alone to find and optimize their own way of being productive.

---

The above is overly simplified and I am well aware there is a lot of nuance. But I didn't want to write a book so I settled for a condensed and partially inaccurate summary.

Re: Designing an Engineering Performance Management System from Scratch

#65

Post by pdimitar »

Renaud wrote: post #46

I liked the idea of Objectives and Key Results (OKR), a system that was started at IBM and brought over by John Doerr to Google and others[1]: short term goals alongside long term goals, set at the company level and the individual level, constant review and adjustment of the short term goals, disconnection of these metrics from employee bonus. The idea is to get to you goals faster and re-evaluate them for relevance…

> The idea is to get to you goals faster and re-evaluate them for relevance as you go along.

I cannot see how this might be true in any situation except when your core product and efforts are always in one particular direction and a very particular area.

Many companies shift focus -- partially or completely -- as they grow, so I cannot see the wins in the quoted approach. You might gain a perfect understanding of an area and how a feedback loop improves productivity there but is that such an universal wisdom that it applies everywhere else you might go in the future?

Re: Designing an Engineering Performance Management System from Scratch

#66

Post by Draiken »

Renaud wrote: post #46

I liked the idea of Objectives and Key Results (OKR), a system that was started at IBM and brought over by John Doerr to Google and others[1]: short term goals alongside long term goals, set at the company level and the individual level, constant review and adjustment of the short term goals, disconnection of these metrics from employee bonus. The idea is to get to you goals faster and re-evaluate them for relevance…

Then people create objectives like:

O - Improve team efficiency

KR - Increase test coverage by X%

KR - Update at least Y outdated dependencies

Which are complete bullshit, easily gamed and don't actually make the company move forward or the team better.

But according to almost any OKR believer, these are great OKRs.

Making KRs measurable a lot of the times corrupts the OKR system. However if they aren't measurable, their value is sometimes questionable. Kind of a paradox.

Perhaps for huge corporations this kind of system is absolutely needed, but I'm experiencing this on a small company and it's honestly tiring and inefficient.

Re: Designing an Engineering Performance Management System from Scratch

#67

Post by tilolebo »

all2 wrote: post #31
shadester88 wrote: post #29

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…

My gut tells me that these metrics are in place because upper management does not trust you to be objective or consistent when it comes to your people. Rather than actually trust your judgement, they give you a checklist and tell you to check the boxes. Along with a lack of trust, there's also the need for a paper trail in some states if it comes down to firing someone who needs firing. Without an appropriate paper t…

That and the fact that upper management also wants a way to compare employee performance ACROSS teams or departments to decide who's a "rising star", who deserves a promotion or a raise (because the raise budget is always limited so they want to pick the most valuable performers).

Hence the "need" for a standardized performance review, which is bullshit anyway because a true equal assessment would mean that all employees are assessed by the same person/group, which never happens.

Re: Designing an Engineering Performance Management System from Scratch

#68

Post by walshemj »

muro wrote: post #56
walshemj wrote: post #37

Earlier quoted context omitted.

No all PMS systems are worse that say giving every one the same pay rise even a lottery would cause less disruption.

Lotteries were tried, they are the worst system possible.

Got any case studies you would care to share with the class

Re: Designing an Engineering Performance Management System from Scratch

#69

Post by snarf21 »

SatvikBeri wrote: post #57
snarf21 wrote: post #19

Earlier quoted context omitted.

I agree with what you are saying but I think performance reviews can be extremely valuable. The issue is that at all big companies they are used for promotions, raises and bonuses. They aren't designed to accurately measure or predict these things. To me, the right kind of review (and done every six months) is something that takes an employee only an hour and the same for the manager. Its only purpose is to set and r…

How do you decide promotions, raises, and bonuses then? I'd think of that as the main purpose of performance reviews.

That's a fair question. I think reviews shouldn't be about performance but rather about employee growth. It is a touch base to make sure everyone is on the same page. It should also direct an employee in their career path. These are discussions that also lead to "Would you like to manage people or remain an individual contributor?" "Okay, to do that you need to improve your skills at X".

As far as bonuses, I think they should just be split regardless of performance. I think raises are tied to promotion but if it is CoL, then people just get it.

As far as promotions go, this should be a broader discussion with lot of ancillary group managers as well and should focus on "Has this individual contributed at a level above their current pay and role?" "Do we all think this individual can handle this new role/level and be effective?" "Do we need more people at this role/level?"

Re: Designing an Engineering Performance Management System from Scratch

#70

Post by muro »

walshemj wrote: post #68
muro wrote: post #56

Earlier quoted context omitted.

Lotteries were tried, they are the worst system possible.

Got any case studies you would care to share with the class

This one is famous:

https://www.google.ch/amp/s/www.cnbc.com/amp/2018/03/05/unit...

Post reply on HN