Item — HN Reader

Now having worked in a few smaller teams since my time at FB, I realize how marvellous it is to not have to worry about OKRs, performance reviews and all that malarkey. It was so draining to run yourself as a mini PR/brand within one's team (/one's department) and market oneself (one's team) to your manager (/your company).

So much mental bandwidth was spent.

I also, from a systems-thinking POV, just fundamentally reject the value in OKRs as a meaningful proxy for the value you (/your team) are producing unless you are an entirely mechanistic function. By mechanistic I mean you have a clear discrete Input<>Output expectation. Every single time an element of human activity is reduced to a metric, you lose something, and if you do it enough times, you've effectively produced a metric that is completely distinct from the thing you intended on measuring in the first place. For example: let's say you're in the suicide prevention team at FB, and your OKR is 'number of suicides averted'. Well, that sounds good, but unbeknownst to you, perverse incentives have kicked in and invisibly imbued your metric-chasing experiments a dark undertone. A new risk model might start flagging more content as potentially suicidal to boost numbers, leading to over-intervention that could traumatize users or waste resources. Or perhaps the surface we use to measure success, a UX or user activity metric, might actually be uncorrelated with crisis aversion or... and this is where it hits: the thing that's instrumental in crises is social media itself. The metric becomes a game, and it games _you_. Your team thinks you're doing X, but you're really doing Y. Because you're disattached from the real problem and comforted by incredibly lossy proxies.

17 comments

The times I've seen OKRs and metrics used effectively, they met two criteria. (1) it was always a metric closely aligned with what customers want and which drives revenue for the company; and (2) it didn't just impose a requirement to do work, it also provided political cover for not doing other, competing work.

For example, if you're designing GPUs and/or GPU drivers? If your next-generation product has the aim of providing 25% more frames per second in "Baldur's Gate 3" and "Call of Duty 6" while maintaining the same quality - that would be a good objective for the team, as it's closely aligned with what your customers want.

And if someone should come to you and tell you there's a lot of people streaming these days, and they think you should optimise gaming FPS and h264 compression at the same time? It's a sensible request but it's also a distraction; proper goal setting will let you say "great idea, but not this quarter".

But there are a lot of fields of endeavour where it's not possible to meet these criteria - like the suicide prevention team from your example.

And then customers complain that the driver is frequently crashing and the team is well aware but won’t fix the ticket because it doesn’t help them meet OKRs.

What you really want is: - every team working to improve the customer experience - guided by leadership priorities and initiatives

"every team working to improve the customer experience - guided by leadership priorities and initiatives"

The fundamental issue is that in almost all larger companies, upper management does not trust that their employees are either intrinsically motivated to do a good job, or are smart enough to determine what "a good job" is.

So rather than having a chain of trust from upper management to middle management to individual contributors, they seek to create a measurable control system. This inevitably replaces people's intrinsic motivation to do a good job with an extrinsic motivation, which only poorly represents the company's actual goals. At this point, most people are no longer trying to do a good job, they're instead trying to make their numbers look good.

Upper management has effectively replaced real, meaningful work with a game where everybody tries to score points, and the people who don't participate in that game are eventually stackranked out of the company.

Something I appreciate about small workplaces is that, often, people have a shared sense of the purpose of the organization and strong teamwork.

It manifests in little things. We were waiting outside the conference room last week for our manager to get the keys to unlock it. Nobody told me to, I wasn't responsible for snacks, but I picked up the trays of pastries and brought them in and put them in the right place and joked "It's my New Years resolution to squat anything I can get my arms around." I got thanked.

In startups you often have to get things done quicker than you can hire new people to do it. A lot of people have the attitude that they have a certain circle of responsibility, which is necessary and appropriate in a large organization, but in a small organization I like it that people have internalized the goals of the organization and are willing and able to pinch hit.

I think people often get this attitude working in small businesses, like a little shop that sells knick-nacks at the beach or the summer that I got re-hired at a supermarket that owed me a favor despite not really hiring at the time. I worked about 50% at the front end and the other 50% doing odd jobs directly under the store manager which meant they'd have me paint a metal line that ran around the outer wall of the store or sub for people in the deli (learn to work the meat slicer) or bakery, etc.

In a big organization you need some rigidity, but big organizations can also be seen as a collection of small organization (e.g. "employees don't leave companies, employees leave managers")

It's a pet peeve of mine when people in a startup don't have a flexible attitude.

>And then customers complain that the driver is frequently crashing and the team is well aware but won’t fix the ticket because it doesn’t help them meet OKRs.

You highlight the danger of goal setting - where the goal becomes an end onto itself. I disagree with your adjustment however. It's too vague as written, and if you attach KRs to it, you'll end up where you started (with a KR like 'improve fps performance of game X by 25%')

Ideally, you fix the issue, but you track it as having impact on achieving the OKR. Achieving OKRs should not be seen as a "be-all and end-all" ... Failing an OKR should be seen as a opportunity for improvement. If the corporation sets a goal of improving game FPS performance but is unable to meet it because of technical debt, that is good information that needs to be managed.

> And then customers complain that the driver is frequently crashing and the team is well aware but won’t fix

I slipped in the catch-all phrase "while maintaining the same quality" for exactly this reason :)

