[HN Gopher] Hitting OKRs vs. Doing Your Job
___________________________________________________________________
Hitting OKRs vs. Doing Your Job
Author : zdw
Score : 333 points
Date : 2025-01-06 04:19 UTC (18 hours ago)
(HTM) web link (jessitron.com)
(TXT) w3m dump (jessitron.com)
| gbin wrote:
| "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.
|
| Then everybody ignores OKRs.
| osmsucks wrote:
| The most insulting case is that of the retroactively-adjusted
| OKR wording so that you can always meet 0.7+ scores.
| szundi wrote:
| I remember when reading about Intel and OKRs in every
| management execution book. I thought that's the time to sell
| the stock.
| Aromasin wrote:
| 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.
| PaulHoule wrote:
| 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.
| friendzis wrote:
| Goodhart's law is an adage often stated as, "When a measure
| becomes a target, it ceases to be a good measure".
| blueboo wrote:
| 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!)
| friendzis wrote:
| I'm being humorous here.
|
| 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.
| zmgsabst wrote:
| I'm not sure I've heard it summarized that way before: that
| good process causes good metrics, but good metrics don't
| cause good process.
|
| People are indeed prone to affirming the consequent.
|
| https://en.wikipedia.org/wiki/Affirming_the_consequent
| mrayycombi wrote:
| https://blog.appliedcomputing.io/p/okrs-are-bullshit
| padolsey wrote:
| 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.
| friendzis wrote:
| 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.
| qznc wrote:
| 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.
| paganel wrote:
| > How do you know if you are doing that?
|
| You don't, as an individual "unit", which is part of the
| problem, i.e. modern management's focus in trying to split
| teams/big companies down to its "elementary" unit, the
| employee.
|
| > Not having metrics means it all depends on the gut feeling
| of executives.
|
| And that's why you need good executives, executives who have
| good guts. You cannot automate your way into being
| successful, at the end of it all running a company is still
| pretty much a social endeavour, one that cannot be
| partitioned down to individual units, neither can its success
| or failure be explained by those individual units alone.
| 0xEF wrote:
| 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.
| paganel wrote:
| 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.
| msoad wrote:
| 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...
| parpfish wrote:
| 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
| jghn wrote:
| 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.
| devjab wrote:
| > 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.
| philjohn wrote:
| 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.
| michaelt wrote:
| 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.
| ricardobeat wrote:
| 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.
| DanielHB wrote:
| 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.
| aflukasz wrote:
| > 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.
| exe34 wrote:
| 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.
| michaelt wrote:
| _> how do you come up with 25% goal?_
|
| 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.
| liontwist wrote:
| 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
| madeofpalk wrote:
| > it was always a metric closely aligned with what
| customers want
| liontwist wrote:
| All OKRs help customers, but not all customer help meets
| an OKR.
|
| Finding and fixing product problems requires
| decentralized decision making and trust.
| DrScientist wrote:
| Indeed.
|
| 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.
| zeroonetwothree wrote:
| You might want to read "The Nature of the Firm", which
| discusses this.
| DrScientist wrote:
| 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.
| liontwist wrote:
| That's an easy one to answer.
|
| 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
| DrScientist wrote:
| > 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?
| aurareturn wrote:
| >Finding and fixing product problems requires
| decentralized decision making and trust.
|
| Which is exponentially harder in a large company - hence
| why OKRs are invented.
| makeitdouble wrote:
| Parent's point is that customers want more than single
| metrics, and the metrics you leave on the side to
| priorize the OKRs can be as critical.
|
| 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.
| liontwist wrote:
| 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._
| devsda wrote:
| > fix it themselves without anyone asking - bring it up
| to higher management
|
| No matter what your intentions are, doing this frequent
| enough will give you reputation of being a lonely wolf
| and trouble maker.
| liontwist wrote:
| I'm sorry that's your experience.
|
| 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.
| marcosdumay wrote:
| 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.
| michaelt wrote:
| _> And then customers complain that the driver is
| frequently crashing and the team is well aware but won't
| fix_
|
| I slipped in the catch-all phrase "while maintaining the
| same quality" for exactly this reason :)
|
| _> What you really want is: - every team working to
| improve the customer experience - guided by leadership
| priorities and initiatives_
|
| What I'm saying is, in some types of organisation the goal-
| setting process _can be how you express the leadership
| priorities and initiatives_
| InsideOutSanta wrote:
| "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.
| blased wrote:
| best explanation I've seen, this describes the org I'm at
| cnotv wrote:
| This literally applies to everything in this world except
| global warming :D
| PaulHoule wrote:
| $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.
| ericd wrote:
| 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.
| marcosdumay wrote:
| 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.
| PaulHoule wrote:
| Exactly. Somebody should be able to capture carbon and
| get a rebate from that.
|
| 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.
| dowager_dan99 wrote:
| 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!
| PaulHoule wrote:
| 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)
| yellow_postit wrote:
| 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.
| InsideOutSanta wrote:
| 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.
| rybosworld wrote:
| 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.
| mandevil wrote:
| 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.
| InsideOutSanta wrote:
| 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.
| mandevil wrote:
| 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.
| geewee wrote:
| 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
| aidenn0 wrote:
| > 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.
| rqtwteye wrote:
| "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.
| stevenklein wrote:
| 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.
| rqtwteye wrote:
| 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
| pbhjpbhj wrote:
| Do they "not trust" or do they not have a clue whether to
| trust them?
| rqtwteye wrote:
| The result is the same. If a manager can't judge whether
| their employees are trustworthy they are not competent
| for the job.
| JALTU wrote:
| 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?"
| nradov wrote:
| 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.
| InsideOutSanta wrote:
| 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.
| rescbr wrote:
| > 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...
| burningChrome wrote:
| Was at a company for ten years and same thing.
|
| 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.
| mysticllama wrote:
| 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.
| InsideOutSanta wrote:
| "you want me to leave the main app feed broken"
|
| 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.
| kridsdale1 wrote:
| I worked on Facebook News Feed for a number of years. I
| wonder if we were coworkers. This is what it was like.
| macspoofing wrote:
| >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.
| PaulHoule wrote:
| 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.
| JALTU wrote:
| 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.
| haolez wrote:
| "KR #3: the amount of bugs reported by users must not
| increase from our baseline"
|
| Solved :)
| jayd16 wrote:
| Replace the bug report system with a maze of menus so as
| to reduce the reports.
|
| Now we're getting key results.
| Spooky23 wrote:
| Policy: "Bug reports are only accepted once they are
| validated and fixed"
| haolez wrote:
| 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).
| gosub100 wrote:
| > 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
| beAbU wrote:
| > a metric closely aligned with what customers want and which
| drives revenue for the company
|
| My experience says these two things are often mutually
| exclusive.
| hobs wrote:
| Add a meta rule - only pursue revenue sources that make
| both of you money - that's called being a good company.
|
| Many people will say I am leaving stuff on the table, and I
| say that they are literally parasites.
| PaulHoule wrote:
| 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.
| cpeterso wrote:
| That matches Bill Gates' definition of a platform:
|
| _" A platform is when the economic value of everybody
| that uses it, exceeds the value of the company that
| creates it."_
| stevenklein wrote:
| 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".
| jayd16 wrote:
| 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.
| michaelt wrote:
| _> You actually probably don 't want just 25% more, you
| probably want 30hz or 60hz or VRR support and you don't
| care about going from 92 to 118._
|
| Then someone probably ought to tell the GPU review
| industry, because for the past 20+ years FPS on current
| popular games has been a key focus of their reporting :)
|
| I count 462 mentions of fps in
| https://www.tomshardware.com/reviews/gpu-
| hierarchy,4388.html
| jayd16 wrote:
| 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.
| nine_k wrote:
| > _from 92 to 118_
|
| Or maybe yes; 120 Hz gaming monitors are a thing, and give
| some advantage. You probably want to target something like
| Doom Eternal, not BG3 though.
|
| As you see, it all depends on _who is your customer_ , and
| then _what matters to your customer_. This is the closest
| proxy to the company 's bottom line, and usually is not as
| fickle.
| jayd16 wrote:
| 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.
| marcosdumay wrote:
| That's a product OKR, not a personal OKR.
|
| Yes, product OKRs can work, as long as you listen enough to
| feedback. In fact, you probably can't ever creating anything
| good without them. But I don't think most people even call
| them "OKR".
| jhghikvhu wrote:
| > 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.
| aiizo wrote:
| Yes but this being made into a formal process and having to
| regularly interact with that process is what's so draining.
|
| Not having to deal with this is one of the positives about
| working in a small startup versus a long-established large
| corporate.
| Lionga wrote:
| In big teams you are right it almost is inevitable.
|
| It is not in small (say below 5 people) teams/ organisations.
| At least not in the ones I worked in.
| sunshowers wrote:
| 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.
| robertlagrant wrote:
| > 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.
| Izkata wrote:
| They've always been closely related. The "KR" in OKR is "what
| is the new target for the KPI in order to reach O?"
| theGnuMe wrote:
| The FB suicide risk detector OKR is an interesting example.
| It'd make a great business school / psychology case study.
|
| We measure something because we need something to measure even
| if it is divorced from reality.
| QuadmasterXLII wrote:
| 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.
| TheBigSalad wrote:
| At FB would the 'boots on the ground' devs be required to do
| OKRs? Or were they done at the team or manager level?
| fsociety wrote:
| 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.
| zeroonetwothree wrote:
| 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.
| loloquwowndueo wrote:
| > you've effectively produced a metric that is completely
| distinct from the thing you intended on measuring in the first
| place
|
| Basically Goodhart's law
| https://en.m.wikipedia.org/wiki/Goodhart%27s_law
| dfxm12 wrote:
| 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.
| roland35 wrote:
| 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...
| eweise wrote:
| 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.
| PaulHoule wrote:
| 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.
| eweise wrote:
| 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.
| nedrocks wrote:
| 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.
| MortyWaves wrote:
| 80 seems like a specific number
| 98codes wrote:
| 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.
| eweise wrote:
| "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.
| jorblumesea wrote:
| 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.
| burningChrome wrote:
| Interesting take.
|
| I believe there is some truth to what you're saying. My
| experience was slightly different where all the devs were
| working together, nobody "owned" an entire domain. Mainly
| because if a dev left, we needed to have someone else on the
| team capable of picking that up and move forward without
| everything falling apart because we had a chokepoint on
| something because one dev held all the keys to it.
|
| But it was the same thing, the sense of everybody working for
| a common goal, and devs never judging each other. We found
| ways we complimented each other in order to be more
| efficient. There were times when you really did feel your
| worth as a dev and all those sort of romantic ideas of what
| being a dev was? And there you were, living it every day and
| being super proud of working shoulder to shoulder with some
| very talented people who saw you just as talented as they
| were.
|
| Big Corp? 100% spot on with your observation. Its a fucking
| shark tank and at times, I felt like I was in a mosh pit.
| fighting off other devs, over zealous project managers trying
| to get me to do stuff that would make them look good,
| directors who constantly cut corners to make themselves look
| better at the cost of your bonus and promotions. Add in the
| abnormal turn over and feeling like I never had any stability
| on any of the teams I was on, I just never felt like I fit in
| anywhere. It was very high school stuff I didn't want to deal
| with.
| deepsun wrote:
| 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.
| epolanski wrote:
| > Every single time an element of human activity is reduced to
| a metric, you lose something
|
| Also, metrics eventually become the goal and are gamified.
| treetalker wrote:
| I think Laozi and Zhuangzi had something to say about this.
| sunshowers wrote:
| 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).
| lumost wrote:
| 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.
| lifeisstillgood wrote:
| 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"
| lifeisstillgood wrote:
| 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...
| qprofyeh wrote:
| 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.
| Cthulhu_ wrote:
| 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.
| wesselbindt wrote:
| > it's a big disruption and it's costly so it's not done
| lightly
|
| Isn't this the very definition of not being agile?
| robertlagrant wrote:
| It's what the consulting class invented to lift the power
| that agile places in individual teams back up to
| management.
| xtracto wrote:
| Engineering OKR: Make system like more stable and with less
| bugs.
|
| 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.
| ozim wrote:
| 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.
| throwawaysleep wrote:
| 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.
| ibejoeb wrote:
| >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.
| praptak wrote:
| 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").
| SteveVeilStream wrote:
| 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.
| AndrewSChapman wrote:
| 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.
| WXLCKNO wrote:
| 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.
| zoul wrote:
| Yes! Instead of data-driven management, I believe in
| conversation-driven management. Frameworks such as OKRs are a
| way to spark helpful conversations.
| maayank wrote:
| Or, you could have these conversations without OKRs?
| ghaff wrote:
| 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.
| tyleo wrote:
| 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.
| rfdearborn wrote:
| Yeah: the value of (good) OKRs is as a proof of work for the
| process of aligning teams' vectors with business objectives /
| each other.
| justinl33 wrote:
| 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'
| michidk wrote:
| 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.
| rednafi wrote:
| I call it planning palooza. It keeps a ton of people employed
| though.
| brcmthrowaway wrote:
| What does OpenAI or Anthropic use?
| zelphirkalt wrote:
| 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.
| robertlagrant wrote:
| 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.
| marcosdumay wrote:
| Nah. What gets excluded is a function of management style.
| But that most important things are excluded is an inherent
| feature of OKRs.
| rednafi wrote:
| 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.
| lrog wrote:
| 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?
| rednafi wrote:
| 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.
| zeroonetwothree wrote:
| Really depends on your priorities. For me I'd rather do 'good'
| work (or 'interesting' work to me) since I don't care about
| minmaxing my comp.
| rednafi wrote:
| Same and got stuck in the eternal loop of SE.
| azemetre wrote:
| Also if you are going to job hop in less than 3 years there's
| much less reason to play the corpo game.
| doppp wrote:
| I still chuckle when I recall this tweet, "OKRs were actually a
| psyop from Google to slow down potential early stage competitors"
| [1].
|
| [1] https://x.com/benwbear/status/1543056694330003456
| PaulHoule wrote:
| That's what I told the managers at one startup when they
| brought in a consultant to introduce OKRs.
| marcosdumay wrote:
| I imagine React was the Facebook version of this.
|
| 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.
| wavemode wrote:
| Funny - I used to make this same joke about Kubernetes.
| DanielHB wrote:
| 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.
| liontwist wrote:
| 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.
| DanielHB wrote:
| > I think business people understand the value of setting
| high level goals and giving autonomy to accomplish them.
|
| I think a lot of business don't, at least on the lowest
| levels of the org chart.
| chasd00 wrote:
| > 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.
| 0xbadcafebee wrote:
| 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.
| PaulHoule wrote:
| I love _Out of the crisis_ by Deming and _Some theory of
| sampling._
| 2OEH8eoCRo0 wrote:
| I worked at place that did this. They had screens of plant
| output everywhere so everyone knew how they were doing. It was
| unavoidable.
|
| At a factory it's easy to know how many widgets were made. It's
| tricky with software.
| 1970-01-01 wrote:
| >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.
| everybodyknows wrote:
| > who could save more money
|
| Sounds good, but how did the "metrics" expose which individual
| decision-makers were responsible for any improvement or
| deterioration?
| muzani wrote:
| 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.
| vegetablepotpie wrote:
| 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.
|
| [1] https://commoncog.com/deming-paradox-operational-rigour/
| msluyter wrote:
| 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.
| Afforess wrote:
| Majesty I & II were implemented like your idea of this
| game...
| jtbetz22 wrote:
| 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.
| steveBK123 wrote:
| 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.
| m463 wrote:
| okr: reduce parts count
|
| me: Tesla,I want a car with turn signal and drive selector
| stalks!
| Schiendelman wrote:
| Has the new UX bothered you when using it? I got used to it
| in a day and it seems fine.
| m463 wrote:
| how has quickly reversing to get a parking spot in moving
| traffic worked for you?
| steveBK123 wrote:
| 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.
| frenchtoast8 wrote:
| 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.
| steveBK123 wrote:
| 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...
| crispyambulance wrote:
| > Phoenix Project
|
| 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.
| robocat wrote:
| patio11 makes some other suggestions for similarly good
| books:
|
| https://bitsaboutmoney.com/archive/fiction-about-finance/
| dent9876543 wrote:
| 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.
| dakiol wrote:
| 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.
| kubb wrote:
| 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.
| nine_zeros wrote:
| 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.
|
| So why would you care? You sound rational to me.
| prh8 wrote:
| 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.
| aoeusnth1 wrote:
| That's why I don't hire people with resumes like yours :)
| bdangubic wrote:
| exactly - resumes like this are immediately discarded... you
| would REALLY want to get a job where I am at, REALLY :)
| tekno45 wrote:
| because you want someone who won't ask for a raise.
| bdangubic wrote:
| 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
| crowcroft wrote:
| 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.
| indymike wrote:
| 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.
| jongjong wrote:
| 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.
| keeptrying wrote:
| If you work in a big company,
|
| - 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 :)
| naasking wrote:
| 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?
| 0xbadcafebee wrote:
| 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.
| theptip wrote:
| 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.
| joegoober wrote:
| 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.
| gdubs wrote:
| 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]"
| jayd16 wrote:
| Was it ever a good idea? Even when I bend over backwards to
| treat the process as earnestly as possible, it feels like silly
| dance, corporate kabuki.
| gdubs wrote:
| Honestly? I don't know! The central idea of "measure what
| matters" is good if you actually do the meaningful soul-
| searching involved.
|
| But most good ideas can turn into just a lot of rules and
| process to follow over time.
| PaulHoule wrote:
| 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"
| epolanski wrote:
| It should be noted that as of today no single study on the OKRs
| demonstrates any value in them.
|
| 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.
| dogman144 wrote:
| 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.
| maayank wrote:
| 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)
| curious_cat_163 wrote:
| > 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.
| jklinger410 wrote:
| > I am from the engineering side of things but this does not
| seem right about marketing...
|
| 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.
| tetha wrote:
| 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.
| shusson wrote:
| 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.
| dimgl wrote:
| > because said start-up is about to fail.
|
| How come?
| doawoo wrote:
| 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.
| awkward wrote:
| 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
| jjslocum3 wrote:
| Are people still talking about OKRs? Dang that's so '00s
| crest wrote:
| I read it as "hitting orcs vs. doing you job". Maybe I should
| read less war reports.
___________________________________________________________________
(page generated 2025-01-06 23:00 UTC)