Manager OKRs, Maker OKRs: How Early Stage Startups Should Think About Goal-Setting
By: Hunter Walk
Tags: Goal Setting, Goals, Startup, Okr, Technology

Manager OKRs, Maker OKRs: How Early Stage Startups Should Think About Goal-Setting

Google’s internal management approach has sustained and scaled pretty impressively over the years. Quantitative goal-setting, setting stretch targets — these principles are as evident in the 2020s as they were when I arrived in 2003. Underpinning it all are OKRs — Objectives and Key Results — the framework by which individuals, teams and the entire company is managed. Xoogler Don Dodge did a comprehensive job of documenting OKRs in an earlier blog post, but the basics were always this: Each quarter individuals and teams document their objectives for the next 90 days and grade the goals they set 90 days earlier. In Q4 teams also set metagoals for the next year. Now we have software startups who have basically built their business around OKR-style planning! Or you could, of course, use this OKR template from Homebrew portfolio company Coda.

Photo by Jeffrey F Lin on Unsplash

My Nine Years at Google meant 36 Quarterly OKRs and the correlating number of annual planning exercises. My role at YouTube had me often working through our OKRs with Larry and Sergey (one of those stressful exercises that in hindsight was amazing). I believe OKRs were originally recommended to L&S by John Doerr of KPCB, and since that time, OKRs have spread through tech companies, sometimes carried by Google alumnus themselves. OKRs are sensible, straight forward and on a planning cycle managers understand. And that’s the problem.

In 2009 Y Combinator founder Paul Graham wrote an essential essay called Maker’s Schedule, Manager’s Schedule. The post discusses how engineers need long periods of dedicated time to build and managers (or people whose work generally involves lots of meetings) can honor this by not scheduling interruptions in the middle of these periods. It’s great — you should read it.

Manager time vs Maker time gave me a lens to not just evaluate day to day schedules, but the general cadence of how we plan and build at Google. We consider ourselves a company founded and driven by Makers (our engineers), but somehow we settled into a Manager planning rhythm, one which mimicked accounting cycles rather than how things actually get built.

“Quarterly goals?” Why are three months the right duration for building features, why not two months or four months? And there was the amusing “last week of quarter” push to try and ship all the features you’d committed to ~90 days earlier.

Even more confusing were annual goals. By Q4, it’s pretty clear whether you’re going to hit the annual goals, the high level targets meant to inspire a year of work, but because you haven’t started next year’s planning cycle, the team has no documented targets for what the next 12 months look like. (Obviously the best managers start with an evergreen vision and then break into planning cycles — this isn’t about roadmapping within teams — but the Quarterly + Annual segmenting is still derived from financial planning, not hacking).

What would I recommend for the Maker-side of early startup companies instead of Quarterly + Calendar Year Annual? These three:

One Month — “What are we building this month” is the key question. Team leads get together the morning of the Monday prior to month’s end and document the next month’s feature releases. This is a bottom up process which includes items shipped completely intra-month and component work of projects which are greater than 30 days long (if you can’t break a complex project into at least 30 days goals, then it’s too big). Four weeks, a few weekends. Enough time to get a lot done. You don’t need to micromanage — for example, if the team spends two days per month bug fixing, just hold that time aside in your calculations, don’t document the bugs you intend to fix.

“What are we building this month” is the key question. Team leads get together the morning of the Monday prior to month’s end and document the next month’s feature releases. This is a bottom up process which includes items shipped completely intra-month and component work of projects which are greater than 30 days long (if you can’t break a complex project into at least 30 days goals, then it’s too big). Four weeks, a few weekends. Enough time to get a lot done. You don’t need to micromanage — for example, if the team spends two days per month bug fixing, just hold that time aside in your calculations, don’t document the bugs you intend to fix. “N+12 Months” — “What will our product and business look like a year from now?” I like the idea of a rolling “one year out” vision, processing new learnings and opportunities. At any given time the entire organization can have a true north for where we want to be a year from now. It evolves, it learns, it doesn’t tick down to zero but rather always looks out over the horizon.

“What will our product and business look like a year from now?” I like the idea of a rolling “one year out” vision, processing new learnings and opportunities. At any given time the entire organization can have a true north for where we want to be a year from now. It evolves, it learns, it doesn’t tick down to zero but rather always looks out over the horizon. Minimal Quarterly/Annual KPIs — Recognizing that quarterly and annual goals are important for financial reporting and goaling, you should keep a very narrow grasp on what you actually want to measure — just key drivers of business — and set quarterly targets. There can be a reality check — do these quarterly targets get achieved given what we’re building?

For me, Monthly Goals combined with N+12 Goals create the right short-term Maker cadence with longer term vision. I never got the chance to try it at Google, but hope to find companies using this sort of planning cycle to see how it works for them.

[This post updates a version I wrote in 2013. Wanted to refresh and re-share because it’s planning season!]