> What you really want is: - every team working to improve the customer experience - guided by leadership priorities and initiatives

What I'm saying is, in some types of organisation the goal-setting process can be how you express the leadership priorities and initiatives

> the team is well aware but won’t fix the ticket because it doesn’t help them meet OKRs.

Oh, someone will fix it. But it won't be the glamorous team that does the "lead" development. It will be a less desirable team that is relegated to "maintenance coding" and is paid substantially less than the premier team that created the big and got the bonus

"KR #3: the amount of bugs reported by users must not increase from our baseline"

Solved :)

> it was always a metric closely aligned with what customers want

But this is such a good example of why these hard metrics are terrible.

You actually probably don't want just 25% more, you probably want 30hz or 60hz or VRR support and you don't care about going from 92 to 118. The easy metric doesn't necessarily correlate to user desire.

And like you mention, it disincentivizes reprioritizing with changing user desires simply because you didn't predict it or could come up with some other better metrics for something else.

It's opposite of being agile but of course you see the same company claim they do both.

> You actually probably don't want just 25% more, you probably want 30hz or 60hz or VRR support and you don't care about going from 92 to 118.

Then someone probably ought to tell the GPU review industry, because for the past 20+ years FPS on current popular games has been a key focus of their reporting :)

I count 462 mentions of fps in https://www.tomshardware.com/reviews/gpu-hierarchy,4388.html

> from 92 to 118

Or maybe yes; 120 Hz gaming monitors are a thing, and give some advantage. You probably want to target something like Doom Eternal, not BG3 though.

As you see, it all depends on who is your customer, and then what matters to your customer. This is the closest proxy to the company's bottom line, and usually is not as fickle.

In my job we have metrics, but they are not mandated to employees. There are no targets and stuff like that, they are just there if you want to know. Managers track it and try to optimize for it, but nobody bonuses or employment is on the line over them. Maybe some sales people have commission, but most of the customer acquisition is organic anyway.

Funnily enough we have a weird situation right now, where we want to optimize the _cheaper_ plan of our product, meaning moving people from the more expensive plans to the cheaper one. It is a weird dynamic, but due to licensing our cheaper plan is actually far more profitable than the more expensive plans. Most clients wouldn't really miss anything from the more expensive plan.

It is one of those rare situations where convincing people to switch to the cheaper plan aligns with what is best for the consumer.

100% agree. There is a basic level of honesty required for this to work, which seems to have gone missing due to the "evolution" of corporate culture and the cash-rich environment which made actual productivity a secondary concern.

