Google’s internal management approach has sustained and scaled pretty impressively. Transparency, quantitative goalsetting, setting stretch targets — these principles are as evident in 2013 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. Googler Don Dodge does a comprehensive job of documenting OKRs in an earlier blog post, but the basics are 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.
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 Andy Grove of Intel John Doerr of KPCB, and I know 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 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?
The one thing I'd say, although you are correct that three months is suitably arbitrary, is that 'deadline' concept often helps managers and makers alike drive toward a tangible target with urgency. Often makers complain about the overhead a planning cycle imposes (no matter the frequency) so limiting the number that exist is wise. Managers, on the other hand, often times lament the seemingly long lead times required to ship a product or feature, so some modest amount of deadline driven mindset is also beneficial.
Pingback: What a New VC’s Goals Look Like: Homebrew’s First Two Years | Hunter Walk