Hacker News Reader

> what you wanted probably wasn't on this quarter's OKRs so it would be an uphill battle to get them to do it

Everywhere I've ever worked - OKRs or DPMs or Goals or whatever you want to call them or not - I've had a set of work that's assigned to me via JIRA tickets or Bugzilla tickets or some kind of ticket tracking system, and I've also had a constant deluge of co-workers asking for my help with something or other. The longer I work there, the greater the deluge of both requests for help and volume of work assigned. Every day I've ever come into work in my life (besides the one-two month "honeymoon period" when I start a new job), I have to decide between ignoring my coworkers pleas for help or slipping the deadlines on the individual tasks assigned to me.

Over the course of the past three decades, I've tried both ways - first, focusing on my assigned tasks and second, dropping everything every time I get a request for help. I've found that, overall, the second way works best. I have to constantly apologize for constantly missing deadlines, but if I keep turning away coworkers, not being enough of a "team player" shows up as a nastier mark in my performance reviews than always being behind on tasks.

One way I deal with this is having co-workers also create tickets if they need help with something. That way I can still be a team player but there is also documentation about how much I helped which is otherwise hard to quantify.

I've tried that approach, too - for the most part, the blowback is the same as just ignoring them or even telling them to go away. Sadly, success is and always will be 10% ability and 90% how much people like you.

> 1. It makes organizations slow and inflexible. I used to joke that as soon as another team was involved in something you needed to do it would probably take a quarter. why? Well what you wanted probably wasn't on this quarter's OKRs so it would be an uphill battle to get them to do it. You'd have to argue about getting it into next quarter's OKRs;

This. It's not a joke either. At a previous job, we wanted to use the G Suite API to access calendar data from GCP, but that required help from the Info Sec and Cloud teams (we didn't have the right permissions to do it ourselves). We got push back for asking for help because it wasn't in those teams' OKRs. So we effectively gave up for an entire quarter and then some.

Even so, how does one write an OKR for a scenario like this? Objective: be able to access GSuite API from tool Foobar so it knows about everyone's availability. Key result: Umm, can complete a feature everyone wants?

What's worse is when that team gets around to it next quarter, and then in their research process they realize another team needs to be involved, etc. Eventually you have a two-week project that doesn't get delivered for a year.

But this does reveal an organizational problem right; either the security teams have it right and their current work is more important, in which case maybe they are under-staffed and need more slack. Or maybe they failed to add a KR for “perform timely security review” if that is a service that they provide to the org. If you’re blocked, you should be able to raise this up and learn something as an org.

Or maybe the KRs are correct as written, but the security teams have it wrong and their KRs should be deprioritized only favor of delivering yours. When KRs clash you need to have a conversation and resolve the conflict in the way that maximizes value for the business.

Ultimately prioritization of work always involves trade-offs, and there needs to be some mechanism for handling these. No system can handle 100% of cases without adding human judgement.

To me it seems the pathology in your example is that everyone was just sticking to the KRs, instead of coming to the best business outcome (and if your request was not prioritized, you should be able to understand the reasoning used to decide that). I can see how OKRs could be used as a shield to hide from those difficult conversations, but it’s not clear to me that they necessarily make things worse; if you didn’t have OKRs maybe your teams would be finding other ways to avoid working on things that they don’t want to help with.

Putting this in a separate reply as it's a separate train of thought.

> Even so, how does one write an OKR for a scenario like this? Objective: be able to access GSuite API from tool Foobar so it knows about everyone's availability. Key result: Umm, can complete a feature everyone wants?

The key thing about an objective is that it is a high-level goal. You've written the implementation into the O, which is a bit of an anti-pattern.

It's a bit hard to extrapolate exactly what the context was for your feature, but let's say your team owns an internal tool that orchestrates a business ops system that manages a task queue for "agents"; say "review these potential fraud cases that the system flagged".

As this is an existing system that you're trying to improve, not a new product, your team's objective for the Q might be attacking the main stakeholder-facing pain point with "Improve response time for manual review tasks". A KR that measures this might be "P50 latency for handling fraud reviews is reduced from 5d to 1d". (This formulation gives you a progress bar -- "0% complete" is >=5d, "100% complete" is <= 1d. You can easily build a dashboard for this, which is the holy grail for KRs.)

Now, based on the observation that most of your significant delays for this process are due to tasks being scheduled on agents that are on vacation, an initiative that you propose to progress the KR is to add calendar-awareness to your service's scheduling process. But, there are a bunch of possible initiatives that could move the needle here, and so as a team you get together and figure out which are going to have the best bang-for-buck.

Formulating the OKRs like this gives the team freedom to figure out exactly how they are going to solve the problem, while also communicating to the rest of the org what you're working on (and giving the org a chance to say "isn't <other objective> way more important?". And turning the implementation into a precise KR gives you the opportunity to discuss with stakeholders whether P50 is really the metric they care about, or if the business would be better served with P99 or some other way of measuring things. These metric discussions can be annoying, but at their best they can uncover subtle differences in expectations.

Note -- this is quite process-heavy; you wouldn't go into this much detail with a two-pizza-team startup! But if your team is dedicated to this internal tool in a company of tens of teams, then this level of detail might make sense for you.

For sure #1 is a big problem. But are OKRs causing this, or are the big companies that are using OKRs just fundamentally slow and inflexible? (In other words, are OKRs a symptom rather than a cause?) Thinking about how to coordinate 100k engineers, the trade-offs are pretty brutal. Startup-style “move fast, break stuff” simply doesn’t scale well.

I’d like to see some case studies here. Anyone got examples they like? I hear patio11 talking about Stripe a lot, and he says stuff like “could we deliver something faster?” which I think gets at an urgency for results, interested how they coordinate the layers and orgs.

I think it’s plausible that OKRs forestall agility and innovation as-used. But (at risk of invoking the “no true Scotsman” argument), maybe these companies are just doing OKRs wrong? OKRs are supposed to be abstract enough that you can change your plan if something better comes along. So if your KR is tightly coupled to a particular implementation then you can’t pivot in the face of new information. A quarter is a long planning horizon for small/medium sized companies! But if your KR is loosely-coupled, then it leaves room for new approaches. This balance is hard! The maximally-loose O/KR for many companies is just “succeed/increase share price by X% QoQ”. This doesn’t give you any direction.

I think at their best OKRs provide bi-directional information flow; both giving a way to make output from the lower levels more legible to the upper levels, while also making the objectives, desires, priorities of the upper levels more legible to the lower levels. I think any replacement has to achieve both of these things too.

#1 is a real issue, but is actually a problem of management and company as a whole. Teams want to be silo-ed and not bothered by anyone else hence set their goals and just do them, engineering managers just care about their teams or don’t even communicate between them to check for cross team projects, and upper management never sets some actual objectives and roadmap which could have been mapped into cross team projects and goals. And goals become a religious quarter to quarter thing without allowing any deviation, and then everything is slow.

> This might be useful for directors+ but is really a waste of the time of 50-100 other people. This is a problem with status meetings too;

A status meeting serves to reinforce the social status of the one who called the meeting. No other status is relevant.