> For example, if you're designing GPUs and/or GPU drivers? If your next-generation product has the aim of providing 25% more frames per second in "Baldur's Gate 3" and "Call of Duty 6" while maintaining the same quality - that would be a good objective for the team, as it's closely aligned with what your customers want.

I can get selection of particular gaming titles, but how do you come up with 25% goal? How is this closely aligned? Your users tell you they want ~30% gains?

This seems to be completely ignoring a constant feedback loop between general aspirations for the product, operated timeframes, and conclusions from ongoing engineering R&D.

> a metric closely aligned with what customers want and which drives revenue for the company

My experience says these two things are often mutually exclusive.

This is the crux of what's wrong with the original article IMO. Key results that are customer centric as opposed to "ship {thing}" help keep teams focused on the thing that actually matters.

Of course there will be a tendency to try to game the metric, but the flip side of having customer centric goals is teams become feature factories, building idea after idea without constantly evaluating "are the things we're shipping driving the change in customer behavior they're intended to drive".

That's a product OKR, not a personal OKR.

Yes, product OKRs can work, as long as you listen enough to feedback. In fact, you probably can't ever creating anything good without them. But I don't think most people even call them "OKR".

I'm experiencing large company culture for the first time after being in small startups. What I object to the most, is the competition between engineers created from the goal setting and performance reviews. At startups, I had a domain that I could own. Now, at largco, everyone tries to take over my area in an effort to build their resumes. I used to view fellow engineers as teammates, now I see them as my competition.

Interesting take.

I believe there is some truth to what you're saying. My experience was slightly different where all the devs were working together, nobody "owned" an entire domain. Mainly because if a dev left, we needed to have someone else on the team capable of picking that up and move forward without everything falling apart because we had a chokepoint on something because one dev held all the keys to it.

But it was the same thing, the sense of everybody working for a common goal, and devs never judging each other. We found ways we complimented each other in order to be more efficient. There were times when you really did feel your worth as a dev and all those sort of romantic ideas of what being a dev was? And there you were, living it every day and being super proud of working shoulder to shoulder with some very talented people who saw you just as talented as they were.

Big Corp? 100% spot on with your observation. Its a fucking shark tank and at times, I felt like I was in a mosh pit. fighting off other devs, over zealous project managers trying to get me to do stuff that would make them look good, directors who constantly cut corners to make themselves look better at the cost of your bonus and promotions. Add in the abnormal turn over and feeling like I never had any stability on any of the teams I was on, I just never felt like I fit in anywhere. It was very high school stuff I didn't want to deal with.

Funny in a startup I value people being pinch hitters. Sure you should have your domain but if there is some exceptional event I want somebody to be able to cover for you or for you to do some job that wasn't even on the roster yesterday.

The key to largeco success is to understand that when you own a certain area, especially if it's an area that will generate opinions or a visibility boost, you will need to manage your full stack, not just the code you write. Code access, PR acceptability requirements, roadmap, triaged backlog, and communication upwards, downwards, and sideways.

If you're not doing that work, either someone else is going to do it or it'll cause issues down the road. Look at it this way: you can either be grateful that so many folks are wanting to help you in your effort and coordinate that effort, or you can stick to the code and complain that someone else is trying to steal your credit.

All of this hinges entirely on your direct manager (and to an extent their manager) being an actually good manager, and not a microcontroller, pass-the-buck-er, or an empty chair.

It's not a startup vs large company problem but a DNA/company culture thing. I've been at 50 person startups that implemented okrs like Meta or Google.

I feel the same way. There’s a shift that happens at around 80 people where not everyone rows in the same direction. Incentives become different because not everyone “lives and dies” together or by the same metric. By the time you are at bigco status, this is so ingrained that work becomes repeated prisoner’s dilemma trials.

You got into a good large company. In huge old companies (e.g. gov) there's often the opposite problem -- no one wants to take anything. They know that if they do something at least once -- it becomes their problem forever. With some amount of job security fiefdoms of course.

