Hitting OKRs vs. Doing Your Job
jessitron.com
jessitron.com
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 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.
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.
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.
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
> Just reduce all their responsibilities into a few numbers so they don't have to really understand what's going on underneath 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.
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.
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.
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.
What you really want is: - every team working to improve the customer experience - guided by leadership priorities and initiatives
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.
And in the real world, not even this is true, due to the cost of satisfying OKRs--opportunity cost is one kind of cost, but optimizing an OKR can of course negatively impact other valuable things that aren't represented by OKRs.
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.
I slipped in the catch-all phrase "while maintaining the same quality" for exactly this reason :)
> What you really want is: - every team working to improve the customer experience - guided by leadership priorities and initiatives
What I'm saying is, in some types of organisation the goal-setting process can be how you express the leadership priorities and initiatives
The 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.
(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.
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 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)
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.
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.
But this example I don't completely agree with:
> 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)
I've seen it many times that forcing teams to use the same solution doesn't work as imagined. Often times, teams are solving similar problems. But similarity isn't grounds enough to merge a solution imo. A programming analogy is DRY. Everyone has seen what happens when you take DRY too far.
Some level of management and bureaucracy is necessary. But I think nearly every single company that's ever existed, takes this too far. There are far fewer examples of companies that under manage. I'd argue that all else being equal, under management has less downsides than over management. The reason we don't see companies with too few managers is because of individual interests.
Basically, imagine that a company has the perfectly correct number of managers (contrived example for sake of argument). Then imagine that you can choose to either add or a subtract exactly 1 manager. I am willing to bet that in the vast majority of cases, subtracting the manager leaves the company better off than adding one.
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.
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.
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...
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.
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.
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.
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.
Solved :)
Now we're getting key results.
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
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".
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.
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".
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.
It is not in small (say below 5 people) teams/ organisations. At least not in the ones I worked in.
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.
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.
We measure something because we need something to measure even if it is divorced from reality.
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.
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.
Basically Goodhart’s law https://en.m.wikipedia.org/wiki/Goodhart%27s_law
Any levels of social complexities beyond that has to rely on systems/traditions rather than direct interpersonal relationships.
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.
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.
Also, metrics eventually become the goal and are gamified.
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.
Where are these malarkey-free companies? I've worked at several small companies and they all had all kinds of malarkey.
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.
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.
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.
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.
Sounds good, but how did the "metrics" expose which individual decision-makers were responsible for any improvement or deterioration?
> 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/
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.
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.
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.
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.
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.
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.
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.
I don't want to waste my time and effort on people who don't give a fuck.
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.
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.
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 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.
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.
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.
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.
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.
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.
- 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 :)
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.
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.
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.
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.
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.
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.
There is project-oriented engineering work that lasts for some arbitrary near-term period as well (2 week scrums, or 6 week long cycles in the shape-up world) -- but there is some deep strategic thought given to overarching design, etc. that I think the original post was talking about. Those don't fit neatly into OKRs and I buy that.
I would think that some marketing work is project-like but there have to be things that are more strategic in nature... Things that have impact beyond a quarterly campaign, etc.
That's where I was coming from. Feel free to disagree. Would love to get your take. :)
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.
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”
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
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").
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"
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.
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.
(1) Do bang up, really good word, save/make major improvements in the work of the organization.
(2) Thus, fully unintentionally scare the management (afraid of being upstaged, shown up) all the way to the top.
(3) Have the scared management arrange to fire you.
Response: Find a market need can meet with own resources (e.g., think of a new Web site, get some computing equipment, write the code, go live on the Internet, get some publicity, users, and ad revenue, entertain buyout offers), be the first level worker and also the manager and owner. Basically, if get good revenue, can't get fired, e.g., can't lose your job.
Experience examples:
(1) In high school plane geometry, in class mostly slept, refused to admit doing any of the assigned (too simple) homework, but there were some more difficult exercises in the back of the book so made sure I did ALL of them. One took me Friday to Sunday evening, and on Monday in class the teacher had the class work on an easy exercise with the same figure, so for the only time I participated said "There's an exercise in the back with the same figure ...". For about 20 minutes the class and teacher struggled with increasing frustration but no success. Since I didn't want to be accused of wasting the class time, said "Why don't we ...", and the teacher interrupted, spoke over me, wouldn't let me finish the suggestion, and said with anger "You knew how to do it all the time." Of course, wouldn't say anything otherwise. Point: The main goal was to learn some plane geometry which I was doing apparently quite well but got anger instead of praise.
(2) At the end of the class, there was a State achievement test. The last problem was "What is the first step in using construction to inscribe a square in a semi-circle." I didn't get it so after the test kept working on it until I did. My solution was first to construct something easier: Construct a square of whatever size, circumscribe a semi-circle, thus, have a figure similar to the desired one but of the wrong size, construct a 4th proportional to get the needed length in the given semi-circle. Constructing the second figure looked novel, not from the course, so after school asked the teacher if that was okay? She said "No, but why are you working on that?" Later I discovered that I'd reinvented similitude, actually taught in some more advanced material. Point: The main goal, even beyond what was in the class and book, was to make progress, even invent, in the subject. Again the from the teacher I got contempt instead of praise.
(3) Working in a time-sharing company, my job was the math library. The FFT (Fast Fourier transform) was a hot topic, and I got fairly deep into it, along with the related Blackman-Tukey power spectral estimation, dropping the assumption of number of samples a power of 2, etc. The manager's remark was "You tend to pick the bones clean" and fired me. Point: The main goal was to please the customers, and having a better software library in the FFT hot topic was a part of that. So, from doing admittedly exceptionally good work, I got fired instead of promoted or even keeping my job.
(3) After the FFT work, got hired as helper of users of a university computer center. As a tool for teaching some statistics, a prof had written a main program to call the statistics routines in the IBM SSP (scientific subroutine package). In testing he found that two of the routine were slow (for integer n points of input ran in time proportional to n^2) and for polynomial fitting (via a method that led to the notoriously ill conditioned Hilbert matrix) gave numerically inaccurate results. So, for the two n^2 cases, I found tricky ways to use the n(log(n)) heap sort without using more storage (did some tricky overlay, reuse of the storage in the passed parameters) and for the polynomial case used some Forsythe and Moler work to get better numerical accuracy. To do this, some days I worked late, and the head of the computer center said critically I hear that you have been working all hours of the day and night" and fired me. The Dean of the business school kept me on to teach courses in computer science. Point: Again the main goal was to have better software, better than the prof wrote, to have a better computer center, and my work, improving on what the prof and IBM had done, was exceptionally good work, but I got fired instead of praised.
(4) At FedEx, the BOD was seriously* (funding at stake) concerned about scheduling the fleet. At a meeting to see how to respond, no one had any ideas, so I said I'd solve it. I had some ideas, wrote the code, ran the code, pleased the BOD, saved the funding and the company, and got an angry manager who tried to get me fired. The founder, COB, CEO got me a Senior VP as a new manager; I did some better work on scheduling the fleet, and the VP's response was "there no money in the budget for you", and wanted me fired. The promised stock was very late, and I went for a Ph.D. in such applied math. Later FedEx worked with a prof and a grad student and implemented, as a Ph.D. dissertation, my scheduling idea (0-1 integer linear programming set covering). While reporting to the VP, I pleased again the BOD and saved the company. Point: So, I had saved the company twice, and the new scheduling proposal in effect directed a dissertation, i.e., it was good work. But the two managers both tried to fire me and there was no stock and no money in the budget.
(5) Later in a major AI project, there was a big problem with the design and code. The team had a crude solution in mind, that would take weeks of coding and at best would not be very good. So, I had an idea, got a pizza, worked all night, and had running code for a nice solution. I got an award from my manager, but from the rest of the management chain soon I was fired. Point: I'd done novel, good work, saved the AI project, but got fired.
There are a few more examples.
Old quips: "No good deed goes unpunished." "The nail that sticks up gets hammered down." "Don't rock the boat."