Ask HN: What does performance management look like at your company? I'm curious to learn about staff performance management at other companies to understand what works and what doesn't. How does your company set goals, evaluate performance, etc? Do you use OKRs or a similar tool? Thanks! Edit: Clarified that I am asking about staff and employee performance management. Thanks! |
1. Agree OKRs with managers in the beginning of the year (to be completed by March). Everyone at same level/hierarchy will have same baseline.
2. Performance evaluation in October. Employees discuss their achievements with managers.
3. Results disclosed in February.
This waterfall-ish process never really worked:
1. Over the year priorities change, teams evolve, and products take new directions. So, everyone used to put vague OKRs.
2. Evaluation process is a black box. Performance metrics (if there really were any) were never disclosed, and were calibrated at multiple levels.
3. You get to know only your evaluation. No data to compare to whatsoever.
I've seen this doing damage only. People with good visibility, and network used to get better ratings despite average work. Silent hard-workers will get average ratings, and will leave.
We use KPIs and 360 feedback. These are not perfect measures, and I acknowledge that often, but are good enough for some purposes.
Performance reviews are easy for all sides if there is nothing new in them. If you either side is surprised during a performance review they are not talk to each other nearly enough during the reviewed period.
If I had the opportunity to evaluate I would experiment with more frequent feedback - like monthly sessions, small forms focusing on a very few key items.
So you don't give them too much weight, you don't want them to influence employees too much. We used to do that and it impacted company culture negatively IMHO. Now it is under 20% of the score and so it cannot be abused, but it remains a useful tool.
We used Google Sheets and asked for qualitative feedback on defined headers (skill with KPIs & culture/values), and a rating (1-5). Each of the headers had weightage that changed with roles & levels.
We tried to make promotions and compensation changes as data driven as possible, but they were inline with intuition / general opinion. To the employee it always felt like "Why did we do all this for such little change?!" It sucks but you need to improve the system across many years. With every round try and understand signal vs noise. That's how you build trust.
Consistency is key. A few learnings regardless of the system that I learnt the hard way:
* Communication. You need to communicate before, during and after the process. You need to make it relatable for all levels of employees. Give them specific templates with specific examples. You need to remove the narrative of you-vs-them, doing-this-to-justify-an-increase, and bring focus on reflection.
* Frequency/Cycle. "if it hurts, do it more often" is the quote that applies to this. Never let it slide. Minimum every six months, ideally every quarter.
* Review of KPIs. You need to review the KPIs every week without fail. It forces you to focus on metrics that you can move on a week-on-week basis. Anything that changes in step function over a month/quarter/year can be broken into a smaller metric.
* Rewards and Recognitions. We were always late on this. Always rolling out the red carpet when someone threatened to quit. It always felt like extortion as the manager. Don't wait for the cycle to call out extreme performance (great and terrible). Give negative feedback in private as quickly as possible. Do a non-monetary (Amazon Gift Coupons etc) for great performance. Wait for promotions and compensation.
* Pay performance linked pay well. I think this was what I got wrong the most. I did not plan the company finances well enough to pay out immediately. I would say "Hey great performance! We will pay you $$ but in 2-3 months when our situation improves". That erodes trust in a moment.
* Getting and acting on feedback. I struggled on this one too and made many excuses -- we are going through a curve
Hope this helps. I would love to hear from others.
First, the levels, because I perhaps have a different interpretation of these than I'm used to seeing. There are essentially three levels that correspond to performance compared to expectations. So underperforming, performing, and overperforming. Only underperforming carries a negative connotation [0], because it means that you are not meeting the expectations for your level. In contrast, overperforming means that you are reaching beyond your current level.
So, hopefully we have zero people underperforming. Also, hopefully we have the vast majority of people performing. Because overperforming basically means we need to be finding an expanded role for that person, which we may or may not have. If too many people are overperforming, then we can maybe expect turf wars as people start trying to expand their role without guidance, which is terrible for morale. Hopefully we can balance overperformers with growth, so we are moving people to expanded roles and then filling in below with new hires.
So, given this leveling, there are two types of goals: baseline and growth. Baseline goals apply to the entire team and define those baseline expectations for that team. Meeting these goals will keep the team out of underperforming territory [1]. Growth goals are tailored to a specific individual, and detail specific targets to work on. The idea is to provide meaningful growth to the person and their capabilities, with an eye towards expanding their role. Over time, having and meeting these growth goals will result in overperforming as the individual fills that expanded role more and more.
[0] Caveat: I would expect a junior-level to be growing. So juniors who are not overperforming are worrisome.
[1] There's a bit of issue here in team vs individuals. Generally, as long as the team is successful, I tend to err on the side of overrating individuals. After all, part of the reason we make teams is to allow them to shore up weaknesses and play to strengths. However, I leave in an out by having a baseline goal centered on teamwork and team success. So if someone is not contributing as expected to the team, there's something to call them out on.
It's generally accepted that using them for performance reviews is a bad thing because it encourages people to be conservative and create hackable key results.
In one of the companies I worked for : one hand we were doing marvels in automating stuff and repetitive work which saves ton of manual efforts and reduces human errors , and guess what ! its not even accounted for in the standard goals..
Sometimes you need to stare at the bullshit and say here we go and beat the crap out of it..
“I will speak ill of no man and speak all the good I know of everybody.”
― Benjamin Franklin
Last job, my last performance review. There was literally only 1 complaint against me. I was late >40 times. My boss told me he was disappointed in me. I was upset because I was never ever late to work; I was always early.
I asked him to tell me when I was late. He pulled it up. Everytime I worked the weekend because I was oncall 24x7; I would swipe in and because I swipped in after 8am or whatever it was considered a late.
So not only was I going above and beyond helping people afterhours, I was taking a hit in my performance review because of it. Dont care how stoic you are, that hurts.
I reported this to my boss. The next day I was fired.
Really I think any company that waits until performance review time is really broken. That could be a year, or sometimes many years.
Also, the usefulness or performance management is usually undermined by the fact that the people doing the worst usually are in hardcore denial as to their performance. Those people are the hardest to change and manage. I've rarely seen performance management actually fix a problem, other than making the environment so unpalatable that the person just leaves.
I really wish I could have all that time wasted on writing useless "self-reviews" back. Even if I was staring at a blank wall it'd be time better spent.
If I'm doing my job well, reviews should mostly feel like a formality. They shouldn't take much time from me or from my reports.
If I'm doing my job poorly, one signal of that is that a review takes a lot of effort. If a performance review takes a lot of my time or that of the report receiving the review, it suggests there's been some considerable communication breakdown. Typically this means the report has been performing poorly, doesn't realize it, and I have failed to convey this situation to them. More rarely, someone is doing well but I failed and made them feel like they were doing poorly.
In this way, I still appreciate the review process. It encourages me to confront performance management issues continuously throughout the year, and in the worst case that I slip up it provides a safeguard that makes sure I eventually do get on the right page with the employee.
That said, I once worked for many years at a small company with no formal review process at all. At this place, there was practically no communication from upper management about how they thought you were doing, whether they understood or valued your work, what they wanted you to focus on, etc. After years of this, I left feeling rather bitter and unappreciated.
For all its flaws, the review process at forces a conversation where you get to summarize to higher management what you have accomplished and why it is important. Peer-review at least gives you a chance to call out outstanding work from your co-workers. And the review itself at least gives you a venue to hear what management thinks of what you have done.
Anyway, I'd do a lot differently now, if I were back at the old place. But on the whole, I think the review process is actually a good thing.
> For all its flaws, the review process at forces a conversation where you get to summarize to higher management what you have accomplished and why it is important.
In my experience, they've decided it already and don't really care what you put down - unless they want you to get a promotion and then they will care as they need buy-in from others. Particularly, if they want to screw you over, then it doesn't matter what you've written (i.e. even if you put in great accomplishments you can still get a poor rating).
> Peer-review at least gives you a chance to call out outstanding work from your co-workers.
Same thing here. We used to require naming 3 people to give peer feedback. When they want to screw someone, the manager would actively seek out negative reviews to support his case - regardless of whoever you picked.
> And the review itself at least gives you a venue to hear what management thinks of what you have done.
I can agree with this - although where I worked they'll let you know throughout the year. I did have one manager who was very reluctant to give negative feedback, though, so I suppose this benefits the employee where the manager is at least forced to formally give you negative feedback.
Processes are good in general, but useless if the system doesn't value it. If the manager can actively go and solicit feedback from folks you didn't nominate, then why waste my time and the time of the people I did nominate?
I cheered when my company stopped doing annual reviews.
The fact that the performance rating is good means your manager probably is acknowledging the work you do, just not to you. The manager input for ratings is hugely important at the FAANGs, so your manager is clearly telling others you're doing a great job. There's just clearly a gap here between you and her/him in that feedback.
Source: Am a manager at one of the FAANGs. I'm finding that everyone is overthinking every bit of feedback right now. Clearly minor feedback is hard to differentiate compared to major feedback. Likely due to the video communications barrier and that everyone is a little bit more alone with their thoughts. I'm being cautious on delivery because of it. There's also less ad-hoc thank you's and acknowledgements going around due to the remote barriers.
Also, never forget that your performance is 'capped' by your management chain. While others may see that you are amazing, the best they will be able to do is poach you to their team, but they can't override your manager's feelings about raises, promos, etc.
(I feel like I'm talking to past me, who I really wish I could have told this to earlier.)
Competent managers don’t need to do performance reviews and bad managers are not helped by them
In Finnish performance reviews roughly translate to "Development discussion" and in my experience that's exactly the case as well. I've spent most of the time in my reviews talking about my boss about how the company can support me better and how I can achieve personal goals (raise, titles etc) and what I'd need to do.
That said, it isn't too unusual in my experience because people who are good engineers usually get told "you should go into management if you want to keep advancing" but they don't tell them "Oh, and this is a completely different job than you have been doing and none of your skills will apply, kthxbye!"
For a long time in my career I didn't want to be a manager because I didn't trust myself to manage well. And it took a really bad manager at Google to educate me on what the job of a good manager is. I stumbled around a bit but figured out that there are two things a manager must do to be successful; first is to communicate with their team what is expected of them and how that expectation will be measured, and second is to listen to what their employees say to them.
Sounds kind of simple but it's actually kind of hard to get right.
Performance management is drilling down into understanding what is going on with the person who is failing to meet their expectations.
If you both understand the metric for measurement, whether it is lines of code or time to delivery or what ever you have worked out with the employee ahead of time, both of you have to look at the metric, and the action to date, and get to a common understanding of what is going "wrong."
The most common problem I have dealt with are people who claim to be "senior" from a large company but don't really have any idea what that means other than "time spent in the role." I have pretty qualitative definitions of "entry level", "experienced", and "senior" that I work from and right away I try to communicate that to an employee. Sometimes they get hired into a role that is "above" them and they are unable to rise to the challenge, sometimes its just a different work flow than they have been used to.
The second most common problem is ego. An engineer who defines themselves by how good of an engineer they are, has a really really hard time looking critically at their own weaknesses. That conversation usually has a lot of "this doesn't mean you are a bad engineer, it means we have to work out how you can be even better than you currently are." type discussions.
The third one that comes up are people who are doing the job because someone else (spouse, parent, peer) thinks "it's a good job, you should be a ..." rather than the job they really want to do. As a result they put in only enough effort to not get fired and not much more. I'm okay with that if they don't mind being paid at the entry level wage level. If they are in the mindset that "I've got five years of experience and <reference> says I should be making $Y at this point." Then we have the conversation about "careers" versus "jobs". There are plenty of people who just want a paycheck and will do the minimum for it. They do fine work and clock in the hours, but they don't add value to the team like someone who wants to be good at what they are doing.
Too many engineering managers try to treat engineers as cogs with the only power of "do it or I will fire you" to motivate them. From my limited experience with this type of management it only works so much, and it doesn't build teams, or good product in the long term.
I have had good managers, but for them, the performance review process actually tends to hamper them. A good manager who knows all the people under them are amazing and then has to stack rank them is going to make someone mad. Your manager only has so much power. Then it's their manager, and their manager. Managers don't have infinite amount of social capital, or even the amount they deserve. Some have too much.
I agree, performance reviews can be a time to get feedback and make changes, but in general, I find the continuous feedback (from standup/team, customers, daily work, incoming types of bugs) much more useful. If anything, I feel that my written reviews have had a lot of dissonance with the financial results or lack of promotion. Many times I can have glowing written reviews, but due to stack ranking, budget, or whatever other excuse they want to use, many times it just doesn't line up with results from management. And it's impossible to hold management to account in general, which is why HR is there.
So when you're doing bad, performance reviews are a stick. And when you're doing good, they dangle the carrot, but many times you can't grab it. Then they force everyone to do mandatory training about how objective the process is, even though it really isn't. And that level of gaslighting has spelled the end for many good employee/employer relationships IMHO.
One secret I would tell any engineers considering management: "management is a career change, not a promotion". Charity Majors has some excellent blog posts on this, including the Engineer/Manager Pendulum: https://charity.wtf/2017/05/11/the-engineer-manager-pendulum....
As an engineer I agree that "time spent in a role" does not say anything about the quality of an employee.
That combined with the mindset of someone who clocks in the hours, adds up to a person that can be hard to work with. At least if your own mindset is that you want to be good at what you are doing.
An example of that is a manual task that is holding the team back, but nobody is really pursuing how to get rid of that task or automating it.
Anyways, many good points and it definitely sounds like you are one of the great managers out there.
like:
"Gained Expertise in product X in Q3." "Implemented self guided research in Technologies X,Y,Z in Q1" "Member of diversity committee in Q1-Q4" "Increased bug detection by 10%" "Code quality increased by 15% per code analysis done by codetech.com" "Upgraded deprecated libraries on build servers"
1. Every Wednesday I Google Meet with my salespeople. We review the prior week's priority prospects, this week's, and then I ask them about clients not on the list that our BI system has identified as promising. An integration of internal systems, Slack & Zapier alerts me each day to anomalies (good and bad) with clients, inventory and systems. MixMax (shout out to Brad!) is a big help in tracking email activity. RingCentral reporting is a big help in validating Salesperson activity.
2. Every Friday I review Github repository activity for my development teams. A very soft-touch and collaborative conversation follows for developers and engineers whose pace of work or direction seems off. This is almost always a result of improper scoping, unrealistic milestones, or miscommunication.
3. Every Monday and Tuesday I'm hands-on with my marketing team preparing for the Wednesday release of our marketing communications, and reviewing ongoing advertising campaign results.
4. Every weekday I'm in our Xero accounting software looking at cash flow projections, inventory, A/P and A/R. Xero is hot garbage IMHO, but I've built some integrations that make is easier to use for real-time reporting.
5. I visit our satellite facility every other week for in-person chats with that team.
6. I've invested a lot in automation to track our market, predict conditions and generate alerts.
Notwithstanding 1-6 above, there's no substitute for good market conditions and good employees. I have the latter, but not the former. I mention this just in-case you're thinking you can systematize your way out of a demand vacuum.
As a developer of internal web apps, it is apparent what I must do next to serve my users, in the next week, month, quarter, year --- I have a long to-do list! It is also apparent what I must do to serve my team, in the next week, month, quarter, year. (I get rave reviews from both, unsolicited.)
The goals that cascade from the executives are laughably vague and obvious: cut costs, increase revenue, reduce maintenance, get to the root of recurring problems, please the customer (of course they phrase those things with your typical multisyllabic jargon). So what the process ends up being is taking my goals that I have already got and writing them down in another place (a shockingly flimsy and probably expensive web application they bought from a vendor) using certain words that they like. It is a total waste of money and time (which, ironically, is counter to at least two of their supreme goals).
Let me be clear. While it is theoretically possible that the executives know of a problem or need at the company that I don't, and when they share their company-wide goals it would be news to me, this has never happened. There has never been a time when the yearly goals come out and I say, "Oh, well, now that you put it that way . . . "
On the other hand, I must be above average, because there exist many at my company who, left to themselves, would sit around and do nothing, or worse. Presumably this whole ceremony is in reaction to their behavior. In my opinion, such people should be fired, not babysat.
Don't get me started on stack ranking or making sure everyone "fits the curve" by knocking down everyone to average because HR said so.
Exactly my experience as well, but it's often not even thinly veiled.
These processes should not even be referred to as "performance" reviews since they often have little or nothing to do with performance. It's loaded and deceptive language.
Getting promoted has very little to do with the role profiles of the above grade but instead involves doing some menial task, for example I knew a guy who was a total manchild and would smash the keyboard, groan and hide in the toilet if he encountered some difficult code, he would also never ask for help but because he did support he got promoted.
Also there's a limited number of slots, so you could meet the criteria of the above grade go through the process and still not get promoted. We basically lose all our developers after 2-3 years and most projects are composed of contractors. people who can't leave before 2 years and mediocre developers who are promoted way beyond their means and aren't good enough to work at other companies.
The worst thing is our clients usually have a high opinion of us so our competitors must be even worst.
They'll get rolled out with a big hype, people will fill them out with varying degrees of diligence and understanding of how OKRs are supposed to work.
3 months later they're already forgotten and out of date. Some managers will try to keep it going for their teams, because that's what they were told to do, but that'll peter out once they realise no-one else in the org is taking it seriously.
6 - 12 months later there'll be a half-hearted attempt to reset and resurrect the OKR process, but after the first time people take it even less seriously the second time around, and after a few more months OKRs are never mentioned again.
> 6 - 12 months later there'll be a half-hearted attempt to reset and resurrect the OKR process, but after the first time people take it even less seriously the second time around, and after a few more months OKRs are never mentioned again.
At GitLab (I don't work there but it's explained in their public handbook), OKRs are updated/redefined every quarter. Seems a good way to avoid the issues you are describing.
An OKR is about a paragraph of text per quarter, hardly seems cumbersome.
I'm currently a director of a twenty person office. My current teams are supposed to have stack ranked individuals, so I simply give everyone the exact average. I also give everyone the same objectives: improve performance with technical debt repayment, use retros to determine working agreements and adhere to them, adhere to a WIP limit and then help any other team areas when there are bottlenecks, do weekly research to keep your skills sharp, self organize your team to best meet the business goals, help anyone with their job when asked or offer a time when you next are free, and if you have no work ask your team for something to do. These are pretty easy to meet, so people usually do well on them.
Ultimately compensation is tied to the whole product, not the employee, since we all split any money evenly.
I find this works exceptionally well at ensuring the ultimate goal is team performance, not individual performance.
Team members not pulling their weight are identified and asked to find a new job or improve. The ones that don't are given low ratings and let go.
In all it allows us to have a very stable team of high performers. Our average tenure is over seven years. No one has any incentive at all to "beat" everyone else. I've found the teams that employ such tactics never have long lasting talent anyway, just a string of "heroes" who burn out after a few years.
Also I flush this out with a regular "salary review" where I try to ensure everyone is paid fair market rate for their job. This happens maybe every 18 months or so for new grads, and less frequently as people get closer to salary ceilings for our location.
Thanks for sharing your wisdom, I may be referencing it in the coming year.
1) Their attitude stinks but nothing specific that can be picked up in a disciplinary on its own
2) They have been in the job for a few years, and their old manager never recorded the behaviour problems
3) Their role is not redundant
So to get them out you meet regularly, set short term goals, and be really picky about not meeting them. The whole thing is designed to make the staff miserable so they leave or get sacked for missing the goals, whilst building up a substantial volume of paperwork supporting a legal defence at tribunal.
Or less cynically it allows the staff to understand what is expected of them, so they perform better. This never works IMHO
However, it is occasionally successful and those (admittedly rare) occasions have been some of the most rewarding experiences of my career.
I also don’t think that what you have described is necessarily a bad thing. As long as the manager goes into it in good faith and genuinely tries to understand what the problems are and to help solve those problems then the process works well for everyone - either they improve and become a happy and productive employee or they leave (voluntarily or not) and can seek a position more suited to their skills or personality.
Most of the times I have been through this the person involved was perfectly capable of doing the job but they just didn’t want to for various reasons and putting them on an improvement plan helped them see this and they move on themselves before they were forced to
Second company: It was a huge joke. The CTO invented KPIs that were unattainable and didn't matter, and we were given raises purely because our contract was profitable.
Third company: We had such a ridiculous process of "Write three goals and go over them with your manager", which turned into "Just write anything so HR doesn't complain." The goals were totally useless. Engineers did not have the ability to decide what they worked on or how it went, but the goals implied they did. It was awful and, luckily, did not effect bonus targets.
I honestly think that "performance management" at most companies is a huge joke. I haven't seen it, and none of my peers have seen it, run successfully or be taken seriously. Companies want to pretend they care about your career trajectory and goals only until an employees goals require any legitimate effort from the company's side. The goals/KPIs are pretty much only successful if an employee sets those goals to be "Do whatever their manager thinks they should do", which I would argue isn't a goal at all.
At our company Goals/OKRs are set at the individual, department, and company level. You can align your goals up, or set individual (personal growth) goals. These can/should be reviewed in your weekly 1:1s with your manager. We allow anyone to send recognition, or send or request feedback at any point. We have several templates that facilitate different feedback types. We do quarterly Check-Ins which is more of a top down performance review where you can reflect on goal progress, feedback, and next steps with your manager. The 9-box talent assessment is calibrated for each employee twice a year. We also facilitate surveys at the company level to help do things like eNPS scores. If you want to learn more, ask away or check us out at https://www.kazoohr.com/
Prior to working at Amazon, I had mostly worked for start-ups. The thing I found at startup is that people are trying to figure out processes, and it's kind of hard. Most people putting in a process (whether that's HR or the founding team) are trying to do their best, but start-ups aren't at a large enough scale where they really need to have scalable processes, and for individual contributors all the distinctions are pretty informal anyway, so there's usually no individual contributor promotion path.
At Amazon, I was fortunate to work under someone who had been my boss previously, and we had a good working relationship. He was not afraid to give me blunt, useful feedback about either my work or how my work was perceived.
At some of the start-ups I worked with, part of the year-end evaluation involved filling out a form with a lot of evaluation criteria - the employee would fill out a self-eval form, and the manager would fill out a form, and then they would compare during the evaluation meeting. There's no such equivalent at Amazon.
One thing that overall I like about Amazon's performance management in terms of promotions is how it's centered around a document that you and your manager write together. There are some tedious aspects to the process, but if nothing else when you go up for promotion you know what your manager is officially telling other people are your strengths and weaknesses. The flip side of the process is that decisions about your promotion are being made based sometimes on the quality of your promo doc. I'm not sure about all the company, but at least in the team I was on some of the senior folks set aside time for reviewing promo docs that they were working on with other members of the team to iron out any "doc writing" issues.
We don't really have an official OKR system, but as a more senior engineer my personal goal has generally been to enable whatever my team's goal is for the quarter or year (launch this product; get this architecture document done; research how to solve this problem).
Besides the official process, I've also found it useful to ask trusted peers how I'm doing, whether I'm giving them everything they need and expect of me. It's also pretty common to have one or more mentors outside of your team to give you more informal feedback.
I'm a broken record about this.
1) Pay
2) Promotions
3) Accountability (e.g. firing)
4) To satisfy legal requirements (perceived and real)
Performance management falls under the umbrella of HR. HR's historical roots are in compliance. In the 90's when cost vs. profit center was the rage, the HRBP model emerged to prove HR could provide business value beyond compliance. HRBP is the dominant model now but it hasn't had the impact its creator intended. Inertia is a powerful thing.
Combine HR's roots in compliance, with the above four reasons performance management exists in practice and that will give you a good way to understand why performance management works the way it does.
If you're learning about these things in an effort to improve your own organization's practices then you can also use the above to evaluate any proposed changes and think about what they would have to contend with. History is replete with failures. Unless you are in a small organization, with total control over incentives and the culture then I will leave you with a quote from Blade:
"Some motherfuckers are always trying to ice skate uphill."
Different strategies perform well depending on size. For example, most of the time I find OKRs a little excessive for a small team.
Have you identified KPIs? What are they?
"What's measured is managed," said Drucker. Personally, finding what exactly to measure is difficult. So don't be afraid to spend a lot of time figuring this out. When you do, all the other performance management strategies will somehow find a way to work towards your goals.
As senior dev / senior consultant I had to pick goals like „prepare a pitch for a potential customer“, stretch goal „win a pitch“. I didn‘t want to do this. I don‘t care about sales. I want to design and develop systems for someone who wants me to do that, not convince someone to let me do it.
By now almost everyone quit.
Current company: I can work in peace. Bi-weekly 1:1 with my manager that is usually over rather quickly.
The problem is that marking a task as finished does not mean that its deliverable is solid. A developer can game the system by leaving technical debt behind for others to fix. In this way, the developer is stealing productivity from others, by forcing them to spend more time reading, debugging, refactoring their half-baked code.
A neophyte manager may buy into this approach to performance, and even encourage it. But after a few iterations of this unsustainable practice of leaving tech-debt behind for no reason, reality sets in: now you need an army of engineers to get things done because the system becomes fragile and complicated. And you also need an endless amount of documentation that is constantly getting out of sync.
In a way, under poor performance management rules, development becomes like a game of pool: it's not only about having a higher score, but also about making it more difficult for others to have a high score. If you want high productivity, recognize this and penalize it.
In any rational world, execs would be basing their OKRs on something similar to https://stripe.com/atlas/guides/business-of-saas#the-fundame.... Instead it's a trickle up process whereby people tell execs what they want to work on, then the execs group those into OKRs. Also the OKRs appear to only have one level, despite being an org with a thousand people. And finally, the system uses the internal wiki to track, rather than integrating with the project/issue backlog tool.
Annual reviews are even worse. People fish for peer reviews that paint the rosiest picture. They only happen once a year and if something bad is going to happen to you, I recommend it happen directly after reviews, and absolutely never right before them, the recency bias is huge.
I found this happening when our firm used KPI metrics (key performance indicators). Whichever metric management emphasized, those would shoot way up via ... weird methods (all sorts of finagling, but not necessarily helping overall firm performance). Every time they optimized for some other lever it would have all sorts of unintended outcomes on other metrics and overall people spent more time trying to get around the system and increase their metrics than just doing a good job. System was scrapped < 12 mo later.
Then managers talking to their reports, discussing results, giving and receiving feedback.
Grades are from 2 to 5, greater is better. Normal grade is 4, it gives a bonus of 1/2 of monthly salary. 5 is 1 monthly salary and 3 is 1/4 of monthly salary. Our compensations are on market, so we ended up better compensated even after grade "3".
Two 5's in a row is an occasion to talk about promotion. Two 3's is a reason to talk about leaving the company.
That's about it, the whole process takes about two weeks, most of the time in a grade calibration process.
As a manager of a team, I tried to institute OKR's into the process for my team at minimum. I found that technique partially successful -- meaning successful for me and my team but limited in that other teams in my department wouldn't adopt them. Too much work they said.
However, it really meant you were scored as either 3 or 4 as "nobody is a five and if you were a one or two you wouldn't be here anymore". My manager and I did agree it was a silly system so we settled on me being a 4 and I set everyone who reported to me as all 4s - even though they all deserved 5s.
I can't really tell you how it's measured or anything like that. The company has policies about it, but more often than not those policies are blatantly violated. It basically comes down to the subjective opinions of your manager, the department head, and the business people you interact with.
I agree completely, however that is usually far different than "goal setting" in my experience. It's far more about opportunity, which unfortunately is also handed out by management.
> Even if you're motivated to improve on your own you'll be working with people who aren't and that's more stressful and annoying than any number of performance measurement systems.
Welcome to corporate life. I've worked with a lot of people who could care less about doing better, and sometimes that's right (hey, some of those people even have kids, which I would say is a better use of time!). I'd say performance reviews add more stress and strife than remove it.
Nobody ever checked the progress of the OKRs either, not even at the end of the measuring period and not even to calibrate the realism of the goals for the next measuring period. Once, when asked at an all hands meeting by the person who had been designated "OKR champion" a year earlier, the CEO answered he had forgotten about it but that OKRs were certainly still on.
I think the most success was had by a single guy who had managed to get "increase twitter followers" on his personal OKR list. Not for some company account btw, for his personal twitter account. It was continuous hilarity, but I don't regret not working there anymore. Whatever system you use, take it seriously.
That said, when performance review time comes around, that also means that it doesn’t really mean anything. The important thing is how your manager feels about you, and the rest is a formality.
Would be interested to hear more details about your thoughts on this. Do you look at # of commits, lines added/subtracted?
2. Commits over 2-4 weeks. I expect commit gaps that can last up to 2 weeks given some of the problems and constraints unique to us.
Curious to understand more about these? I've been doing a bit of exploring in the analytics space here, and would love to know where you found the available apps falling short.
It took me 20 mins to build a monthly revenue dashboard in metabase that updates live and you cant do that natively with Xero.
I'm curious about how you effectively context-switch between sales and code reviews and marketing.
Do all of them report to you?
Rapid context switching is taxing and something I try to avoid. Some folks are better at switching than others and I guess I am one of those people. I do try to separate contexts by day or portion of day. I also have many years of experience with all this, so decision-making carries a low cognitive load for most problems.
Client interaction with website.
Client follow-through on 'promises' --> sales methodology we employ.
I feel this same way at most places I've worked. But as I've gotten older, I've started to think "how can I level these people up?" and that has gotten me much farther towards my personal goals than the prior thoughts.
Not staying you should or that you aren't already. Just a thought to past me.
I will say though, that the executive layer above our heads is not to be totally dismissed. They do have vision into things that we can lack, namely people and culture stuff that has significant impact on the company's long term trajectory. Or maybe big acquisitions and whatever. But the people stuff is what generates all the perceivably asinine people management stuff because if you get rid of the average nonautonomous employee, you have no one left pretty much. Hiring good engineers is HARDDDDDDDDDDD unless you can just bury the problem with cash.
The best potential solve I can personally see still hinges on having the right people. For any unit of people at any scale doing anything, a leader who can effectively recognize who to empower within what boundaries feels like it's by far the most crucial thing. I'm not sure there's even a way to have a pilotable thing made of individuals without having a conductor. If you just build out the org in a way where it can be conducted and put good conductors in place then they will be able to tell you wtf is going on at the level you need to know about and effectively translate your intentions into implementation.
Feels like this is the why behind the whole "idk y'all figure it out" style of startup engineering nonleadership that's becoming common these days. People just flat out don't know what they're doing, and even when they know it, they obscure it for self-serving reasons. If you have a leader setting this example via doing anything but having technical field vision and directing as a respected and well liked military officer would, then you will have an engineering org that is optimized for bleeding money.
I can't emphasis how important this advice is in general - Use it to validate everything you read about, especially on HN.
If you work in a small organisation or team (the ones that don't make lots of noise) then most of the advice out there, from technology choices to management choices, are going to be biased against your size, some of those choices are the direct opposite depending on size.
https://medium.com/centre-for-public-impact/what-gets-measur...
Similar quotes are often attributed to Deming. He never make this claim either.
Edit: typo
Can you explain this one a bit more? Are there specific pitfalls of the OKR system that don't work well for small teams?
Is it purely a size of the organization as a whole? i.e. If the whole company is <10 OKRs don't work. Or is it inclusive of team size? Any group/unit of <10 should not use OKRs, too single metric heavy.
In my understanding, OKRs are dependent on organizational clarity of the mission, vision, and metrics.
Now I'm sure there are plenty of teams that have matured in their space and have this organizational clarity.
But when I was referring to small teams, it was in the context of "we're small now, but if we make this work, we'll be bigger."
In the latter, decisions are going to be more bite-sized. And going through the OKR exercise could take as much time as the execution of the tasks.
Edit: in other words, OKRs are great for well-defined outcomes, where the time required is longer than what would be expected from an individual contributor during a week-long sprint.
That said, I think calling them "performance reviews" to be a disservice as well. (I prefer 'Focal Reviews'). I try to stress in reviews a write the ways in which I feel the person is making progress against their medium and long term goals, and where they are perhaps stuck.
In terms of promotion and pay however, we may disagree. I try to distinguish between someone improving as an engineer and someone doing a good job. It is a subtle difference but it is an important one to me.
Using the example of a fictional programmer, if they get their part of the projects done on time and their code is of high quality and reliable. Then I think they have done a great job and if I can I seek to give them a bonus of some sort to reward that.
If this same programmer gets their part of the project done, and helps others getting their stuff together, and perhaps refactors the project so that everyone has an easier time integrating and testing? Then they are a better engineer because they are acting as a force multiplier for the entire team. Those are the people I try to promote.
I'm not a big fan of raises for "time served" as one manager I knew put it, although I do believe you have to adjust to the market so if salaries are going up across the board you should reflect that in the pay of your engineers.
It is always my goal that annual focal reviews are not a 'surprise', rather they are a summary of the previous 12 months.
EDIT: I don't know what country you are in.
If your manager is keeping your performance results from being reflected upwards, you have a problem.
Becoming a manager because you think that is the only ladder to climb is definitely the wrong choice. I think a great manager is also a leader who takes an active interest in the motivation, growth, and outcomes of their team. If a management team worked the way you describe (manager's managers run the show and broker deals with their peers for micromanaged promotions), that would be an extremely dysfunctional environment.
In my experience it is always the direct manager who recommends someone for promotion rather than the next level up (although your manager's manager likely has final approval on budget). As a manager, I support and coach my team toward their career growth aspirations with regular performance & growth conversations. I also try to ensure my direct manager has visibility on the state of the team, but ultimately they are expected to be looking at a bigger picture and trust that I am taking care of my team.
They both need to praise and recommend you in order for you to be promoted (your manager has more to do on that). A bad word from either will kill any prospect of promotion instantly.
They both need to carry their weight for the team and the department respectively. They put a ceiling on what your team and your department can do and can get (work, budget, opportunities). In a bad case there's simply no slot for promotion so you can't be promoted. In the worst case your team/department might get gutted.
You could have a very deep sales methodology. Just curious if that's how you do it
- Write up self review. 1-2 pages to highlight what you worked on and accomplished, who you helped, why it matters. Score yourself on various dimensions of how good of a job you are doing (working with others, getting stuff done, etc.)
- Nominate 3-4 people to give you peer reviews. Best to pick people who can speak to your work, ideally with some folks from outside your particular group, and ideally with some seniority.
- Managers decide who to ask for peer review about whom. You'll get asked by various managers for feedback about their reports. Write and submit this feedback -- could be as short as a paragraph, more typically 2 or 3 paragraphs: what did you work on with them, what did they do achieve, what could have gone better? I've probably given feedback for 5-10 people on average.
- Manager synthesizes all of this into a report, score you on the same dimensions.
- Manager meets with you, gives you their report, goes over it with you. There's a lot to this meeting. It's a review of how they see your work, a comparison of your self-scores and their scores to get on the same page, a discussion of noteworthy feedback from others (positive and negative), a chance to defend yourself against any negative feedback, and a discussion of ideas for addressing any concerns. Typically there is also a lot of goal-setting for the upcoming year, and more generally a discussion of how things are going, how happy you are, and so on.
- Formally acknowledge that you discussed the report with your manager (checkbox in some system). This also gives you a chance to formally comment on the report, I imagine in case of some dispute.
- Followup meeting, some time later, deals with compensation adjustments, promotions, etc. This is kept separate from the review itself.
Effort level has been perhaps 2-3 days per year for writing up all the reviews. I'm sure it's worse for managers.
The individual goals are set in this year's review, evaluated in next year's review.
For estimation, hours is a good measure, even more so when there are external consultants that get paid by the hour.
Developer velocity can be measured by tasks/features completed compared to the estimate.
Could you elaborate on why story points are useful or perhaps point to some resources on the topic ?
There was an expectation that devs complete about 8 points a sprint. I don't know if the eight point target is common, but SAFe does talk about comparing story points across teams.
> At scale, it becomes difficult to predict the story point size for larger epics and features when team velocities can vary wildly. To overcome this, SAFe teams initially calibrate a starting story point baseline where one story point is defined roughly the same across all teams.
...
> Give every developer-tester on the team eight points for a two-week iteration
Otherwise, somebody ends up trying to convert story points into hours and that's not what it's there to measure.
I wrote extensively about this a couple of years ago before I found out about SAFe itself.
https://www.brightball.com/articles/reality-driven-developme...
I've loved it at my company. It seems like development best practices + sanity enforcement outside of it and it's fairly flexible too (we use kanban instead of scrum).
It's done wonders for putting the planning of how things should be implemented into the hands of developers themselves and then essentially gets out of the way.
One thing is you need 100% collocated experienced people who know what they are doing - no third party agencies who spend 15 mins discussing pixel separation in photoshop mock-ups.
It also not something you'd carelessly throw a junior or an intern into
It’s supposed to be getting out of the way of developers.
Secondly, and more relevantly and importantly, I'm about to walk into a shooting match to defend my employees' performances against a larger pool. And what I need in that battle are bullets. The more bullets I have, the more successful I will be. So load up my gun with every single bullet you can think of!
If someone is underperforming then you take steps to try to understand why and help them to get to the level the company needs them to be at. Hopefully this works and everyone is happy but you need to be clear (to your employee and yourself) that ultimately this could end up in dismissal if it doesn’t work out. This is when you document everything and have regular meetings with the individual so everyone understands what is going on and if it ever becomes legal then you have everything you need to justify your decision.
Point is, you only need to do this if someone is underperforming so much that you’re thinking you need to dismiss them, and if someone’s performance is bad then you don’t wait for the annual (or quarterly or whatever) review before doing something about it - you deal with it straight away
The more savvy people started applying at other companies the same day they received the PIP, since it was clear to them they would have to work significantly more for no increase in salary and they perceived the attainable effort/reward ratio to be better elsewhere. In one case this led to hilarity when the CTO had instructed the managers to PIP at least one of their team members "for morale reasons" and it ended in more than a third of all devs leaving the company in the next two months.
BAD idea with most managers. Your manager is likely to be vindictive and insecure if confronted like that. Even with peer reviews in place managers have disproportionate influence on your reviews, and promo/comp decisions (something you readily acknowledge). If the manager treats you with disdain, it's almost impossible to fully reverse that - it's just human nature, let alone do so through confrontation.
The best thing is to move on to greener pastures, of which there's vast abundance at any FANG. People can move around easily there by design: that way shitty managers get naturally de-staffed. Anything else is a sunk cost fallacy. Do yourself a favor, and go to a team where you're appreciated, respected, and can work alongside decent people. Do not tolerate this abuse. Otherwise your career will stall, you won't be able to do anything about it, and you'll feel miserable throughout.
Source: been there, done that.
Yes, the chances of retaliation from your manager is not insignificant.
However, the experience with a good manager is always fantastic. If I don't trust my manager enough to give him negative feedback, I don't want to stay in the team. Giving negative feedback is one of the few reliable ways to discover if you have a good manager. I'd rather know than not know.
Source: Also been there and done that (and paid the price, but it was worth it).
The worst thing, though, is to put up with it. I tried it and it didn't end well either, which put me on the path of "Well if it's going to suck, it's better to be vocal than not."
Nobody at any company they don't own should be under any illusions that they're viewed as anything other then replaceable labor. Your salary like everyone else's gets lumped into the expenses column, and your accomplishments don't appear on that spreadsheet next to your name at all.
Some anonymous email exchanges would do, if you'd prefer that way.
"what gets measured gets managed" is one of the reasons I don't like the usual metrics and performance reviews, but in the specific case of a PIP they are necessary. If someone meets the targets of the PIP but starts dropping other required behaviours then you just add that into the PIP to make sure they don't do that