Hacker News Reader

Comment by _heimdall | Hacker News Reader

I'm been really frustrated by OKRs specifically. The whole system does a great job of appearing to empower a bottom up approach while actually being implemented as a top down, authoritarian system.

It sounds great to be metric and goal driven, allowing employees to decide for themselves how to best reach those business goals. I've never seem it implemented this way though. Instead, I've seen leaders define goals and solutions together, paired with a list of metrics used to define success so specifically that annual reviews and layoffs become an almost mathematical, robotic process.

View on HN

I always found it really interesting at Google that OKRs generally seemed to make sense at the CEO & PA level, but massively broke down somewhere between VP->Dir->Team level, to the extent that for the majority of teams it was nearly impossible to identify clear OKRs for themselves that trickled down (or flowed up) to the OKRs that should have been inheritable by their management chain. Some orgs manage to get to the Director level, but in others the break happened at the VP level, which just meant that entire large groups of Type A, highly productive people were mostly rudderless -- not to mention being at risk of poor performance reviews if their management chain weren't able to provide adequate air cover.

I always wanted OKRs to be flipped to a bottom up approach. Let every employee or manager define what's most important to them, or their team, and how they'll measure success. As it goes up the chain, managers and ultimately the CEO are responsible for taking all those goals rolling up to them and craft it into a plan or business direction.

Effectively crowd sourcing your business from all of your employees. Of course you have to actually trust and respect a majority of your employees which really makes it a non-starter for most high level leadership.

So, exaggerating, the CEO would be responsible to craft a business direction from this set:

    - publish more as open source,
    - migrate to novel:
      - libraries
      - frameworks
      - architectures
      - paradigms
    - small refactoring that hugely improves elegance and readability,
    - big refactoring that barely improves anything,
    - add an impressively-sounding feature, sponsored by letters C, R, D and T
    - ...in Rust

I'm not saying it'd be easy, or that it'd scale to a massive company, but then I don't think we should have such massive companies which is another discussion.

The examples you give are more like every employee getting to decide what they feel like working on. The idea would be for employees, as the ones almost always closest to customers, to define what they see as mattering most.

You have to remember that OKRs aren't just tasks. Ideas from the bottom up would include what they see as most important along with why its important and how success will be measured.

All of the examples you gave could be great examples if they are complete. Publish more open source to break into a new market or improve code maintainability. Migrate to a new library to fix long standing performance issues or unlock a new feature set. Redactor for readability to reduce code review time or speed up new feature development.

Other, more customer focused, examples could be to improve docs to reduce customer churn or improve discoverability for new users. Maybe you help in a support channel on Slack or Discord and find a ton of users asking for some specific integration, its very easy for you to see that pattern but hard for someone at the top to see it or assign it value.

Pushing down orders from the top is easier, and better at stoking ego. Hiring and developing your team well so you can honestly take their recommendations and craft the next 6 months of marketing or define a new product direction that ties together what your team has seen is much, much harder but an amazing strategy if done right IMO.

My examples were more like every employee getting to decide (cynically, individually) what's best for them.

Your examples are where every employee figures out (altruistically, collectively) what is best for the CEO.

Breaking the symmetry, CEO in both cases decides what's best for the CEO (officially "best for everyone", but in fact you are only counted as "everyone" if you are an employee who is contributing to what's best for the CEO).

I admit that your proposition could very well work fine. Many people do love to get into the shoes of higher-ups.

That also just doesn’t make sense to do because most employees don’t understand the business and are terrible at defining OKRs.

They probably aren't good employees then, honestly. My scenario here is entirely dependent on leaders trusting their reports, if that isn't possible then at best they can try to force objectives down from the top.

I'd argue that still won't work, and in my experience it hasn't. Id your employees don't understand the business or aren't good at defining goals, you've failed them as a leader. Maybe they shouldn't have been hired, though I'd argue they have been poorly managed and put into roles that don't fit their skills and interests.

The model I was talking about here would be flipping the script entirely though. There wouldn't he a chance for someone to misunderstand the business. Leaders' entire task is taking what their reports' priorities are and unifying a vision and business plan from that (recursively until you reach independent contributors). Employees can never misunderstand, leadership can only misunderstand their employees.

> They probably aren't good employees then, honestly.

This is incredibly naive. Even in single product companies you can have excellent employees (e.g. a CNC machinist) who don’t know anything about the pricing, regulatory, and legal aspects of the company.

At my last company, managers success was defined by their reports success, so if we didn't achieve our KPIs by the end of the quarter, my manager would say "You worked really hard this quarter, and I want to make sure you get your full bonus!" then he would just lower the KPI metrics until we achieve ~80% of them (because our CEO believed if you are achieving more than 80% of your goals, then your goals aren't ambitious enough)

We're explicitly given top-down OKRs, which we're required to align our own "bottom-up" OKRs to, and then we're not empowered to meet our own OKRs, because product management alone steers the ship.

That's how I've often seen it implemented as well. There's absolutely no point to OKRs when used that way, I assume its a sign that someone pushed through a big change in the name of efficiency and got a nice promotion out of it without anyone checking to see if it actually helped.

Reply on news.ycombinator.com