I have semi-humorously dropped a comment defining Goodhart's law.

The problem you are describing is nothing else but Goodhart's law in action: A measure stops being a good measure, i.e. be a proxy for something, once there are objectives attached to it. In other words, attaching goals to a metric invalidates previous causal relationship.

That's neither bad, not good. It's a property of goal setting. The problematic part is still treating the measure as if it had causal relationship to something when that relationship has already been invalidated. In your example, number of suicides ceases to be comparable between pre and post OKR timeframes, however if you look closely, this particular goal is based on a metric the underlying OKR targets invalidate.

Yes, sometimes you get these weird tautologies where you have to change the whole framework/process to make something both targetable and measurable simultaneously, potentially losing comparability to past data.

As a team within a larger company, your purpose is to contribute to the larger goals. How do you know if you are doing that? As this "suicide prevention team", how do you know if you are doing a good job?

I agree with you that proxy metrics easily distract you into doing Y instead of X. My opinion is that you need to iterate on your metrics then. Not having metrics means it all depends on the gut feeling of executives.

It surely is draining to be clear about your goals. I fear we cannot really be politically correct and sufficiently honest even. What is the real goal of having a suicide prevention team? It might be token effort after some incident, then the actual goal would be to as cheap as possible while still maintaining the illusion. It might be to prevent future PR disasters, then collection helpful evidence for lawyers should be part of the job. This touches hard ethical questions and these should become evident when discussing the purpose of a team.

> How do you know if you are doing that?

You don't, as an individual "unit", which is part of the problem, i.e. modern management's focus in trying to split teams/big companies down to its "elementary" unit, the employee.

> Not having metrics means it all depends on the gut feeling of executives.

And that's why you need good executives, executives who have good guts. You cannot automate your way into being successful, at the end of it all running a company is still pretty much a social endeavour, one that cannot be partitioned down to individual units, neither can its success or failure be explained by those individual units alone.

> Not having metrics means it all depends on the gut feeling of executives.

Having spent a couple of decades in enterprise I can say that in my anecdotal experience it does so anyway. I've rarely seen any form of metrics put to good long term use. That's not to say that it doesn't happen, but benefit relaization seems to be something very few managers and teams actually work with beyond hitting some metric. It's usually the most obvious with changes in management. I've seen hordes of measurements thrown in the bin when a new manager took over a team and had different goals and values. On the flip side there are a lot of negative side effects of metrics over time. If you measure employees by the hour you create a culture of people who won't help each-other because how do they registrer that?

I mainly view productivity measurements as a HR tool for managers who don't actually know what their team members are doing. Which can happen for a lot of reasons, sometimes it can be because the manager is simply bad at people management, often it's because they are too busy. What is especially bad about them, however, is that people aren't consistently productive and what you really want to work with is how to keep them motivated. A motivated great employee can be unproductive in a period where they have small children, a loved one is sick and so on and an unmotivated employee can be very productive while simentaniously looking to leave your comapny.

I get why these tools exist though. Most managers are weak decision makers and HR supply them with tools that help them over come this.

I worked on the Suicide and Self Injury team at Facebook.

It was multi faceted, and whilst out of the door escalations (to emergency services) is one metric, it was a guardrail - i.e., if it went down it's likely something was wrong, not because "yay we solved suicide!".

The more difficult thing is that sometimes it's not possible to develop a metric to properly capture "decreased risk of harm", and so proxy metrics have to be employed.

You have invoked Goodhart's Law. The problem is, of course, that most managers are not good at their task of evaluating talent, proving the worth of their services, etc. and try to take the easiest way out of it. Sometimes this means outsourcing the job to you or picking a poor thing to measure.

> you've effectively produced a metric that is completely distinct from the thing you intended on measuring in the first place

Basically Goodhart’s law https://en.m.wikipedia.org/wiki/Goodhart%27s_law

