About OKRs

OKR stands for "objectives and key results". I believe this is pretty standard lingo in larger tech companies (and possibly other industries) describing a process/deliverable/trackable/measurable/accountable/assignable thing that most employees have to participate in or work with.

I think it's also one of the things that sucked the joy out of working at Google. Or maybe OKRs were just a symptom of a larger underlying problem that did that.

I'll start by painting the picture a la "the road to hell is paved with good intentions." You are the CEO of Big Tech LLC, a publicly traded company with a market cap of 1 trillion USD. Per the SEC, you (on behalf of Big Tech) are responsible for reporting on the company's earnings each fiscal quarter, and answer to the representatives of the shareholders, the Board of Directors. Generally shareholders become shareholders because they expect the company's valuation to grow, and have high expectations for earnings reports.

Because you have this high stakes quarterly presentation to do, it makes sense to track, company-wide, all the things we're planning to launch, ship, land, deploy, sell, etc. on a quarterly basis. This will help you provide guidance on expected earnings and company performance for the next quarter in your presentation. So you tell your VPs, "Hey, let's do this planning thing where your org figures out exactly how much head count is dedicated to different tasks... and let's organize those tasks into categories which align with Big Tech's overall mission. Uhh how about we call those tasks 'key results' and these categories 'objectives'?" So your VPs go to their direct reports, and so on, until everyone is busy fitting everyone's work into neat little KR packages, and accounting for everyone's time spent in a quarter.

At first glance, this doesn't seem too bad right? Doable, useful, shouldn't take too much time?

The Problem

Turns out, time estimation in software engineering is mostly bullshit. A cursory web search for "why are estimates always wrong in software" will turn up a bunch of articles asserting this fact and offering explanations for why this is the case. The Mythical Man-Month by Fred Brooks tells a similar story of how the SWE-hour unit doesn't scale linearly: a project will not necessarily complete twice as fast if twice as many engineers work on it.

Unfortunately, these complications don't fit nicely into the OKR structure, and so engineering managers spend extra time cutting up projects into story points, or milestones which factor in extra time for unforeseen obstacles in the course of development, all to put something down in the OKR tracker that can reasonably be started and finished within a quarter.

Oh by the way, your completion (or lack of completion) of your assigned OKRs is likely to factor into your annual performance review, and compensation for next year.

I mean, this makes sense right? Your ability to deliver these KRs should be a good proxy metric for your productivity and contribution to the company right? And presumably, these KRs are representative of the most important and impactful things you could work on at the company?

Aside: I remember managers on my team having multiple hour long meetings to comb the backlog to prioritize and assign work, and possibly a meeting to plan the planning of the OKR process for the next quarter. I got the impression that as soon as, say Q1 OKR planning was done and everything was assigned to ICs, they were already starting planning for Q2 OKRs.

The importance of the KRs, and the uncertainty surrounding any project in software combine to add a lot of friction to proposing and working on large projects (basically those that take longer than 1 quarter to finish, with more friction as your timeline extends further). Larger projects generally need more detailed, lengthier design documents, more meetings with stakeholders, more prototyping, more dissent farming, and that's all without any consideration for how to fit the project into the quarterly prioritization of KRs and chop it up so one can give a reasonably good score for work done at the end of each quarter.

About site reliability engineering

There's a compounding issue here specific to my team's domain at Google: site reliability engineering, in the realm of dev ops and maintaining production environments.

Planning for bigger projects is in some sense easier when your team is feature driven. Projects which add new API endpoints, or UI elements, or improve ML model performance have a natural progression from ideation to prototyping to launch and eventually impact measurement (typically some A/B test which corresponds to percentage increases in revenue, or user engagement).

For SREs, the number one priority is to keep things running. There's already a (hopefully stable) production system that's business critical, and the goal when you're not putting out fires, is to make gradual improvements to things like update rollout speed, configuration maintainability, resource provisioning forecasting, etc. There are usually no "easy win", 1 quarter estimate, high impact things left to do (they've already all been done).

So what's left is the large projects spanning multiple quarters, and possibly years, which spin up fancier, better automation to maintain these production systems. Oh, and there are the small projects which comprise of mandates, configuration cleanups, migrations, which are important, but tough to show off during perf as high impact work.

The combined pressures of needing to think quarterly, and having few opportunities which naturally scope themselves to one quarter's work made me feel like I had less and less agency on my team. I let myself get relegated to small scope tasks on the backlog and felt that all important vision diminish from "how can I contribute something of high impact with the team?" to "how can I make it to the next quarter with a passing score on my KR?".

There's a whole separate post to be made about the importance of the feeling of agency or empowerment for feeling fulfilled in one's vocation, so I'll leave it there.

I want to caveat that my management chain did try very hard to encourage ICs to propose big projects and keep them in mind during quarterly planning, but the steady waves of oncall rotations, interrupts tickets, production meetings, and carryover KRs made it too difficult, at least for me, to invest the time and attention to push past the friction and think big.