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.
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.
A less cynical take is that communicating consistently the priorities and tradeoffs the company wants to make as they get larger is a hopeful use of OKRs.
In small teams/companies “the right thing” can be obvious and the team can operate in a shared headspace with low cycle time to discuss and decide tradeoffs when they arise. This gets really problematic at scale.
Now back to the cynicism — it’s also tricky when you want to hide the ball and make teams feel ok about doing bad things: make time spent go up is the goal, who cares if there’s addiction along the way.
I just fundamentally don't believe that most people in most companies have an understanding of the company's priorities that is worse than what an OKR encodes. In fact, my experience is that most people in larger companies believe, and are correct in believing, that they are forced to intentionally make worse decisions because better decisions have negative impacts on their measured performance.
I've been part of an extremely effective 200 people company that got acquired by a 4000 people company. We all understood why we were acquired, we built a platform that solved a fundamental problem the larger company had.
After the acquisition, this larger company's OKR and measurement system was implemented for our teams.
We initially all ignored the system and went on as usual, starting to implement our platform. Initially, things went well, we made steady progress and started migrating legacy projects to out platform.
Then, the annual stack ranking firings happened. Some of our best engineers were fired. Seeing this, many other top performers started looking for jobs immediately. The ones that got hired elsewhere started poaching even more top performers. The ones left started playing the numbers game to avoid being fired.
Within a year, most people went from trying to solve the larger company's problem to optimizing their numbers. Within another year, the platform initiative had completely failed and was abandoned, with most of the remaining people being fired or integrated into other teams.
that was the end result the company wanted. they bought out a competition and didnt intend to mometize it. so the engineers working on improving the acquisition were doing the opposit of what the buying company wanted
“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.”
That’s what i have concluded a long time ago. Upper management has a deep distrust of their employees and acts accordingly. They will hire consultants or external people before they will listen to their employees. I think part of it is that a lot of them don’t really believe in anything themselves and only blindly try to fulfill goals set by their CEO or board of directors.
Consultants also provide political cover if things go sideways. Conversely, if the consultants operate well, the executive sponsor might be promoted and thus there is value delivered. But really the question is, "Are you working someplace where there is a culture of promoting from within?"
Ideally management is working with IC teams to set good Key Results. Management shares context of what's important (objectives) and IC teams propose good quantitative measures (key results) of how they'll achieve it.
Yes, “ideally”. I have never seen meaningful numbers as targets. Sometimes it works for a short term effort but in most cases you have ten different measures tha5 are important
For some reason, this is a controversial idea but: it's hard to argue that multiple layers of management can become anything other than bureaucracy.
Corporations reward an individuals tenure and experience with increased decision making (often, this means manager title). That increase in decision making means that less senior IC's become less autonomous, even when they inevitably exceed their superior's experience on the topic.
The level of autonomy is at odds with the number of managers. Some people argue this is a good thing. I argue that those people are just managers justifying their jobs.
I've been at hugely decentralized companies (several thousand engineers, one level of management between me as team lead and the actual executives). Each team was fully empowered to solve their problems in the best manner and they went off and did it. It had downsides. In particular, teams often encountered similar problems, and each team solved that problem differently. There was no one in a position to see that Team A and Team D were both solving problem theta, and that Team D's solution was better, and Team A should just use Team D's (or, more often, that we needed to detail an engineer to solve problem theta fully and get both teams to use that full solution rather than the jury-rig that each team had built). There was also no one to keep us informed that Team Ssang-giyeok had already solved the issue months ago and we could just use their solution.
Internal communications like that are a scale problem: in a small company, the matrix of personal relationships is basically full, but as companies get larger, the matrix gets sparser and sparser. By the time you have a 100,000 employees in time zones all over the world your matrix is almost all 0's with only occasional 1s. And so information will travel quite poorly without people whose explicit tasks are to convey information to the right people. That's what managers and internal bureaucracy are supposed to do. Sometimes that information is "we need to build this and not that," sometimes it's "employee 24601 is great and should be given more responsibility," sometimes it's "this project is a Kafkaesque nightmare of un-ending pain that will never be delivered as scoped." But identifying this information and sharing it with the correct other people- that's what middle-management is supposed to do.
Believe me, I am not generally a fan of bureaucracy (as I type this I'm supposed to be fixing a problem that is somewhere in the interface between my 100k employee company and another 100k+ employee company, and it's goddamn terrible), but it does have value beyond just fief-building.
> In particular, teams often encountered similar problems, and each team solved that problem differently. There was no one in a position to see that Team A and Team D were both solving problem theta, and that Team D's solution was better, and Team A should just use Team D's (or, more often, that we needed to detail an engineer to solve problem theta fully and get both teams to use that full solution rather than the jury-rig that each team had built). There was also no one to keep us informed that Team Ssang-giyeok had already solved the issue months ago and we could just use their solution.
Convince me that this duplication of work is worse when you have to shoehorn solution X into solving problem theta poorly, because someone 2 degrees (or more) removed from the problem thought that problem iota (which X actually solves) was "basically the same thing" as problem theta.
The interesting thing is that we have solved this. Groups of people much larger than single corporations work together effectively using systems like GitHub, Wikipedia, or npm, without overloading the social graph. I don't know why companies don't use similar systems internally — although I'm sure some do, but perhaps they don't advertise it, because it's a huge competitive advantage.
The modal OSS project is a one man band, or at most 2-3 people involved. By the time you get to something large scale there is also quite a bit of bureaucracy there too. Look at something like, to pick something mostly at random, a single project of the Linux Foundation, KernelCI, devoted to building CI for the Linux Kernel. And that has a Technical Steering Committee, ad hoc working groups, differentiation of responsibilities, etc. It has, for all practical purposes, just the sorts of middle management that I'm talking about.
I don't really think we have. There are many open source projects that duplicate work for a variety of reasons. Perfectly fine for stuff you want to do, but probably not an optimal allocation of resources
> 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.
This. Got managed out of a previous employer as I didn't want to participate in the numbers game by focusing on the customer.
If you are senior enough, you can get away with it for a long time. Customers liked me, account managers too (as their customers increased spending), and my manager (at the director level) had my back. That was all good until the day they put another management layer between the director and me...
i worked at a FAANG co and managed to make it 3 years focusing on solving problems that widely bothered users. there were several instances where i had to -fight- to ship critical bug fixes because the fixes so-happened to regress an obscure metric someone was baby-sitting…
the first time this happened, i felt like my brain was going to explode -- so wait, you want me to leave the main app feed broken and people pissed off because the comment-notes-experience-home-ex team's weekly comment rate is slightly regressing?
writing this out, not sure how i lasted as long as i did.
This reminds me of when we introduced Yammer at a company. Initially, it worked great, everybody loved it, it was super valuable to share information internally. Then, at some point, the feed broke and it somehow started demoting the most valuable posts, requiring much more time to be sure that you had caught up on everything relevant to you.
Then I read an interview with the CEO where he bragged how they were data-driven and were optimizing for engagement. My guess is that somebody had figured out that hiding important information created more "engagement" because people now had to spend more time searching for the stuff that was relevant to them.
This person probably got a promotion, and we switched to a different system half a year later.
Yes, exactly -- the fixation on "metrics-driven development" created perverse incentives (i.e. cobra effect). People would ship bugs and broken shit because it'd bump engagement, like you're referencing; nevermind the fact that the engagement win was because people were clearly flummoxed by a meaningfully worse user experience and it took them longer to do shit. I saw this happen many times, gaming metrics by doing backwards things would definitely get rewarded.
Although what happened was slightly different. I was a developer. Came in fresh faced and worked my ass off. Took on additional work, went to copious amounts of conferences, networked outside of team constantly, always finished my Sprint work ahead of time. Did everything a high performing dev would do. On a scale of 1-5, I was ranked a 3 (meeting expectations), barely any bonus, barely any salary increase.
I was like, "WTF?!?!" and was naturally pretty pissed. Next year? Barely did anything. Came into the office for morning standup, left, worked from home rest of the day. I constantly took afternoons off, Still got work done on time, did the absolute minimal amount of work. I was "silently quitting" before anybody ever coined the phrase. Next years review? Yeap, you guessed it, another 3.
That pretty much confirmed to me that nothing was ever going to change if I was working my ass off or just doing the absolute minimal amount of work. This lasted another two years before they finally offshored my team and I left the company with several great references.
It was a great lesson to learn that its just a game, and you either do everything to stand out which has a high mental and emotional cost, or you simply refuse to play the game, retain your sanity, and look at your job as simply a means to an end as opposed to a satisfying career.
$400 a tonne CO2 tax ($4 on a gallon of gas) is enough to modify behavior and encourage real CCS. This could be rebated to consumers (everybody gets a $6500 check a year) to make it revenue neutral. Two problems:
(1) A legitimacy gap. People think taxation is on ratchet and wouldn't trust it to be revenue neutral and not a money grab.
(2) It's a global problem. If there is a carbon tax in the US and no carbon tax in China that's unfair for our manufacturers. People will complain about the fairness of any particular rebating scheme inside the US, but there will always be much worse complaints about a system which embraces all nations from Luxembourg to Burundi.
For #2, most proposals I’ve seen aim to put domestic products on a level playing field with products from countries without an equivalent tax with a “border adjustment”, a sort of tariff that’s based on the carbon intensity of the product (with a pessimistic estimate if they don’t know). This has the side effect of encouraging other countries to adopt similar carbon taxes.
The EU is implementing something like that, and we’re seeing an uptick in appetite in the US to implement a border adjustment here, partly as a result, there were a few bills put forward in the last Congress, though nothing has gotten very far yet.
you forgot (3) an efficiency gap. No government or quasi-governmental organization can deliver this program without massive leakage. Look at Canada: carbon taxes go into general revenues, and some portion of it gets paid out of general revenues. It also doesn't matter if the payment is a redistribution or an ad buy for a terrible commercial on the CBC - it's all fighting climate change!
It's better if the tax revenue goes back into fighting climate change but the point of a carbon tax is to punish bad behavior. Just by implementing the tax you're fighting the problem (in a small way).
You'd wish instead of "seeing like a state" organizations would learn to "see like a consumer" and be able to recognize that a terrible commercial is a terrible commercial!
I think the efficiency gap is less than with other approaches. Rather than privileging electric cars we should reward people the same if they save carbon by buying an electric car or riding a bike or if an industrial process is replaced by one that is naturally carbon free or if you take the carbon out of the stack or if you take it out of the atmosphere. The market should decide what is the most efficient.
(Note another 'efficiency' concern people have is that you don't want to pay people $400/ton to store carbon from fermentation at an ethanol plant that is unusually cheap at $40/ton because you get nitrogen-free CO2. People seem to have a moral problem with that, first fundamentally, second because the ethanol plant is problematic in other ways)
Besides the tariff on imported products the sibling talks about, you can also rebate the tax paid on exported products.
It's not simple to manage those adjustments, but governments deal with much more complex taxes everywhere. It's not a big deal.
And yeah, the UBI cancellation of the tax, the tariffs on imported products and the rebate on exported products deal with every single problem I've seen people post about a carbon tax, except for "expensive gasoline will destroy our economy!", that is almost always pushed by people that live in a place with some of the cheapest gasoline prices of the world.
There is an add-on that some people push where you don't cancel all of the tax in an UBI, but use a part of it to finance carbon capture projects. I do really like this one, but it's not something that is required for things to work.
Intrinsic motivation is great, it's a powerful force and can enable amazing accomplishments. But it's not something that management can necessarily rely upon. Sometimes there's shitty work that just has to get done for legal compliance or to meet customer demands or whatever, and to make that happen management needs a control system to create extrinsic motivation. In any large organization it's not possible to have everyone doing interesting, meaningful work.
I've never seen that actually be a problem when people were motivated and empowered to make decisions on their own. In my experience, people by and large don't mind doing boring work if they feel that it is necessary or valuable.
I worked at a small company when GDPR was introduced, and people volunteered to read up on it, and work with an external lawyer to write specs on what we had to do, because they knew that it had to be done and wanted the company to succeed.
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.
100% and people in startups tend to have more of an ownership approach vs "not my job, nor in my job description" attitude. Not suggesting here that options are the answer, just echoing my experience in the small workplace vs large.
>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.
This only happens if people are evaluated based on OKRs, which is not what this tool was originally about. High Output Management, as far as I can remember, says that such a tool must be used solely for communication, i.e. to avoid having people ask the same questions over and over again (and to enable descentralized decision making).
Exactly. So a productive employee is one who identifies a problem and knows which of the following to do:
- fix it themselves without anyone asking
- bring it up to higher management
- deprioritize it based on severity and leadership initiatives
This is the pattern taught by Jethro to Moses in the Old Testament:
every great matter they shall bring unto thee, but every small matter they shall judge: so shall it be easier for thyself, and they shall bear the burden with thee.
But it can’t function any other way. You are a filter of small problems for everyone in the org higher than you. If you bring up everything up the chain your level may as well not exist.
There are many places out there where individual contributors are agency-less executors.
I don't think it ever worked. (Remember when Japan destroyed the world's car industry just by changing that single thing? And that's industry work, highly repetitive and formalized.) But that never stopped managers from doing something.
What I find odd, is often the biggest proponents of the free market - with it's decentralised decision making process ( and redundancy of effort ), decide that total centralized, top down control is the best way to run their own company - as they think top down decisions and minimising waste through duplication is the way to go.
That's a slightly different angle - if I understand correctly it's about why firms exist at all - and if I were to summarise it's because lack of trust costs - a firms boundaries are created to balance transactional costs ( within the firm it's low, between firms or individuals it can dominate ) versus the costs of perhaps not being market efficient.
My argument above is about not what shapes a firm's boundary but how it operates internally - too much top down control potentially risks exacerbating the risks associated with being a company and also potentially increases internal transactional costs as well - worse of both worlds! - all that ceremony around decision making, time spent justifying existences, inability to just act.
Obviously as I said above - it's a balance - just as it is with country/international systems.
> In a “free market” you can choose what firms you work for and with, except the government.
Eh? Nobody ever leaves one country for another?
> The government would be more efficient in an autocratic leadership. But government efficiency is not the societies efficiency and well being
I think the free market proponents would say otherwise - one key problem is the myth of perfect information - you are imagining it's possible to concentrate all the required information to make any correct decision into a very small group of people at the top ( and assuming these people are competent and not corrupt). One of the ideas behind why distributed markets work is the information about what is needed is communicated by the mechanisms of the market itself.
And to bring it back to the original post - does the CEO have all the information required to direct others to meet the customers need across all areas - or is it better to use the collective intelligence of the entire organisation?
> 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
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 :)
You misunderstand. There are thresholds where FPS produces visible results and there is diminishing returns after 60fps as most displays cannot do more than that.
When you make a game you'd want to hit those thresholds for as many users as possible. When you're reviewing cards all you can do is give a sampling of the landscape to get a rough sense of how the card would do in any given game.
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.
Yes, it gives some advantage. The point is that its not a binary metric to hit 25% exactly, nor is it some linear correlation.
As stated its also likely not possible. Even a free 10% improvement across the board would be massive. Imagine only getting 20% more perf out of a driver and yet the bonus is marked as below target.
The numbers were picked because they were easy to pick, not because they were deeply thought through and that happens all the time with these OKRs. That's why they're dangerous.
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.
As a manager you should have metrics because then you know if you tweak the process correctly. Not sharing it with employees and definitely not making any bonuses or pay increases depending on metrics. Because then employees will game your metrics and they will be useless.
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.
In organisations that do this kind of work, the 'marketing' department isn't just about placing adverts and writing blog posts. They also have people whose job is to keep track of what's going on in the market, and to estimate what your product needs in order to be competitive when it comes out.
To take a simple example, the marketing team might have visited https://www.tomshardware.com/reviews/amd-radeon-rx-7900-xtx-... and found on 4K ultra settings that the "RX 7900 XTX" shows up as 90.3 fps average and the "RTX 4090" shows up as 112.6 fps average. And 112.6÷90.3 = 1.246 so if AMD want their next-gen flagship to outperform nvidia's current-gen flagship, they need 24.6% more FPS.
Of course it's a lot more complicated than that in practice. They'd also consider value-for-money, non-flagship cards, whether users' monitors even support >120fps, guessing at what nvidia's next flagship will offer, interviewing big buyers like Dell, and so on. But that's the general gist of it.
I've never understood that sort of target - managers at McDonald's had them when I flipped burgers through uni, and they would just pull some numbers out of somewhere and get very excited about them. then they would nag customers until they hit those numbers, presumably.
I was a Linux zealot in the 1990s. I had a conversation with a friend from college who was developing solutions based on Windows in Arizona who told me that he loved Microsoft because Windows was a platform that made people like him rich.
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".
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.
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.
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.
"All of this hinges entirely on your direct manager (and to an extent their manager) being an actually good manager" I've found this to be a pretty tall ask at most companies. IMO If companies got rid of most of the performance and goal setting, most lower level managers could just convert to project management and teams would be a lot more effective.
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.
True. I guess what I mean is that other engineers try to take over the architecture and design. For instance, I had a fellow engineer without even talking with me, create a 2.0 vision doc for part of the system that I had designed and was mainly responsible for. This was clearly an attempt by them, to raise their status and influence.
I feel this pretty hard. You almost have to do your own 2.0 vision doc for things to make sure your name is on it in order to preempt the opportunists and influence pirates, but that can lead to you being seen as "hogging all the good work" and turning into the common adversary.
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.
80-100: my theory is as humans who lived hundreds of thousands of years in small hunter-gathering groups, there is a natural limit to interpersonal relationships we can manage on one-on-one level.
Any levels of social complexities beyond that has to rely on systems/traditions rather than direct interpersonal relationships.
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.
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 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.
> 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 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.
Higher ups love to be "a data guy"! Just reduce all their responsibilities into a few numbers so they don't have to really understand what's going on underneath them. Have you notice how in love they are with their "progress dashboards"? They love to kick back and put their legs on the office desk watching minions making "progress" on OKRs so they can report that to their manager. It's too much work to really understand things and be on top of them anyways...
The other way that being a numbers guy lets managers be lazy is that they will tell their data scientists to “do an analysis” so they can say that their product decisions are empirical and data driven rather than relying on any obvious design/product sense.
If they can point to a number from a really poorly/quickly done ad hoc study, they’ll never worry about being told they made the wrong decision
This has always been my beef with OKRs in the software industry. Most shops are at least pretending to be agile-ish. And this means that a random IC dev is pulling tickets from the backlog and doing them.
They're not going to be personally responsible for "improving the response time of the FizzBuzz server by 22.3%" or anything like that. No - the product manager tells the team on what they'll be working, the work gets broken down into parts, and they take what's available when they come up for air.
OKRs should never be handled at a level more granular than a scrum team, or equivalent.
It's exceptionally hard to find good executives due to nepotism and other problems with hiring them that result in the wrong people in charge of the wrong thing more frequently than not, though.
So we need metrics., lest we get swept away in the Trickle-down Incompetence.
Yeah, I agree that it's a very difficult problem to solve and that getting the balance right between using metrics and having access to good "guts" is essential in a company's forward success, but that's the state of affairs we are in right now, for better or worse.
I also think that the companies that matter getting bigger and bigger, with no actual failure on the horizon (such as bankruptcy) in case of strategically wrong decisions doesn't help things one bit, because in those cases management failure is in many cases rewarded as there's no immediate and adverse affect on the life of the company itself. We need some return to creative destruction, otherwise we'll be left re-arranging the chairs on the deck of the Titanic (I see this type of discussion on this particular subject as part of that metaphorical re-arrangement) until the proverbial iceberg will strike.
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.
> 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.
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.
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 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 remember reading an anecdote about this stuff from the book The Essential Deming by W. Edwards Deming the "father of the quality movement and was hugely influential in post-WWII Japan".
It talked about some company moving oil around in barges, the setup was unprofitable and a new manager was brought up to fix it. He created metrics of the business, but didn't put any goals or goalposts for the barge crews and other managers in the company.
All he did was simply print the metrics and glue them on every barge of the fleet weekly. Soon the whole project was massively profitable. Apparently the captains of the barges would compete with each other to see who could save more money, without any penalties for the low performing nor any rewards for the high performing barges.
One thing that was very surprising is that the barges were given freedom to choose where to source materials and, more importantly, the fuel. Before the metrics the captains would pick whatever was closest no matter the prices, after the metrics the captains would, on their own, try to source fuel from the cheapest place that they could. No amount of central planning could have been as optimal as the prices fluctuated a lot from day to day, so whenever a captain saw a good deal he would re-fuel.
It turns out that empowered people want to do a good job and want to save money.
The barge company in question is Koch Industries (yes, that Koch Industries). Starting in 1982 they leveraged Deming’s ideas, realized 30% profits, and pushed it far enough to enter the dark side.
> Koch’s dedication to Deming’s ideas eventually led the company into several sticky situations, not the least being targeted in a Senate Select Committee investigation for oil theft in 1988, a direct result of immense internal pressure on employees as part of its continuous improvement program.
[1]
This is powerful stuff. When you empower people and set a goal, they will do anything it takes to hit that goal, including breaking the law.
Half of the point of Deming's books is that you should not set goals. Measure yes, but not goals. Especially not tied to incentives like bonuses or promotions.
> It turns out that empowered people want to do a good job and want to save money.
You have to be careful here. In your example those captains didn’t really care about their job they cared about getting the high score. Metrics, KPIs, etc work but only when they’re setup perfectly aligned with your actual business goals. Measure/score the wrong thing and you’ll get nowhere.
For example, what if the metric posted was distance traveled by a barge. You’d have captains taking the longest routes possible just to get the high score instead of shipping the most product per unit time which is what the manager would have intended.
And Deming has a ton to say on this. Lots of very practical advice on how to measure the right things, yet also avoiding relying too much on measurements. It is unfortunately quite complex and not easily digestible as pop management advice.
I think business people understand the value of setting high level goals and giving autonomy to accomplish them.
It’s a good sign if your job works this way. Unfortunately this tends to mostly be applied at the VP level. Engineers are modeled as expensive pieces of an equipment to optimize and derisk.
This works when people can compete on something measurable. But when you have teams split into feed, messaging, and ads, something else might be needed to measure value.
I've often speculated about a radical interpretation of this idea, inspired by a old video game (whose name I forget). In the game, you rule a kingdom, but unlike, say, Civilization, you don't directly manage things. You set goals and create quests, like "slay this monster and get some reward." And the quests would inspire heroes to join your kingdom, and things would grow from there. Iirc, you create incentives around your economy as well.
Imagine if there were product goals ("implement feature X") with some reward [1] attached and you could leave it up to teams or individuals to claim that goal if they desired. You could choose the goals you wanted to claim, recruit coworkers to help you, (eg, self form teams). PMs/Management would basically be in charge of allocating rewards for the goals.
I imagine it'd be a terrible system in practice for a number of reasons, but I enjoy thinking about ways you could attempt to make it workable. For example,
[1] rewards -- I don't think you could tie rewards directly to people's paychecks. Do that too much and I think you'd create perverse incentives. But perhaps things like swag, gifts, time off, or just bragging rights, honor, and glory might work.
[2] coordination -- a danger would people redundantly working on the same goal. You'd need a way to prevent that.
[3] other perverse incentives -- you might get an overabundance of folks choosing the "fun" goals, for example. (After all, engineers may be more motivated by that than other things.) Here I imagine the rewards for unsexy things would need to rise over time if nobody opted for them. Or, you make first dibs on some other "fun" goal the prize for achieving a less fun goal.
>It turns out that empowered people want to do a good job and want to save money.
This has more to do with Japanese culture than anything. Do that in America, and you just get signs with 'Over 99 Billion Served'
It becomes meaningless to everyone.
The reality of OKRs (or Rockefeller Habits or any other company wide framework for establishing priorities and goals,) is that by going through the exercise of trying to create them across the company, you often discover that there are meaningful disconnects in how teams are prioritizing work or how teams function vs how other stakeholders in the company believe those teams are operating. The real value comes from diving deeper into understanding those things. However, companies often view those as annoyances and find a way to plow the goals through while completely missing that learning opportunity.
This. High level OKRs should be set by the company to steer the ship, and engineering OKRs should align with the company OKRs. Thus, the roadmap is defined by the OKRs - I believe that's the whole point.
It just takes so many cycles to get to a point where everyone in the company is on-boarded to OKRs properly and by then people are burnt out on them, going through the motions without seeing the value, at least from the bottom up.
Large organizations also just have to be more process-driven and formal. And it's fine if you don't like that. At a former employer, I was much happier when it was a medium-sized enterprise than when it grew by almost 10x. A lot of things had to change that weren't really to my liking (or skill set) but they had to.
I also agree with this. I’ve been at growing companies that lacked processes like OKRs and then adopted them. The reason they crop up is to organize the chaos of hundred person teams.
On a 30 person team you’re constantly talking to everyone and don’t need an overarching framework. As you get to 300, teams may do duplicate or incompatible work. There is too much going on to follow unless you start getting a more formal process in place.
There's a famous theory that Gantt charts were actually created to keep decision-makers on the dark while Gantt could have some freedom to manage in a way that worked instead of letting they dictate some way that doesn't.
Taylorism was, of course, something that Taylor never believed in. That's no secret, as he spoke against it several times. Most personal "ism"s are like that. (What he actually preached was something very different.)
It's almost completely settled that current form "agile" was created by people that sold books and courses, and had not interest nor any professional experience in making teams work better.
And I guess the list goes on, but I don't remember more. But surprisingly, the guy that invented stack-ranking apparently believed it was really great.
Am I the only one who doesn’t care about OKRs or whatever companies are following nowadays? I tend to work around 2-3 years per company. Get a salary bump when switching. My first year is rather slow/smooth because “I’ve been here for less than a year!”. My second year is more interesting and I do take it as “real” work. My third year I couldn’t care less since I’m already looking for something else.
I couldn’t care less about goals or OKRs. I get paid, I solve whatever problems the business has (whether they make sense or not) and then I just leave.
No, because I want someone who stays around to build up enough knowledge of the tech and domain to make significant contributions. Someone who is completely uninterested and uninvested is rarely worth the time investment of a relationship with them.
Ah, but do you increase the pay of said veterans as they gain more experience with your stuff? If there's no incentive like that why would they want to stick around if they could make more money elsewhere?
huh? that is EXACTLY who he wants, not someone who will abandon the team to go elsewhere. if you look at the resume and you see someone jumping from job to job like a hooker why on Earth would anyone hire them???! absolute stupidity to even interview such a person
This is completely logical from a compensation/effort maximization perspective. But I find it deeply unfulfilling and could never work like this. If I'm spending 1/3 of my conscious hours on something, I want to feel like it matters.
This is the right approach. As an individual engineer, you are not paid enough to care about business problems and propose your own solutions and timelines. You are also not given organizational authority, budgets, or agency beyond your line of work.
You literally haven't been given the tools to own metrics and OKRs. And moving those metrics and OKRs doesn't get you more money.
> And moving those metrics and OKRs doesn't get you more money.
Because you are already being paid to move those metrics and OKRs. Not doing so means you're not actually doing your job and, in a well managed company (which are admittedly few and far between), will be rightfully fired and replaced by someone who does.
And even if/when you are paid well, you probably aren't given any meaningful ability to do the things necessary for those business problems. Corporate inertia is strong.
This is the way. But I’m unlucky to have been locked into a small job market, so I’m stuck in a local maximum. Won’t be moving to the US anytime soon with Trump’s immigration policies.
I always like to observe people who want quick results reading about agile or OKRs or KPIs and then handsomely shooting themselves into foot.
Other fun thing is having management mandate those things and people who don’t have time to understand all that stuff implement it.
Worst one is having ambitious young people thinking if they push for implementing those things they will be „real professionals” - that is how dev teams go to crawl enforcing all BS rules and product teams bikeshedding OKRs instead of delivering stuff.
>ambitious young people thinking if they push for implementing those things they will be „real professionals”
This is a real problem. It can destroy a successful operation. I don't specifically want to blame "young" or any other particular attribute, but it's common in that ambitious corporate type. Hiring managers, especially in startups, should really think about a newcomer's background. If someone comes from services where the name of the game is billable hours, it is going to be ingrained that there are processes that exist to justify those hours. That fails when your client is your company.
The need for “impact” in performance evaluations is also the cause of a lot of bike shedding.
I had a meeting the other day where my manager sent our team and told us to “be visible so we have something to report for year end about broader impact.”
We basically disrupted a meeting with poorly thought out commentary to put “cross pollination” on our self summaries.
I’ve led teams and then I’ve worked as an engineer, so I feel I understand both sides but have an informed take on how things go when OKRs show up despite/due to that.
I get as a leader that some form of goal orientation and niche engineering speak translation into outcomes must occur.
But, for every 1 leader who can do this well, there are 99 who can’t. For every 1/2 leaders who can do this faithfully, there are 99.5 who don’t care much beyond building fiefdoms or just plain don’t know how to do it in practice - the ex-consultant PM, the manager not the leader, the PM who holds zero authority over a team of skilled ICs, and so on.
Also, as an engineer, I have OKRs, I have ops, and I have the random stuff that shows up that blows a hole in my week to week plans. A good PM maybe can reduce this, but again see above. And: what am I measured on for my hearth and home paychecks: Answer - OKRs.
So, in practice, when OKRs show up, I believe earnest big picture effort (which people love going to startups for, I think), goes out the window overall because of the above.
You’ll only get people hitting OKRs, “hitting OKRs” has so much absurd flex in it because again see above, and so you best hope you have the 1 of 100 PMs that know how to do that well or else people start doing the silly dances engineers leave companies over.
I’ve had the same experience, both as IC and a manager. It’s a nice framework, just not for human organizations (KPI for next framework: result in less “no true Scotsman” replies whenever a post details why the framework sucks in their organization)
I've always worked in a non-tech where our customers are internal.
They have unfortunately read too many SRE/Phoenix Project/Big Tech Management Papers and so OKRs was one thing shoved down our throats.
What I've found is that they've hired a slew of Product Mangers (tm) who mostly just sit in between devs & users, without coordinating cross team, actually writing specs/Jiras/roadmaps, etc. So each teams devs wrote their own OKRs, in ignorance of what users (who might be other tech teams) might actually want or what other teams OKRs are.
For example, to use an analogy one team builds the foundation and decides their OKR is to use 15% less concrete next year. The other team builds frames and decides their OKR is to make the average building 15% taller next year. If any of them talked to actual final customers, they'd have found out the customers actually desire the buildings to be more robust to storm winds.
This is nearly my exact experience at work. I work on an internal tools team, so my users are other engineers at the company. Product teams have Product Managers and seem to put in a lot of effort into their OKRs, but for the internal tools team, we're in some limbo: still forced to write OKRs, but no parts of the process that are actually useful. We might have an OKR to upgrade Jenkins before an EOL date, but no introspection about whether the company at large would be better served by GitLab CI (as an example). Management only cares that we have defined KPIs like "Days remaining until Jenkins EOL date" and that they are improving. I still try to have the difficult conversations, but it's a constant battle with management as improving developer happiness by allowing them to use a better system isn't easily demonstrated on a dashboard.
Also, like you said, teams write their OKRs in a vacuum without coordinating with other teams. So, one engineering team might have an OKR to fix some memory issue affecting their Jenkins pipelines, but they didn't communicate that with the internal tools team that operates Jenkins. It then became a struggle between the two managers, one saying "We need to fix this Jenkins issue or we'll fail our OKRs commitment" and the other saying "We already committed to different OKRs this quarter, we can't take on new work." The engineers are stuck between this battle trying to help each other in secret without management hearing about it.
A lot of the lack of coordination devolves into cost center arbitrage as well. Often intentional.
I once worked at a shop that outsourced their datacenter to such a low cost bidder, that simple RAID disk replacements would be delayed for weeks and in a couple cases caused complete loss of a RAID array due to cascading drive failures.
Of course the datacenter guy got to point to his OKR for reducing operating costs. Meanwhile the "Big Data" team using their services was saddled with their losing days worth of highly paid engineers time as we chased tickets, dealt with data recovery, etc.
I'm now sat in the "final customer" internal seat and seeing it from the outside. IT brought us their new years plan to decommission some stuff I use, when I prodded a bit, they admitted was basically a cost allocation problem.
They were pushing the responsibility onto users like me, because they weren't good at allocating costs. No argument that it was more efficient or a good use of their customers time/resources. Simply that they hadn't gotten around to implementing metering so why not just stop offering the service entirely...
When that book came out, I actually COULD NOT BELIEVE that someone wrote A NOVEL about project management that was NOT some type of farce, comedy, or venomous satire.
Not sure if this is my gen-x mindset playing tricks on me or what.
You see, in the new economy you don't even needs stalks!
I simply hit this Autopark button and then my car alternates between inching back & forth to sharply jerking the wheel every which way, and then lands itself in the spot.
All while taking 3x longer than a competent human parallel parker and with heart stopping near-misses of hitting the surround parked cards. Oh and curbs your rims 20% of the time.
Oh and as the human driver you are still responsible to monitor for passing pedestrians and bikers.
If it crashes it's because you weren't monitoring it closely enough. And if you hit the brakes to stop it, you are a wimp who doesn't trust the car which totally would have gotten it right if you let it.
In my experience managemant roles set the OKRs in a closed circle, without feedback from technical employees and then things like reliable infrastructure are underestimated or forgotten. Once OKRs are set, they are set in stone, because management roles are too busy to come together again and additionally include engineering roles in the decision making process. Instead just put more pressure on engineering.
This kind of thing easily destroys great team dynamic and makes people change from getting work done to meeting target metrics, even if they only game them. This can lead to good and essential people quitting and the downfall of the company.
I think this is an attribution error. The issues you list are a function of management style, not of OKRs. Any management technique is very dependent on management not behaving pathologically.
I strongly believe that the addition of every metric brings with it an associated productivity tax in the form of:
1. time spent doing things that exploit this metric
2. time spent purely documenting/surfacing this metric on your ‘brand’
This post reflects an insidious anti pattern in the practice of setting OKRs: "shipping the roadmap" is not the objective, it is a means to achieving some other underlying objective.
With a well written objective / key result (ex: "grow DAU by 30%"), you can abandon your entire roadmap two weeks into the quarter and still hit your OKRs. They enable you to respond to new information and lessons learned, rather than locking the whole team into a rigid plan for the entire quarter.
I prefer Campbell’s Law — the more a metric is used in social decision-making, the more likely it is to be manipulated.
You’ve stated the widely-accepted formulation of Goodhart’s, but it can be interesting to note Charles Goodhart’s original statement was that “any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.” (The implication is people doubly go wrong presuming the regularity’s existence and placing pressure on it!)
I kinda disagree with tour takeaway. I have expanded on this idea elsewhere in this thread, however, the main point is that a measure is a byproduct of an existing process. Making the measure a target, i.e. process output, changes (possibly inadvertently) the process itself.
It does not matter if the regularity truly existed or was wrongly presumed to exist, as putting pressure on it invalidates the causal relationship it had before.
I'm convinced there is no 'good' way to set goals/OKRs etc. in big companies. Orgs should set goals though, but the problem is when you spend too much time doing it.
If top level management set company OKRs, and then cascade them down with every department and sub department then setting and aligning mini OKRs to the big ones you end up with a months long planning cycle which by the time you finish, you need to restart for the next year.
A good heuristic is that no team should ever end up in a situation where they spend more time debating how a task should be prioritized than the amount of time the task takes to do.
As an engineer I have nothing against OKRs. But it's often the day-to-day management (EM or PM) who tend to override the team's OKRs for upper management to prioritize something ad-hoc & out of scope they agreeably said Yes to.
And that's fine I think, it's why a lot of companies are using one or more of the agile methodologies. But if that's combined with OKRs then said OKRs need to be adjusted, and it'll be down to the manager to pay that cost.
We use SAFe at my current job (please don't look at the website, if you thought the "scrum" infographic was too big already lol); we set quarterly goals and objectives, usually don't meet them because Reasons, but if there is an incident or change that warrants changing those goals it's a Big Thing and we basically redo the planning sessions (two days or so); it's a big disruption and it's costly so it's not done lightly. We've only done that once in the past two and a half years or so.
This article is interesting, because we as a team are currently going through a strange phase, which is similar to KPIs and OKRs, but in a better way than previous companies did it.
Some internal discussions and skewed perceptions of our team are now causing our team are currently causing our team to make our work and our infrastructure more tractable and more quantifiable. For example, we've started to track time spent for internal customers and different topics team-internally and aggregate those on the team-level. Or we've started to generate information about resource consumption of different products.
And this has led to interesting results. At a workers level, our director and the board is very clear that they want to continue this data to be collected without interference or skew. If you work in an area, you track it in that area - don't try to protect anyone. Track time as you spend it. Track resources as spent.
On a leadership level, this has however resulted in a fairly interesting tone. Suddenly you have a CEO saying "Alright, so my very expensive team is spending that much time on this area you claim to be somewhat simple? Make that number go down significantly this year. Hire if and as necessary". Or "I dislike this amount of outages, but if you say we need better data there, make it so"
It's also a very much data driven management style. But you don't have magical bespoke numbers fall from the sky one day and you need to make sense of them and integrate them into your normal work. It is data about our work we collect along the way, and we're trying to change our tasks and our decision making to change our work to change the metrics into a better direction.
Goodhart's law suggests that no fixed set of measures will suffice, but what about a dynamic or a set of complementary measures that periodically switch? Spend 3-6 months optimizing for X, then spend 3-6 months optimizing for some property complementary to X. Like having metrics that focus on new features, then bug fixes, then new features, etc. Or new features, bug fixes, refactoring/maintenance, new features, bug fixes, etc.
Selecting the set of good and complementary metrics requires careful thought and experimentation, but it might prevent gaming over the long term because the complementary measures of the second phase should make up for deficiencies in the primary measures in the first phase. Anyone have any experience with this sort of thing?
This is another way to determine if a company is a "start-up"! If you work at a company that has OKRs, it's no longer a start-up or it's time to bail because said start-up is about to fail.
The problem is that OKRs are divorced from the “go do this piece of work” instruction, and so, just like code comments, they quickly become out of date or are outright ignored.
Because of that, the prescription about SMART and focus on delivery is simply wasted effort. At best a duplication.
The good part about OKRs is (/should be) that it forces an alignment conversation between teams and amongst managers. And the performance discussion with manager is often useful and sometimes revealing. More often both focus on metrics, losing the last opportunity to extract value from the concept.
The problem with OKRs and just about every corporate process is that something that began as a good idea gets diluted over time to the point of being nearly meaningless at best and super distracting at worst.
The reality — having worked in big tech for almost a decade — is that people just take what they already wanted to do and frame it as an OKR. You see this happen with Agile processes as well: "as a user I would like [to use this feature the PM is excited about]"
Some good observations here but I disagree with the conclusion.
> Shipping features from the roadmap is a chunk of our core job. It shouldn’t usually be in our OKRs.
First of all, your roadmap shouldn’t be static. You should give teams flexibility to change it. When/why? When they see a better way of achieving the teams objective. Ideally you can set up your KRs to also be flexible WRT implementation.
People loose sight of this, but it’s one of the two big value adds from OKRs.
The second big one is legibility outside your team/org. OKRs are about making your goals and work easily understandable, because the alternatives don’t scale as well.
So vis. the article, you should start with the question of what you want to make visible to the org, and make sure you craft your OKRs to highlight that part of the roadmap.
Concrete example, I plan with two buckets: new features, and bug fixes/ops/quality.
The customer for new features is users, and the org cares about this. You need OKRs to make your impact legible to your CEO, who (let’s be real) is not going to log into Jira and read the full backlog.
Bug fixes and ops need to happen, and they should be groomed and prioritized ideally, but in the ideal world nobody outside of the owning team should see them. Internal tooling should be on the roadmap but not OKRs, unless you are in the red and your CEO wants to know that you are improving after, say, a business-impacting outage.
So the roadmap is going to have a bunch of detail on the current delivery plans, sequencing, etc, but it’s downstream of your objectives. You should align your objectives with leadership first, then make your roadmap and propose KRs.
> Marketing is closer to project work, while Engineering (at places like Honeycomb) is product work. Projects like Marketing campaigns fit within a quarter or two, while product work is an ongoing rhythm of updates.
I am from the engineering side of things but this does not seem right about marketing...
Also, the examples of OKRs for engineering in the article seem somewhat contrived. I am sure some organizations/teams have OKRs like "ship the roadmap" but to say that is what all of them look like (everywhere!) is generalizing too far.
Like, everything in life, there is probably a balance: Between thinking in the near-term vs. thinking about the long-term. Between thinking what the ICs on the front-line think is most important vs. what the "middle-management" thinks will move the numbers on metrics that the execs care about.
A well-run planning process will result in the right balance being struck. And that IMHO is a rare thing: a well-run planning process, i.e. My $0.02.
"Let OKRs highlight a special focus. Don’t try to cram everything you do into them"
Then link compensation to OKRs then everybody just focuses on bending the reality to meet the letter of the OKR and nobody is interested in doing their job.
After the "oh shit" moment, we cram everything we do into them.
They brought them back during my recent tenure at Intel, just after Pat joined. I was an application engineer, so my purpose was to debug customer support issues on our chips, filter between the customer and the engineering staff, write some User Guides and helpful collateral to developers, and open tickets with engineering when problems were severe enough. My OKRs could have just been "close tickets" and I think that would have been the best ROI for the company - there was never a point in my career where I didn't have tickets that needed working on that were halting multiple millions in revenue, but somehow my time was always spent having to work on other things.
Management insisted on filling my OKRs with low-value 1:N activities - spending time on the forum (full-time forum people were paid to do that), helping sales with technical discussions with customers (field engineers were paid to do that), creating demos/PoCs for marketing (technical marketing engineerings were paid to do that), or being part of one "centre of excellence" or another wasting time in meetings with non-technical people talking about how we were all going to tackle problems when the reality was that no one in the team had the time, talent, or political capital to do any of the things we spent hours discussing.
To me, OKRs seem effective for the workforce in the same way scout badges are effective for children to learn skills - good for those who otherwise would do nothing. The issue is, for intrinsically motivated people who are incredibly specialised in a largely reactive role they are a distraction at best, and when used for quarterly and yearly performance tracking, a detriment to the core role at worst.
I worked at a startup where the main problems I saw were:
(1) It was impossible for anyone to enforce anything. Our genius business development guy couldn't get our head data scientist to share data files with customers (say Big 5 accounting firms) in a way they felt were safe. I couldn't get the data scientists to use standardized versions of Python. (Docker just accelerated their ability to find defective Pythons, such as one with Hungarian as the standard charset) The engineering manager would tell me "we use monads for error handling in Scala" and "we do code reviews" but I don't believe the latter because the first certainly wasn't true.
(2) We were developing core technology and developing solutions for various customers. There was a lot of zigging and zagging and spoiled work in progress. I felt like the customer contact was helping us understand the requirements for the core so I'm not complaining about that. Our management practices should have been focused 100% on squaring that circle.
The VCs believed in our vision and our BD genius (I did!) but they knew we were badly managed and brought in a stream of consultants some of whom were helpful and some who weren't.
The worst was the consultant who came in and forced us all to write OKRs which took two weeks against the core and solution and development work that did matter for the business.
My feeling was that my job was to pull for the team wherever it needed it and it wasn't my business to set goals that weren't fundamentally grounded in the needs of the team. I had enough work to do that I didn't need to add a single task that wasn't on that critical path. Particularly customer requirements could change faster than the OKR cycle, we needed practices that worked at the speed of our business.
I was anxious that when review time came along I'd find that, out of 20 OKRs, I would nail 5 of them, totally fail at 5 of them and the other 10 would be in between. At review time whether this is success failure would depend on politics and ability to navigate politics. That genius BD would deservedly get a good review, a really good coder or data sci may or may not. People with high and unmitigated narcissism are privileged by systems like stack ranking and OKR because they are focused on presentation of self in ways that average people aren't.
OKRs, KPIs, etc are often challenging for orgs, teams, and individuals that are poorly trained. It's the same problem with Scrum: if the people are poorly trained, they will find it challenging, even counter-productive, to use them.
Every company I have worked for has not trained their workers for OKRs, KPIs, Scrum, etc. (Well that's not true: Cisco paid for us to have two weeks of Scrum training because our stand-ups were 1.5 hrs long. That's the only reason I know how it's supposed to work) They hire you expecting you know all of that (though never verifying), and then they dump you in the deep end and don't give you the training you need to use it correctly. The end result is nobody uses it right, and the company suffers. And it's complex enough that a pithy clickbait blog post on HN isn't going to teach you how to do it right.
Managers, execs: train your staff. You're only hurting yourself and the company by not doing so.
Context: I'm an engineering director at a medium-large tech company.
What both the article and the comments here show is that for most users of OKRs, they don't actually consider the Objective and the Key results to be different. If you consider a key result without considering the objective, then yes, you'll just move a number and nothing more. If you actually try to deliver an objective, and use your KRs to see if you have made progress towards that objective you'll do much better.
That said, I've had to fight many times in my career, even with senior-level product managers, to think about OKRs that way. I ideally ask the engineers that report up to me to care first and mostly about the Objectives their team has taken on, and to care about the KRs second. That leads people to do the right work far more often than having them try to move a specific numerical value above all else.
If I could give one piece of advice to my early-career self, it’d be this: do more "visible" work rather than "good" work. The former gets you promoted, while the latter leaves you stuck as a senior engineer forever. For me, that ship sailed a while ago, and I’m sorta happy being stuck as a senior engineer. That puts me in a good spot to say OKRs are bullshit.
With what other role / direction would you be satisfied instead of being SE? Going up in the IC ladder (lead, staff, etc.) or management? What disadvantages do you see settling at SE?
Staff is the natural progression for people who want to take the next step but don’t want direct reports. Each company has its own definition of a staff engineer's responsibilities. I’ve seen people move back to SE after burning out from all the meetings. In some places, staff engineers rarely code and are essentially glorified team leads.
But there are definitely companies where Staff engineers get to do some awesome work and there's a proper delineation between a Staff and a TL. I'm yet to work in a company like that yet.
There's a big gap between the big list "what we have to do" and being able to furnish a brief summary that both focuses the team's attention correctly and shows higher leadership that what's happening is meaningful.
The problem with OKRs is that they're another metric, and get gamed and talked about as such. The soft skill of being able to effectively summarize and express the meaning behind list of tasks isn't necessarily going to
OKRs are just another word for priority. You have an infinite amount of “could do” and a limited amount of “must do”, and “must” is very rarely clear a year or more out in any measureable sense
So eventually we come to “support the overriding mission”, and record everything we do, and we can retroactively look to see who contributed most.
It will never be who you think
Plus that part is so politically driven you may as well say “elites will reward elites, those with skills will leave if they can find somewhere”
Just a thought but if “elites reward elites” is a truism, then only when you spread enough wealth around that elites become so common that democracy is the only viable means for elites to reward other elites…
As a software dev the only KPI I want my team to have is the build time.
There was that time at one place where it seemed I was the only person who actually put tickets in the ticket system (the product manager never did.)
I was told that every ticket I put in had to have clear value for the consumer and they complained about a ticket to speed up the build. I told them "it has value for the customer because the customer wants the product and could have had it six months ago if we 5x'ed the build speed a year ago"
Duh, obviously I want "shipping the roadmap" in the OKRs. OKRs should capture everything you plan to do, otherwise what's the point? Obviously I don't want the whole roadmap, just the part we commited to. You probably also don't want only the roadmap, for obvious reasons.
There's never enough time to do everything that's planned or necessary and OKRs should be the tool that lets you resolve the conflicts. Ship feature X or fix the infrastructure? "X is in OKRs, let's work on X". "X is not in OKRs and we have KR to get Y% success on autodeployments, let's fix infra".
What I definitely don't want is "do OKRs and also do roadmap". The only things that should not be in the OKRs are ones where prioritization is trivial (like "fix critical outages").
My favorite part of the year is when everyone needs to re-write their OKRs/Goals before review season, because we ended up have to do actual work that related to the end-user product, and in general most humans cannot predict the future.
As long as the metrics attached to an OKR actaully a)make sense and b)are causally related to the OKR, then they can work. Where ORKs go off the rail is trying to set a goal for something you just can't manage.
OKRs and KPIs are scams. Human language and psychology are both vague and malleable. The kinds of people who are good at meeting OKRs aren't the kinds of people who can produce quality work. OKRs are mostly about lowering expectations prior to implementing and exaggerating results after implementing... It's mostly psychological work, a magic trick, not real productivity.
The goal of this game is to sacrifice long term gains for short term gains; build a house of cards fast to boost your OKR scores and get promoted fast... Then let the next person who is assigned to the project take the blame for the collapse.
People don't care about foundations... Only thing that matters is whose watch the tower falls on. People are literally that ignorant and superficial. It works every time.
Yes, exactly this! We are actually spending soo much time deriving, thinking, formulating & refining OKRs from roadmap items that we could just declare as simple "Goals". We could get so much shit done during that time.
Most of the time as the quarter goes on, we then scrap those OKRs anyway because we didn't manage to do them or they were too specific and requirements changed.
I always had the feeling that what we are doing is bullshit. So great to finally hear it from someone else.
I wonder how many engineering companies actually use OKRs though.
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.
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.
What you really want is: - 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.
In small teams/companies “the right thing” can be obvious and the team can operate in a shared headspace with low cycle time to discuss and decide tradeoffs when they arise. This gets really problematic at scale.
Now back to the cynicism — it’s also tricky when you want to hide the ball and make teams feel ok about doing bad things: make time spent go up is the goal, who cares if there’s addiction along the way.
I've been part of an extremely effective 200 people company that got acquired by a 4000 people company. We all understood why we were acquired, we built a platform that solved a fundamental problem the larger company had.
After the acquisition, this larger company's OKR and measurement system was implemented for our teams.
We initially all ignored the system and went on as usual, starting to implement our platform. Initially, things went well, we made steady progress and started migrating legacy projects to out platform.
Then, the annual stack ranking firings happened. Some of our best engineers were fired. Seeing this, many other top performers started looking for jobs immediately. The ones that got hired elsewhere started poaching even more top performers. The ones left started playing the numbers game to avoid being fired.
Within a year, most people went from trying to solve the larger company's problem to optimizing their numbers. Within another year, the platform initiative had completely failed and was abandoned, with most of the remaining people being fired or integrated into other teams.
That’s what i have concluded a long time ago. Upper management has a deep distrust of their employees and acts accordingly. They will hire consultants or external people before they will listen to their employees. I think part of it is that a lot of them don’t really believe in anything themselves and only blindly try to fulfill goals set by their CEO or board of directors.
Corporations reward an individuals tenure and experience with increased decision making (often, this means manager title). That increase in decision making means that less senior IC's become less autonomous, even when they inevitably exceed their superior's experience on the topic.
The level of autonomy is at odds with the number of managers. Some people argue this is a good thing. I argue that those people are just managers justifying their jobs.
Internal communications like that are a scale problem: in a small company, the matrix of personal relationships is basically full, but as companies get larger, the matrix gets sparser and sparser. By the time you have a 100,000 employees in time zones all over the world your matrix is almost all 0's with only occasional 1s. And so information will travel quite poorly without people whose explicit tasks are to convey information to the right people. That's what managers and internal bureaucracy are supposed to do. Sometimes that information is "we need to build this and not that," sometimes it's "employee 24601 is great and should be given more responsibility," sometimes it's "this project is a Kafkaesque nightmare of un-ending pain that will never be delivered as scoped." But identifying this information and sharing it with the correct other people- that's what middle-management is supposed to do.
Believe me, I am not generally a fan of bureaucracy (as I type this I'm supposed to be fixing a problem that is somewhere in the interface between my 100k employee company and another 100k+ employee company, and it's goddamn terrible), but it does have value beyond just fief-building.
Convince me that this duplication of work is worse when you have to shoehorn solution X into solving problem theta poorly, because someone 2 degrees (or more) removed from the problem thought that problem iota (which X actually solves) was "basically the same thing" as problem theta.
This. Got managed out of a previous employer as I didn't want to participate in the numbers game by focusing on the customer.
If you are senior enough, you can get away with it for a long time. Customers liked me, account managers too (as their customers increased spending), and my manager (at the director level) had my back. That was all good until the day they put another management layer between the director and me...
the first time this happened, i felt like my brain was going to explode -- so wait, you want me to leave the main app feed broken and people pissed off because the comment-notes-experience-home-ex team's weekly comment rate is slightly regressing?
writing this out, not sure how i lasted as long as i did.
This reminds me of when we introduced Yammer at a company. Initially, it worked great, everybody loved it, it was super valuable to share information internally. Then, at some point, the feed broke and it somehow started demoting the most valuable posts, requiring much more time to be sure that you had caught up on everything relevant to you.
Then I read an interview with the CEO where he bragged how they were data-driven and were optimizing for engagement. My guess is that somebody had figured out that hiding important information created more "engagement" because people now had to spend more time searching for the stuff that was relevant to them.
This person probably got a promotion, and we switched to a different system half a year later.
Although what happened was slightly different. I was a developer. Came in fresh faced and worked my ass off. Took on additional work, went to copious amounts of conferences, networked outside of team constantly, always finished my Sprint work ahead of time. Did everything a high performing dev would do. On a scale of 1-5, I was ranked a 3 (meeting expectations), barely any bonus, barely any salary increase.
I was like, "WTF?!?!" and was naturally pretty pissed. Next year? Barely did anything. Came into the office for morning standup, left, worked from home rest of the day. I constantly took afternoons off, Still got work done on time, did the absolute minimal amount of work. I was "silently quitting" before anybody ever coined the phrase. Next years review? Yeap, you guessed it, another 3.
That pretty much confirmed to me that nothing was ever going to change if I was working my ass off or just doing the absolute minimal amount of work. This lasted another two years before they finally offshored my team and I left the company with several great references.
It was a great lesson to learn that its just a game, and you either do everything to stand out which has a high mental and emotional cost, or you simply refuse to play the game, retain your sanity, and look at your job as simply a means to an end as opposed to a satisfying career.
(1) A legitimacy gap. People think taxation is on ratchet and wouldn't trust it to be revenue neutral and not a money grab.
(2) It's a global problem. If there is a carbon tax in the US and no carbon tax in China that's unfair for our manufacturers. People will complain about the fairness of any particular rebating scheme inside the US, but there will always be much worse complaints about a system which embraces all nations from Luxembourg to Burundi.
The EU is implementing something like that, and we’re seeing an uptick in appetite in the US to implement a border adjustment here, partly as a result, there were a few bills put forward in the last Congress, though nothing has gotten very far yet.
I think the efficiency gap is less than with other approaches. Rather than privileging electric cars we should reward people the same if they save carbon by buying an electric car or riding a bike or if an industrial process is replaced by one that is naturally carbon free or if you take the carbon out of the stack or if you take it out of the atmosphere. The market should decide what is the most efficient.
(Note another 'efficiency' concern people have is that you don't want to pay people $400/ton to store carbon from fermentation at an ethanol plant that is unusually cheap at $40/ton because you get nitrogen-free CO2. People seem to have a moral problem with that, first fundamentally, second because the ethanol plant is problematic in other ways)
It's not simple to manage those adjustments, but governments deal with much more complex taxes everywhere. It's not a big deal.
And yeah, the UBI cancellation of the tax, the tariffs on imported products and the rebate on exported products deal with every single problem I've seen people post about a carbon tax, except for "expensive gasoline will destroy our economy!", that is almost always pushed by people that live in a place with some of the cheapest gasoline prices of the world.
There is an add-on that some people push where you don't cancel all of the tax in an UBI, but use a part of it to finance carbon capture projects. I do really like this one, but it's not something that is required for things to work.
I like it that you can spend your UBI on expensive gas or to get an electric car or ride a bike, walk, WFH or whatever and pocket all of your rebate.
I worked at a small company when GDPR was introduced, and people volunteered to read up on it, and work with an external lawyer to write specs on what we had to do, because they knew that it had to be done and wanted the company to succeed.
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.
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.
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
Solved :)
Now we're getting key results.
Put another way, if your client has 20 inherent metrics, you can't have 20 OKRs so you're always at risk to mess it when focusing on a smaller set.
- fix it themselves without anyone asking - bring it up to higher management - deprioritize it based on severity and leadership initiatives
This is the pattern taught by Jethro to Moses in the Old Testament:
every great matter they shall bring unto thee, but every small matter they shall judge: so shall it be easier for thyself, and they shall bear the burden with thee.
No matter what your intentions are, doing this frequent enough will give you reputation of being a lonely wolf and trouble maker.
But it can’t function any other way. You are a filter of small problems for everyone in the org higher than you. If you bring up everything up the chain your level may as well not exist.
I don't think it ever worked. (Remember when Japan destroyed the world's car industry just by changing that single thing? And that's industry work, highly repetitive and formalized.) But that never stopped managers from doing something.
Finding and fixing product problems requires decentralized decision making and trust.
What I find odd, is often the biggest proponents of the free market - with it's decentralised decision making process ( and redundancy of effort ), decide that total centralized, top down control is the best way to run their own company - as they think top down decisions and minimising waste through duplication is the way to go.
As with all things - it's a balance of course.
My argument above is about not what shapes a firm's boundary but how it operates internally - too much top down control potentially risks exacerbating the risks associated with being a company and also potentially increases internal transactional costs as well - worse of both worlds! - all that ceremony around decision making, time spent justifying existences, inability to just act.
Obviously as I said above - it's a balance - just as it is with country/international systems.
Corporations don’t have police or taxation power and so have more limited impact on your individual freedom.
In a “free market” you can choose what firms you work for and with, except the government.
The government would be more efficient in an autocratic leadership. But government efficiency is not the societies efficiency and well being
Eh? Nobody ever leaves one country for another?
> The government would be more efficient in an autocratic leadership. But government efficiency is not the societies efficiency and well being
I think the free market proponents would say otherwise - one key problem is the myth of perfect information - you are imagining it's possible to concentrate all the required information to make any correct decision into a very small group of people at the top ( and assuming these people are competent and not corrupt). One of the ideas behind why distributed markets work is the information about what is needed is communicated by the mechanisms of the market itself.
And to bring it back to the original post - does the CEO have all the information required to direct others to meet the customers need across all areas - or is it better to use the collective intelligence of the entire organisation?
Which is exponentially harder in a large company - hence why OKRs are invented.
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
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.
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
When you make a game you'd want to hit those thresholds for as many users as possible. When you're reviewing cards all you can do is give a sampling of the landscape to get a rough sense of how the card would do in any given game.
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.
As stated its also likely not possible. Even a free 10% improvement across the board would be massive. Imagine only getting 20% more perf out of a driver and yet the bonus is marked as below target.
The numbers were picked because they were easy to pick, not because they were deeply thought through and that happens all the time with these OKRs. That's why they're dangerous.
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.
As a manager you should have metrics because then you know if you tweak the process correctly. Not sharing it with employees and definitely not making any bonuses or pay increases depending on metrics. Because then employees will game your metrics and they will be useless.
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.
In organisations that do this kind of work, the 'marketing' department isn't just about placing adverts and writing blog posts. They also have people whose job is to keep track of what's going on in the market, and to estimate what your product needs in order to be competitive when it comes out.
To take a simple example, the marketing team might have visited https://www.tomshardware.com/reviews/amd-radeon-rx-7900-xtx-... and found on 4K ultra settings that the "RX 7900 XTX" shows up as 90.3 fps average and the "RTX 4090" shows up as 112.6 fps average. And 112.6÷90.3 = 1.246 so if AMD want their next-gen flagship to outperform nvidia's current-gen flagship, they need 24.6% more FPS.
Of course it's a lot more complicated than that in practice. They'd also consider value-for-money, non-flagship cards, whether users' monitors even support >120fps, guessing at what nvidia's next flagship will offer, interviewing big buyers like Dell, and so on. But that's the general gist of it.
My experience says these two things are often mutually exclusive.
Many people will say I am leaving stuff on the table, and I say that they are literally parasites.
"A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it."
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".
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 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.
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.
Any levels of social complexities beyond that has to rely on systems/traditions rather than direct interpersonal relationships.
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.
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.
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.
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 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.
If they can point to a number from a really poorly/quickly done ad hoc study, they’ll never worry about being told they made the wrong decision
They're not going to be personally responsible for "improving the response time of the FizzBuzz server by 22.3%" or anything like that. No - the product manager tells the team on what they'll be working, the work gets broken down into parts, and they take what's available when they come up for air.
OKRs should never be handled at a level more granular than a scrum team, or equivalent.
So we need metrics., lest we get swept away in the Trickle-down Incompetence.
I also think that the companies that matter getting bigger and bigger, with no actual failure on the horizon (such as bankruptcy) in case of strategically wrong decisions doesn't help things one bit, because in those cases management failure is in many cases rewarded as there's no immediate and adverse affect on the life of the company itself. We need some return to creative destruction, otherwise we'll be left re-arranging the chairs on the deck of the Titanic (I see this type of discussion on this particular subject as part of that metaphorical re-arrangement) until the proverbial iceberg will strike.
Where are these malarkey-free companies? I've worked at several small companies and they all had all kinds of malarkey.
Basically Goodhart’s law https://en.m.wikipedia.org/wiki/Goodhart%27s_law
Counter point. This is always inevitably a thing. They were only making the implicit explicit.
Not having to deal with this is one of the positives about working in a small startup versus a long-established large corporate.
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.
It is not in small (say below 5 people) teams/ organisations. At least not in the ones I worked in.
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.
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.
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.
Also, metrics eventually become the goal and are gamified.
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.
We measure something because we need something to measure even if it is divorced from reality.
It talked about some company moving oil around in barges, the setup was unprofitable and a new manager was brought up to fix it. He created metrics of the business, but didn't put any goals or goalposts for the barge crews and other managers in the company.
All he did was simply print the metrics and glue them on every barge of the fleet weekly. Soon the whole project was massively profitable. Apparently the captains of the barges would compete with each other to see who could save more money, without any penalties for the low performing nor any rewards for the high performing barges.
One thing that was very surprising is that the barges were given freedom to choose where to source materials and, more importantly, the fuel. Before the metrics the captains would pick whatever was closest no matter the prices, after the metrics the captains would, on their own, try to source fuel from the cheapest place that they could. No amount of central planning could have been as optimal as the prices fluctuated a lot from day to day, so whenever a captain saw a good deal he would re-fuel.
It turns out that empowered people want to do a good job and want to save money.
> Koch’s dedication to Deming’s ideas eventually led the company into several sticky situations, not the least being targeted in a Senate Select Committee investigation for oil theft in 1988, a direct result of immense internal pressure on employees as part of its continuous improvement program.
[1]
This is powerful stuff. When you empower people and set a goal, they will do anything it takes to hit that goal, including breaking the law.
[1] https://commoncog.com/deming-paradox-operational-rigour/
You have to be careful here. In your example those captains didn’t really care about their job they cared about getting the high score. Metrics, KPIs, etc work but only when they’re setup perfectly aligned with your actual business goals. Measure/score the wrong thing and you’ll get nowhere.
For example, what if the metric posted was distance traveled by a barge. You’d have captains taking the longest routes possible just to get the high score instead of shipping the most product per unit time which is what the manager would have intended.
It’s a good sign if your job works this way. Unfortunately this tends to mostly be applied at the VP level. Engineers are modeled as expensive pieces of an equipment to optimize and derisk.
I think a lot of business don't, at least on the lowest levels of the org chart.
Sounds good, but how did the "metrics" expose which individual decision-makers were responsible for any improvement or deterioration?
Imagine if there were product goals ("implement feature X") with some reward [1] attached and you could leave it up to teams or individuals to claim that goal if they desired. You could choose the goals you wanted to claim, recruit coworkers to help you, (eg, self form teams). PMs/Management would basically be in charge of allocating rewards for the goals.
I imagine it'd be a terrible system in practice for a number of reasons, but I enjoy thinking about ways you could attempt to make it workable. For example,
[1] rewards -- I don't think you could tie rewards directly to people's paychecks. Do that too much and I think you'd create perverse incentives. But perhaps things like swag, gifts, time off, or just bragging rights, honor, and glory might work.
[2] coordination -- a danger would people redundantly working on the same goal. You'd need a way to prevent that.
[3] other perverse incentives -- you might get an overabundance of folks choosing the "fun" goals, for example. (After all, engineers may be more motivated by that than other things.) Here I imagine the rewards for unsexy things would need to rise over time if nobody opted for them. Or, you make first dibs on some other "fun" goal the prize for achieving a less fun goal.
At a factory it's easy to know how many widgets were made. It's tricky with software.
This has more to do with Japanese culture than anything. Do that in America, and you just get signs with 'Over 99 Billion Served' It becomes meaningless to everyone.
On a 30 person team you’re constantly talking to everyone and don’t need an overarching framework. As you get to 300, teams may do duplicate or incompatible work. There is too much going on to follow unless you start getting a more formal process in place.
[1] https://x.com/benwbear/status/1543056694330003456
There's a famous theory that Gantt charts were actually created to keep decision-makers on the dark while Gantt could have some freedom to manage in a way that worked instead of letting they dictate some way that doesn't.
Taylorism was, of course, something that Taylor never believed in. That's no secret, as he spoke against it several times. Most personal "ism"s are like that. (What he actually preached was something very different.)
It's almost completely settled that current form "agile" was created by people that sold books and courses, and had not interest nor any professional experience in making teams work better.
And I guess the list goes on, but I don't remember more. But surprisingly, the guy that invented stack-ranking apparently believed it was really great.
I couldn’t care less about goals or OKRs. I get paid, I solve whatever problems the business has (whether they make sense or not) and then I just leave.
I don't want to waste my time and effort on people who don't give a fuck.
You literally haven't been given the tools to own metrics and OKRs. And moving those metrics and OKRs doesn't get you more money.
So why would you care? You sound rational to me.
Because you are already being paid to move those metrics and OKRs. Not doing so means you're not actually doing your job and, in a well managed company (which are admittedly few and far between), will be rightfully fired and replaced by someone who does.
Other fun thing is having management mandate those things and people who don’t have time to understand all that stuff implement it.
Worst one is having ambitious young people thinking if they push for implementing those things they will be „real professionals” - that is how dev teams go to crawl enforcing all BS rules and product teams bikeshedding OKRs instead of delivering stuff.
This is a real problem. It can destroy a successful operation. I don't specifically want to blame "young" or any other particular attribute, but it's common in that ambitious corporate type. Hiring managers, especially in startups, should really think about a newcomer's background. If someone comes from services where the name of the game is billable hours, it is going to be ingrained that there are processes that exist to justify those hours. That fails when your client is your company.
I had a meeting the other day where my manager sent our team and told us to “be visible so we have something to report for year end about broader impact.”
We basically disrupted a meeting with poorly thought out commentary to put “cross pollination” on our self summaries.
I get as a leader that some form of goal orientation and niche engineering speak translation into outcomes must occur.
But, for every 1 leader who can do this well, there are 99 who can’t. For every 1/2 leaders who can do this faithfully, there are 99.5 who don’t care much beyond building fiefdoms or just plain don’t know how to do it in practice - the ex-consultant PM, the manager not the leader, the PM who holds zero authority over a team of skilled ICs, and so on.
Also, as an engineer, I have OKRs, I have ops, and I have the random stuff that shows up that blows a hole in my week to week plans. A good PM maybe can reduce this, but again see above. And: what am I measured on for my hearth and home paychecks: Answer - OKRs.
So, in practice, when OKRs show up, I believe earnest big picture effort (which people love going to startups for, I think), goes out the window overall because of the above.
You’ll only get people hitting OKRs, “hitting OKRs” has so much absurd flex in it because again see above, and so you best hope you have the 1 of 100 PMs that know how to do that well or else people start doing the silly dances engineers leave companies over.
They have unfortunately read too many SRE/Phoenix Project/Big Tech Management Papers and so OKRs was one thing shoved down our throats.
What I've found is that they've hired a slew of Product Mangers (tm) who mostly just sit in between devs & users, without coordinating cross team, actually writing specs/Jiras/roadmaps, etc. So each teams devs wrote their own OKRs, in ignorance of what users (who might be other tech teams) might actually want or what other teams OKRs are.
For example, to use an analogy one team builds the foundation and decides their OKR is to use 15% less concrete next year. The other team builds frames and decides their OKR is to make the average building 15% taller next year. If any of them talked to actual final customers, they'd have found out the customers actually desire the buildings to be more robust to storm winds.
Also, like you said, teams write their OKRs in a vacuum without coordinating with other teams. So, one engineering team might have an OKR to fix some memory issue affecting their Jenkins pipelines, but they didn't communicate that with the internal tools team that operates Jenkins. It then became a struggle between the two managers, one saying "We need to fix this Jenkins issue or we'll fail our OKRs commitment" and the other saying "We already committed to different OKRs this quarter, we can't take on new work." The engineers are stuck between this battle trying to help each other in secret without management hearing about it.
I once worked at a shop that outsourced their datacenter to such a low cost bidder, that simple RAID disk replacements would be delayed for weeks and in a couple cases caused complete loss of a RAID array due to cascading drive failures.
Of course the datacenter guy got to point to his OKR for reducing operating costs. Meanwhile the "Big Data" team using their services was saddled with their losing days worth of highly paid engineers time as we chased tickets, dealt with data recovery, etc.
I'm now sat in the "final customer" internal seat and seeing it from the outside. IT brought us their new years plan to decommission some stuff I use, when I prodded a bit, they admitted was basically a cost allocation problem.
They were pushing the responsibility onto users like me, because they weren't good at allocating costs. No argument that it was more efficient or a good use of their customers time/resources. Simply that they hadn't gotten around to implementing metering so why not just stop offering the service entirely...
When that book came out, I actually COULD NOT BELIEVE that someone wrote A NOVEL about project management that was NOT some type of farce, comedy, or venomous satire.
Not sure if this is my gen-x mindset playing tricks on me or what.
https://bitsaboutmoney.com/archive/fiction-about-finance/
me: Tesla,I want a car with turn signal and drive selector stalks!
I simply hit this Autopark button and then my car alternates between inching back & forth to sharply jerking the wheel every which way, and then lands itself in the spot.
All while taking 3x longer than a competent human parallel parker and with heart stopping near-misses of hitting the surround parked cards. Oh and curbs your rims 20% of the time.
Oh and as the human driver you are still responsible to monitor for passing pedestrians and bikers.
If it crashes it's because you weren't monitoring it closely enough. And if you hit the brakes to stop it, you are a wimp who doesn't trust the car which totally would have gotten it right if you let it.
I have yet to hear complaints from someone who's had one for more than a week.
You also didn't answer my question, which makes me think your complaints are secondhand.
This kind of thing easily destroys great team dynamic and makes people change from getting work done to meeting target metrics, even if they only game them. This can lead to good and essential people quitting and the downfall of the company.
With a well written objective / key result (ex: "grow DAU by 30%"), you can abandon your entire roadmap two weeks into the quarter and still hit your OKRs. They enable you to respond to new information and lessons learned, rather than locking the whole team into a rigid plan for the entire quarter.
You’ve stated the widely-accepted formulation of Goodhart’s, but it can be interesting to note Charles Goodhart’s original statement was that “any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.” (The implication is people doubly go wrong presuming the regularity’s existence and placing pressure on it!)
I kinda disagree with tour takeaway. I have expanded on this idea elsewhere in this thread, however, the main point is that a measure is a byproduct of an existing process. Making the measure a target, i.e. process output, changes (possibly inadvertently) the process itself.
It does not matter if the regularity truly existed or was wrongly presumed to exist, as putting pressure on it invalidates the causal relationship it had before.
People are indeed prone to affirming the consequent.
https://en.wikipedia.org/wiki/Affirming_the_consequent
If top level management set company OKRs, and then cascade them down with every department and sub department then setting and aligning mini OKRs to the big ones you end up with a months long planning cycle which by the time you finish, you need to restart for the next year.
A good heuristic is that no team should ever end up in a situation where they spend more time debating how a task should be prioritized than the amount of time the task takes to do.
We use SAFe at my current job (please don't look at the website, if you thought the "scrum" infographic was too big already lol); we set quarterly goals and objectives, usually don't meet them because Reasons, but if there is an incident or change that warrants changing those goals it's a Big Thing and we basically redo the planning sessions (two days or so); it's a big disruption and it's costly so it's not done lightly. We've only done that once in the past two and a half years or so.
Isn't this the very definition of not being agile?
Product: Here are these 1567 story points for this new sprint with new product development stuff which is urgent and should be completed in 2 weeks.
Some internal discussions and skewed perceptions of our team are now causing our team are currently causing our team to make our work and our infrastructure more tractable and more quantifiable. For example, we've started to track time spent for internal customers and different topics team-internally and aggregate those on the team-level. Or we've started to generate information about resource consumption of different products.
And this has led to interesting results. At a workers level, our director and the board is very clear that they want to continue this data to be collected without interference or skew. If you work in an area, you track it in that area - don't try to protect anyone. Track time as you spend it. Track resources as spent.
On a leadership level, this has however resulted in a fairly interesting tone. Suddenly you have a CEO saying "Alright, so my very expensive team is spending that much time on this area you claim to be somewhat simple? Make that number go down significantly this year. Hire if and as necessary". Or "I dislike this amount of outages, but if you say we need better data there, make it so"
It's also a very much data driven management style. But you don't have magical bespoke numbers fall from the sky one day and you need to make sense of them and integrate them into your normal work. It is data about our work we collect along the way, and we're trying to change our tasks and our decision making to change our work to change the metrics into a better direction.
- the perception of hitting OKRs is more important than anything else
- if you can enter into the OKR discussion early, then you can control it.
- if you can, run the OKR process much to your gain :)
Selecting the set of good and complementary metrics requires careful thought and experimentation, but it might prevent gaming over the long term because the complementary measures of the second phase should make up for deficiencies in the primary measures in the first phase. Anyone have any experience with this sort of thing?
How come?
Because of that, the prescription about SMART and focus on delivery is simply wasted effort. At best a duplication.
The good part about OKRs is (/should be) that it forces an alignment conversation between teams and amongst managers. And the performance discussion with manager is often useful and sometimes revealing. More often both focus on metrics, losing the last opportunity to extract value from the concept.
The reality — having worked in big tech for almost a decade — is that people just take what they already wanted to do and frame it as an OKR. You see this happen with Agile processes as well: "as a user I would like [to use this feature the PM is excited about]"
But most good ideas can turn into just a lot of rules and process to follow over time.
> Shipping features from the roadmap is a chunk of our core job. It shouldn’t usually be in our OKRs.
First of all, your roadmap shouldn’t be static. You should give teams flexibility to change it. When/why? When they see a better way of achieving the teams objective. Ideally you can set up your KRs to also be flexible WRT implementation.
People loose sight of this, but it’s one of the two big value adds from OKRs.
The second big one is legibility outside your team/org. OKRs are about making your goals and work easily understandable, because the alternatives don’t scale as well.
So vis. the article, you should start with the question of what you want to make visible to the org, and make sure you craft your OKRs to highlight that part of the roadmap.
Concrete example, I plan with two buckets: new features, and bug fixes/ops/quality.
The customer for new features is users, and the org cares about this. You need OKRs to make your impact legible to your CEO, who (let’s be real) is not going to log into Jira and read the full backlog.
Bug fixes and ops need to happen, and they should be groomed and prioritized ideally, but in the ideal world nobody outside of the owning team should see them. Internal tooling should be on the roadmap but not OKRs, unless you are in the red and your CEO wants to know that you are improving after, say, a business-impacting outage.
So the roadmap is going to have a bunch of detail on the current delivery plans, sequencing, etc, but it’s downstream of your objectives. You should align your objectives with leadership first, then make your roadmap and propose KRs.
I am from the engineering side of things but this does not seem right about marketing...
Also, the examples of OKRs for engineering in the article seem somewhat contrived. I am sure some organizations/teams have OKRs like "ship the roadmap" but to say that is what all of them look like (everywhere!) is generalizing too far.
Like, everything in life, there is probably a balance: Between thinking in the near-term vs. thinking about the long-term. Between thinking what the ICs on the front-line think is most important vs. what the "middle-management" thinks will move the numbers on metrics that the execs care about.
A well-run planning process will result in the right balance being struck. And that IMHO is a rare thing: a well-run planning process, i.e. My $0.02.
I am from the marketing side of things and this seems exactly right about marketing.
But I'm not sure what makes you say this because you did not elaborate.
Then link compensation to OKRs then everybody just focuses on bending the reality to meet the letter of the OKR and nobody is interested in doing their job.
After the "oh shit" moment, we cram everything we do into them.
Then everybody ignores OKRs.
Management insisted on filling my OKRs with low-value 1:N activities - spending time on the forum (full-time forum people were paid to do that), helping sales with technical discussions with customers (field engineers were paid to do that), creating demos/PoCs for marketing (technical marketing engineerings were paid to do that), or being part of one "centre of excellence" or another wasting time in meetings with non-technical people talking about how we were all going to tackle problems when the reality was that no one in the team had the time, talent, or political capital to do any of the things we spent hours discussing.
To me, OKRs seem effective for the workforce in the same way scout badges are effective for children to learn skills - good for those who otherwise would do nothing. The issue is, for intrinsically motivated people who are incredibly specialised in a largely reactive role they are a distraction at best, and when used for quarterly and yearly performance tracking, a detriment to the core role at worst.
(1) It was impossible for anyone to enforce anything. Our genius business development guy couldn't get our head data scientist to share data files with customers (say Big 5 accounting firms) in a way they felt were safe. I couldn't get the data scientists to use standardized versions of Python. (Docker just accelerated their ability to find defective Pythons, such as one with Hungarian as the standard charset) The engineering manager would tell me "we use monads for error handling in Scala" and "we do code reviews" but I don't believe the latter because the first certainly wasn't true.
(2) We were developing core technology and developing solutions for various customers. There was a lot of zigging and zagging and spoiled work in progress. I felt like the customer contact was helping us understand the requirements for the core so I'm not complaining about that. Our management practices should have been focused 100% on squaring that circle.
The VCs believed in our vision and our BD genius (I did!) but they knew we were badly managed and brought in a stream of consultants some of whom were helpful and some who weren't.
The worst was the consultant who came in and forced us all to write OKRs which took two weeks against the core and solution and development work that did matter for the business.
My feeling was that my job was to pull for the team wherever it needed it and it wasn't my business to set goals that weren't fundamentally grounded in the needs of the team. I had enough work to do that I didn't need to add a single task that wasn't on that critical path. Particularly customer requirements could change faster than the OKR cycle, we needed practices that worked at the speed of our business.
I was anxious that when review time came along I'd find that, out of 20 OKRs, I would nail 5 of them, totally fail at 5 of them and the other 10 would be in between. At review time whether this is success failure would depend on politics and ability to navigate politics. That genius BD would deservedly get a good review, a really good coder or data sci may or may not. People with high and unmitigated narcissism are privileged by systems like stack ranking and OKR because they are focused on presentation of self in ways that average people aren't.
Every company I have worked for has not trained their workers for OKRs, KPIs, Scrum, etc. (Well that's not true: Cisco paid for us to have two weeks of Scrum training because our stand-ups were 1.5 hrs long. That's the only reason I know how it's supposed to work) They hire you expecting you know all of that (though never verifying), and then they dump you in the deep end and don't give you the training you need to use it correctly. The end result is nobody uses it right, and the company suffers. And it's complex enough that a pithy clickbait blog post on HN isn't going to teach you how to do it right.
Managers, execs: train your staff. You're only hurting yourself and the company by not doing so.
What both the article and the comments here show is that for most users of OKRs, they don't actually consider the Objective and the Key results to be different. If you consider a key result without considering the objective, then yes, you'll just move a number and nothing more. If you actually try to deliver an objective, and use your KRs to see if you have made progress towards that objective you'll do much better.
That said, I've had to fight many times in my career, even with senior-level product managers, to think about OKRs that way. I ideally ask the engineers that report up to me to care first and mostly about the Objectives their team has taken on, and to care about the KRs second. That leads people to do the right work far more often than having them try to move a specific numerical value above all else.
But there are definitely companies where Staff engineers get to do some awesome work and there's a proper delineation between a Staff and a TL. I'm yet to work in a company like that yet.
The problem with OKRs is that they're another metric, and get gamed and talked about as such. The soft skill of being able to effectively summarize and express the meaning behind list of tasks isn't necessarily going to
So eventually we come to “support the overriding mission”, and record everything we do, and we can retroactively look to see who contributed most.
It will never be who you think
Plus that part is so politically driven you may as well say “elites will reward elites, those with skills will leave if they can find somewhere”
There was that time at one place where it seemed I was the only person who actually put tickets in the ticket system (the product manager never did.)
I was told that every ticket I put in had to have clear value for the consumer and they complained about a ticket to speed up the build. I told them "it has value for the customer because the customer wants the product and could have had it six months ago if we 5x'ed the build speed a year ago"
There's never enough time to do everything that's planned or necessary and OKRs should be the tool that lets you resolve the conflicts. Ship feature X or fix the infrastructure? "X is in OKRs, let's work on X". "X is not in OKRs and we have KR to get Y% success on autodeployments, let's fix infra".
What I definitely don't want is "do OKRs and also do roadmap". The only things that should not be in the OKRs are ones where prioritization is trivial (like "fix critical outages").
Consensus among scholars is that there's no evidence Google thrived thanks to OKRs, in fact it could be said that it thrived despite OKRs.
The goal of this game is to sacrifice long term gains for short term gains; build a house of cards fast to boost your OKR scores and get promoted fast... Then let the next person who is assigned to the project take the blame for the collapse.
People don't care about foundations... Only thing that matters is whose watch the tower falls on. People are literally that ignorant and superficial. It works every time.
Most of the time as the quarter goes on, we then scrap those OKRs anyway because we didn't manage to do them or they were too specific and requirements changed.
I always had the feeling that what we are doing is bullshit. So great to finally hear it from someone else.
I wonder how many engineering companies actually use OKRs though.