> It was so draining to run yourself as a mini PR/brand within one's team (/one's department) and market oneself (one's team) to your manager (/your company).

Counter point. This is always inevitably a thing. They were only making the implicit explicit.

Yes but this being made into a formal process and having to regularly interact with that process is what's so draining.

Not having to deal with this is one of the positives about working in a small startup versus a long-established large corporate.

In big teams you are right it almost is inevitable.

It is not in small (say below 5 people) teams/ organisations. At least not in the ones I worked in.

No, not to the extent that it was and is the case at FB. I think people who haven't worked at FB don't quite understand the degree to which PSC culture pervades the company. It's absolutely more intense than Google, Apple or Microsoft, though I'm not as sure about Amazon. Valve seems differently intense in a way that I think is a negative overall.

A bit pithy, but: The goal of most enterprises is to build useful goods and services for its customers. The goal of Meta is to evaluate its employees.

Safari’s idiotic AI has decided that every time I want to go to youtube, I actually want to go to a specific clip of peppa pig failing to learn how to whistle

Google’s idiotic AI has decided that the clip of peppa pig failing to whistle depicts suicidal ideation, and so every time I visit the clip I get a big dramatic black rectangle and a therapyspeak question “Am I an adult who is prepared to view a depiction of suicide.” It took me embarassingly long to notice that this nessage, repeated constantly enough, was actually affecting my mood.

Your scenario is generous in assuming that the suicide prevention FAANGers who coded up this situation are intelligently following bad incentives. I think its more likely that their intelligence is just found lacking, when unfairly compared to the galaxy brain needed to actually guess the consequences of our actions at this scale.

> For example: let's say you're in the suicide prevention team at FB, and your OKR is 'number of suicides averted'

That sounds like the sort of old-school KPIs that OKRs were meant to replace. I don't know if it's just impossible to measure anything, and you should just rely on a managers' word for how any team is doing, or if the people who did KPIs are now infecting OKRs.

They've always been closely related. The "KR" in OKR is "what is the new target for the KPI in order to reach O?"

The challenge is we don’t have an alternative, at a small company your performance boils down to “does the ceo want to fire you?”. The extent to which the ceo does not want to fire you depends on the reasonableness of that CEO, as well as how much the CEO cares.

In an established small/medium business with flat growth, it’s entirely possible that no one cares to fire anyone, sits also possible the CEO expects everyone to work nights and weekends while being a top competitive coder.

One of the biggest culture shocks I had during my time at FB was when we were doing Mononoke, this completely greenfield project with a ton of unknowns (first big Rust project!), and we got a new skip level who was previously on the web performance team (super narrow and directed).

When I was at fb, I had the curse of being given an extremely vague goal as a new hire. Unfortunately, it was quite difficult to establish meaningful metrics AND hit them in a half! Like you said, I spent way more time on my self review than I wanted...

> I realize how marvellous it is to not have to worry about OKRs, performance reviews and all that malarkey

Where are these malarkey-free companies? I've worked at several small companies and they all had all kinds of malarkey.

The FB suicide risk detector OKR is an interesting example. It’d make a great business school / psychology case study.

We measure something because we need something to measure even if it is divorced from reality.

> Every single time an element of human activity is reduced to a metric, you lose something

Also, metrics eventually become the goal and are gamified.

At FB would the 'boots on the ground' devs be required to do OKRs? Or were they done at the team or manager level?

I did not do any OKRs on an infrastructure team. Qualitative results were just as valued, and we had the quantitative knobs to dial when needed thanks to excellent internal tooling and service maturity.

I found it to be the ironic part of working at one of the most data-driven companies. We didn’t do OKRs in my org despite using data to drive decisions. I much prefer this to OKR hell.

It depends substantially based on which org you are in. But generally it is at the team level, so it would mostly be on the EM/TL/senior eng on the team.

I think Laozi and Zhuangzi had something to say about this.