On an individual level, this feels like a box-ticking exercise at the company I work at. Project goals are hard to set out a year in advance as a developer as there's a good chance that within 6 months the direction is changed yet again from product. Personal career development goals are not really considered.
When it gets tied into career progression, you end up with not very productive goals (but easily measurable!) like "Reduce eslint warnings in legacy project X by 50%", because business value are either not easily measurable (how do you quantify better knowledge of the overall system architecture? Bugs not caused? But how do you know the developer didn't just stay in their comfort area/have easy projects this quarter/year? I saved Joe 4 hours on Friday since he didn't have to investigate what the system does with foobars as I had the answer? That just sounds petty. ), or not directly under the developers control (revenue).
I've come to the conclusion it's folly to pursue any one companies career progression maze. Because you get corralled into all sorts of sillyness like this; vying for projects with your peers, acrimonious code reviews, chasing silly metrics, etc. I find it's much more effective in time, money and title (and work life balance, and mental health) to simply switch jobs for the higher title.
In other words don't fall for the "work your ass off for a possible future bump in pay and title" game many companies play.
Or find a good company. I've worked hard and gone from mid level (actually slightly lower) to principal over several years at the same, growing company. My responsibilities have drastically changed over time towards greater impact and my pay is nearly 3x from where I started.
I had this when I worked at a large enterprise several years ago.
If I recall correctly we had to state goals for each of 5 major categories and another set of 5 supplementary categories. The categories were things like - deliver customer value, enhance team work, collaborate well across teams and various other enterprise buzz words, I forget exactly..
As a coder, my goal was pretty much to write good code and avoid sitting through pointless meetings as much as possible (a very hard task in that place). I would basically have to spend half a day coming up with various different ways to word this so that it would fit each of the five goals.
Every six months (one mid year review, and then the final review) I would have to meet with my manager to provide evidence that I was achieving my goals. That would be another half a day twisting words around to try to fit what I had done to the goals. My manager would have to do the same for me. I was then scored on each of the goals. Then the score was totalled up and was used to determine the salary increase that I would get at the end of the year.
We all despised the system. A collective groan would go around the meeting room when it was announced that it was review time again.
My first "goal-setting" experience (five jobs and 20 years ago) was like this: upper management would define company-wide goals (that ended up being incredibly vague) and their direct reports would define their own goals that supported the company-wide goals, and their direct reports would define _their own_ goals, ad nauseum, until it finally trickled all the way down to me, the lowly programmer. So I took it seriously, read my managers goals, his manager's goals, his manager's manager's goals, all the way up the chain so I could try to define some goals of my own that a) I thought I could actually achieve and b) supported everybody else's goals. I had a lot of things like "increase unit test coverage" and "speed up build times" sort of things in there. My manager reviewed my proposed goals (remember, we were supposed to be defining our own) and rejected all of them, giving me a set of completely unachievable and meaningless goals - mostly related to the "flavor of the day" project that I was already waist-deep in. Things like "reported bugs are down 30%", "my peers consistently rate me as a solid team player" and "project fleebleflub is in production and is consistently producing $100,000/month in revenue" (I'm not kidding). Back then I was young and naive, so I argued with him that these goals were effectively impossible for me to achieve alone and he said, "well, these are 'stretch goals' and that's good". Of course, two months later project fleebleflub was cancelled, I was redirected to a troubled project with tons of bugs and my peers hated me because I was always turning away their requests for help because I was frantically trying to meet my own goals. Performance review time started to loom large and I was starting to have an existential crisis - I had printed out my goals and pinned them to the wall of my cube so I kept them in mind and I knew that I hadn't come anywhere close to achieveing any of them. I was five years out of college and starting to panic: my degree was in computer science, so programming was the only career option I had, but it was starting to look like I was terrible at this. I updated my resume the night before the performance review because I knew for sure I was going to be fired. So I went into the performance review, my manager looked over my goals, said, "well, let's see if we can get this up in the next six months" and that was it; I got a "meets expectations" and kept working there. Lather, rinse, repeat for every single song-and-dance goal-setting/performance-review exercise I've ever been through.
Sounds like that was a classic case of confusing "lag measures" with "lead measures." I'd suggest to anyone in a situation with a manager who tries to over-focus on lag measures to explicitly bring up the concept with them.
That's unfortunate (and all too common). Goals should be meaningful to you and the company and be few. Achieving them over time should feel good. And reviews should be an opportunity to show off a bit and learn where you can improve a bit.
1) While writing up the goals, you don't have a full view of the problem. Goals change, but once written down, there is a strong pressure to implement what has been written down.
2) It selects for people who are good at writing convincing design docs. Often these people write sub-optimal code and the designs only look good on paper.
Actually, the products (aside from search+ads) that come out of Google look exactly like the have been produced using this methodology; and that's not a good thing.
> people who are good at writing convincing design docs. Often these people write sub-optimal code and the designs only look good on paper.
In my experience, the ones who write good design docs are the ones who write good code.
Design doc writing is not simply overhead and marketing - it is concisely describing what and how you want to do something, and inviting feedback and other ideas.
The exercise of writing a good design doc brings you through the process, thinking of every non-trivial aspect.
It also typically only takes a day or two (or maybe a week for something more complicated) - far less time than the corresponding code takes. And if a colleague points out something that could be done better, you won't have wasted weeks or months writing the wrong code - only hours writing the wrong design. Much less costly to fix, and much easier to move on from, emotionally.
Most large companies operate this way. Its great as long as the powers that be actually action these assessments and validate confirm the assessment with other members of the team.
My experience is that the difference in raises between an employee that got an “Exceeds Expectations” and one that “Meets Expectations” isn’t significant enough to be worth wasting the time worrying about it.
The best way to make more money is to change jobs. Google may be different.
10s of thousands of dollars per year difference in bonus, stock refresh, forget about salary. From personal experience having been at both meets and exceeds as a senior engineer.
If you are at an appropriate tier company for your skill level/aptitude then you likely will have to work a lot of extra hours to be (and to be seen as) an 80th percentile performer.
You won't know if that time investment gets you anything until the end of the year. You won't even know what the bonus pool will be or if you'll even have the same manager by the end of the year.
All for an extra 10-30k a year (pre-tax)?
Your time is probably better spent building your reputation in the industry and trying to get a higher paying job.
Google is indeed different. While you might not find the delta in compensation for one performance review cycle to be worth the effort, employees with a track record of exceeding expectations can expect to come out significantly ahead of where they would be if they had only met expectations.
But working at regular non SV companies, I’ve learned just to focus on doing as well as possible while still having a sane work life balance, keeping on top of industry trends and job hopping when my salary and the market were out of whack.
Google pays such above market salaries, the strategy would be different.
At Google you are expected to exceed expectations.
But seriously, you are evaluated against the role description (software eng? product mgmt?) and your level. If you exceed expectations consistently over several review cycles, you are encouraged to apply for a promotion.
The goal is to get you promoted into a role and level where you can consistently meet expectations.
Specifically the opposite. The peter principle implies you'll make it to a point where you flounder and can't manage. This is the opposite: You make it to a position where you do well, but aren't spectacular (compared to your peers in the same position).
Roles/levels are calibrated so that expectations at L+1 are generally speaking aligned with strong performance at L.
Ah yes! It's not enough if you're great at your job, or even if you do other people's jobs...
Instead you have to have this checklist of your quarterly goals, on which you can go through with your engineering manager on biweekly 1-on-1 meetings! And of course you should make a nice spreadsheet and a confluence page documenting your progress, since we're data driven :)
Did you fix a major fuckup in some legacy component? Where are the numbers? Ah, then it's not visible enough for a promotion, here's your 1% raise instead. Do you see Paul over there? He made great progress this quarter! One of his goals was to write a blogpost each week, and guess what, he did! He's on a great growth trajectory, and well deserves his promotion.
Long story short: it's a great way to drive away your best talent while keeping the confluence page and blogpost writers.
> Did you fix a major fuckup in some legacy component?
What if that legacy component was no longer in use? Is there some bigger picture in play?
I've been at bad companies before, so I understand being cynical. But, having people just do whatever they feel like also does not work. From the outside it looks like Google has quite a bit of this, so they are clearly trying to get people on some path. The messaging app situation shows it hasn't quite worked yet (from the outside anyway).
All of life is a series of negotiations. Those who can negotiate more effectively come out ahead. This is true whether you are discussing your compensation when joining a new company or whether you are hashing out what you work on.
If your manager asks you to do something, ask them how the thing they are assigning will help advance your career. Ask the manager how -- if you deliver on what they ask -- they will go to bat for you when they are sitting in the room with their peers justifying your evaluation score. Be willing and able to simply state, "I don't know how you can expect me to spend my time and energy on something that won't help me advance my career." If your manager can't understand or respect that, then that's great! You have a clear warning sign that it's time to fire your manager.
It's OK if we lose people who don't care about contributing to the organizational goals and coordinating with teammates, who just want to mess around on whatever amuses them.
I'm telling you, fixing a serious issue in a legacy component is anything but amusing. I'd be happy writing blogposts about the current framework of the week, but if I uncover an issue while working on my regular tasks, I'm gonna try to fix it instead of sidestepping it.
We do this at a smaller scale (~1500 employees) with success. It enables everyone to work towards a goal and to discuss with their superior any issues that get in the way, as well as every success story along the way. Both are very important parts of the journey.
It's not easy to list goals from the top of my head as it's not my strong side, and especially not if they have to be measurable (which good goals should be, rather than your boss evaluating whether or not you did something), but here goes:
Goals could be "Pick up language X in order to help development on project Y" or "Get formally introduced to all R&D team leaders, and get introduced to their roadmaps" or "Facilitate 10 job interviews together with team leaders in marketing"
Thank you. I asked because in the previous company I worked for we had difficulties setting measurable goals for devs and ended up tracking only product goals.
Product can be highly variable (or uncertain) so dev goals would focus on skills necessary to achieve said product. Ideally these skills a general and transferrable.
Have you ever read a white paper? You see how they manage to say that the product will solve every problem you have and nothing specific at all? Same idea.
You essentially set arbitrary metrics for yourself (create X widgets, approve Y new hires). And then you do those things. And then you pat yourself on the back for doing those things. And then you get passed over for promotion anyway because "maybe next time". It's a way for companies to not promote you based on nits they picked with your own write-ups.
My understanding is that OKRs at Google are visible throughout the org, and coleagues are able to (and do) provide feedback on them.
Most orgs that adopt OKRs only make them visible to the person's manager, and without transparency and good feedback, the other problems mentioned here proliferate.
This is simply part of how they've implemented Jack Welch's Vitality Curve[1]. It's pretty common practice for most large companies, although I understand more and more are starting to move away from this approach. As it turns out, most people don't enjoy playing Game of Thrones with their co-workers every quarter.
OKRs are straight out of Andy Grove from Intel. If you read further along, the author indicates that getting fired from Google is very rare. So it's not a fire the bottom 10% every year.
Andy and Jack knew each other well. Where do you think Andy's strategy came from? It's the same thing as Jack's Vitality Curve, only without firing the bottom 10%.
This seems attractive for other large organizations. Any positive or negative experiences from readers?