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
In 2009 Y Combinator founder Paul Graham wrote an 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 tech 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.
- "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.
- Minimal Quarterly/Annual KPIs - Recognizing that quarterly and annual goals are important for financial reporting, 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.