Designing an Engineering Performance Management System from Scratch
blog.gitprime.com
blog.gitprime.com
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, they incentivize people to work on things that have easily measurable short term costs and benefits. More difficult to measure costs and benefits get ignored. They also encourage sunk-cost fallacy. In almost any company, you're better off, at least in the short term, if you ship something that turns out to be a huge waste of resources later on, than if you make the decision "this isn't turning out the way we wanted, we should just cancel this project".
2. They pretend to be a relatively objective system, when in fact your performance rating at most companies is strongly (though not entirely) dependent on how your manager views you. Attempts to lessen the impact of point 1 above will generally increase the impact of this point. Research suggests that most of what passes for rational justifications are made up after the fact to support gut-level emotional decisions.
3. They replace intrinsic motivation with extrinsic motivation, which at least some research has shown can lead to much less durable motivation over the long run.
At one point I was very enamored of the way Valve does things, but now it seems that that sort of management approach produces super toxic cultures in the long run.
Ultimately it seems like the only way to get away from this stuff is to work for yourself or in a very small team with trusted partners.
Now it's more a performance review of the company and myself, and attempts to encourage my team to think about how we could improve the company. "What do you hate about your job? What do you like about your job? How could we apply some of the good points to other areas of the company?" Stuff like that.
If you're underperforming, I should already know (if I'm worthy of my position). And I definitely shouldn't be waiting a year to talk to you about it.
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 review goals specific to the function and success of the team(s) the employee is/was on. The scores are more like pass/fail or exceeds/meets/doesn't meet expectations. It gives a regular structured time for employee growth review and can help with correcting communication and other soft skills.
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?"
This is highly dependent on company environment however and obviously can come with it's own set of motivations and problems.
It's also just as difficult to evaluate team performance as individual performance. With knowledge workers everything is so subjective, and trying to put objective metrics on it ends up being self defeating due to people gaming the system in ways that harm the broader organization.
All of this is a kind of open secret, so the system is "fair" for some definition of fairness. Still, a novice will spend a couple of cycles to understand the unwritten rules of the game. At this point they will either start playing by the real rules or recoil in horror and suffer a blow to their motivation. Of course staying ignorant is also a possibility.
1. Some feedback is useful. Sometimes it's hard to be sure how you're doing, particularly if you're not super-sensitive socially.
2. More is not better. Once a year is plenty.
3. It's mostly subjective. Trying to draw clear lines is probably a waste of time. A very experienced organization may be able to create some guidelines, but they should be guidelines, not rules.
4. In the end it's all about whether you are making the boss happy. The only reason to involve anyone other than you two in the process is when some of your work is genuinely out of view of the boss.
https://www.google.ch/amp/s/www.cnbc.com/amp/2018/03/05/unit...
[1] https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessne... and https://www.jofreeman.com/joreen/tyranny.htm
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 seems to get a top-to-bottom redesign every year or two... having been on the inside, I think this is definitely a symptom of employees optimizing for climbing the career ladder. Promotion Driven Development is a real phenomenon and is in the long-term detrimental to everyone. I don't know an easy solution to it, since bigger and bigger projects are required to "prove" that you should be promoted. Maybe in a few years people will have experienced this enough to think of a better way.
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.
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.
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 trail the company would be on the hook for paying that individual's unemployment.
I'm not saying you're wrong. In fact, I think you are right. Most people will rise to the expectations set for them (or fall, according to the expectations set).
But for performance management, I basically have to put them on a performance management plan and set expectations. If they fail to regularly meet those expectations, then they can be let go. This generally takes a few months to progress through, giving the staff member the opportunity to prove us wrong.
But this process is very different to KPIs. An important one, nonetheless.
1 In order for hr to justify themselves.
2 As a hypocritical way to cut the pay quanta.
What are the alternatives? Is this something we could build an automated system around? Could the functions be moved to managers (hiring, firing, pay, etc.)? It seems like moving this way would be somewhat like implementing the officer/NCO relationship in the US military.
Are there benefits for non-specialized decision making as it applies to employees?
> pay quanta.
What's that?
> What's that?
"paying a lot". So basically as away to combat a (perceived) inflation in salaries
Off the top of my head: Healthcare (especially in the US - as a non-native I was truly shocked the amount of HR time that is spent managing this...), benefits, immigration issues, legal disputes, compliance, pay, hiring and firing, disabilities... there’s plenty for a competent HR team to do at most medium or larger sized enterprises that isn’t performance reviews.
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.
(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.
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 company is a super high performer and everyone is equally as good, then it's not crazy to do away with those titles entirely as long as that's the case. But obviously that scenario won't last long as the company grows, and that's why titles/levels are gradually introduced.
They CAN all be top performers at their responsibility list...
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.
If you actually have 100% of engineers operating at the Staff Engineer level, then it is what it is. However, the only case I can think of when that should ever be true is when you can count your developers on one hand. Once you grow any bigger, it's just not an efficient use of your money or the engineers' time to have that much experience concentration (as opposed to talent concentration, since more junior people can be talented too).
This is not the same thing as 100% of your engineers being good, by any means, so it's not quite a stack ranking problem. In particular you can solve it by hiring good junior people, as long as you're not overstaffed (and if you are overstaffed, you need to find a way to figure out who to get rid of, other than getting rid of all the junior people).
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.
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 you might be better off having a person with market salary $X spend a week doing something they don't yet find boring (and will learn from so that they can become senior) than having a person with market salary $2X spend three days automating and writing tests for their automation.
And there are a lot of interesting real-world problems (as in would-produce-business-value problems) that can't be automated, like gracefully remediating a legacy system where each user was able to get their own weird requirements supported. In the process of getting all the users onto a system you can automate, you need actual human time to work with each user and understand what they need out of your API surface, and while having senior people available is necessary for the complicated cases, it's unlikely to be necessary for all of them (and again, the ones that senior folks would find boring are good opportunities for junior folks to gain experience).
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.
Rather than endless optimization of the system. Train your managers. Everything from giving good feedback to ignoring or forgetting a bias is a skill that can be learned.
The idea is to get to you goals faster and re-evaluate them for relevance as you go along. Since they are not directly connected to pay there is less of a perverse effect where people are incentivised to work on improving their KPI at the expense of the rest.
[1]:"Measure what matters", by John Doerr
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?
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.
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?
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.
'This site would like to hijack your scroll wheel/touchpad', it's genuinely infuriating.
https://blog.gitprime.com/wp-content/themes/Divi/js/smoothsc...
In chrome you can open the network tab, filter on JS, find the smoothscroll request and right click and block it :D