A new guide for effective startup planning

Over the last seven years, starting around the time I began hiring people in my company, I have been on a journey to continually improve our system for deciding what to do and then doing it (preferably quickly). This planning system I devised was initially based on a presentation given to Google when they were less than a year old by legendary venture capitalist John Doerr of Kleiner Perkins. While an excellent starting point, I soon discovered this presentation was nowhere near detailed enough, and we’ve moved on dramatically since then. Given that this problem of planning and execution is critical to every company, I thought it was worth sharing the rough stages we went through.

Startup days

I recommend you read John Doerr’s original presentation, even though it’s relatively thin. It can be summarized as, you should have 3-5 top-level objectives, and each of these should have a couple of key results associated with it. Together these constitute a company’s Objectives and Key Results, or “OKRs”. These should then cascade down to the rest of your team, so that each team and person has OKRs. I think this is a great high-level tool for communication and focus, even in small teams.

Unfortunately, when I tried to use the system as described, I had multiple questions it didn’t answer. Most importantly, when and how do you make and update these OKRs?

In our company, we speak of an operational rhythm, which is essentially the set of repetitious tasks we run to keep the business working. But the OKR system has no operational rhythm at all, so we invented one. In this early stage, it was pretty simple:

• First thing every period, the management team meets to decide on the company OKRs. This started out as a 45-minute meeting that just recorded the goals, but it evolved into a two-day offsite where we actually decided the goals. I can’t recommend enough that you invest the time early on to think deeply as a team about what you should be working on.

• The rest of the company has some time to build its OKRs. Initially this was a couple of days, but now it’s a couple of weeks.

• These are then used to modify the company OKRs if needed. (In other words, we supported a merged top-down and bottom-up planning model.)
• At the end of every period, the management team records how we did against our goals. Again, this began as just writing down the score but has grown to become a more complete retrospective run by a project manager.

When we began this process, we wanted very short-term plans, so we ran this cadence eight times a year; thus, we called our planning periods “octaves.” As we matured and could think and execute in a more long-term fashion, we reduced this to quarterly.

I think this system is sufficient for most companies of 80 to 250 people. Some companies might grow out of this at relatively few people, whereas others might scale very well with it. I expect most people could scale this system successfully by gradually increasing the amount of time spent on each session, with more time in deep discussion — and also by assigning a project manager to run it. I ran the whole process until we were probably 250 people, which was way too late.

Scaling

As we scaled the company and this system, we found a few critical areas where we needed to do things very differently.

In retrospect, the biggest one is incredibly obvious, and I cringe now just thinking about it. You would never try to build a product without assigning the work to individuals and, of course, you shouldn’t try to accomplish your company’s plans without assigning each objective and key result to an individual. This culture of accountability was a huge change for us – and a really positive one.

Our original lack of accountability for each goal was exacerbated by the fact that we didn’t have any mechanism for in-quarter check-ins on the goals. So we built an operations review (“ops review”), where we review progress against the goals. This meeting is a predictive exercise, not a status statement. Goals are green if you expect to accomplish them on time, even if you’re still two months away from the deadline. We mostly focus just on the areas we don’t expect to hit, which allows us to invest early in correcting our execution.

In one move, this meeting basically eliminated the firefighting that had driven so much of our execution. We still have fires periodically, but now they’re actual surprises, not just information surfacing to a different part of the company, or realizing at the end of the quarter that a goal dropped between the cracks.

Around this time, we also significantly improved our ability to integrate the budgeting process and the planning process. It’s important to recognize they’re different — your budget should fund your plan, rather than building a budget and then planning to spend it — but you should be good at both, and it was around this stage we started to develop that skill.

Finally, as we scaled, the goals tended to cascade in a very functional way, meaning that the top-level company goals quickly got expressed in terms of sales, marketing, and engineering goals. It’s important to translate plans to people and teams, but this was too direct. It encouraged silos in the company and discouraged people from building goals that relied on other teams. We rebuilt the whole goal process to be structured entirely around company goals rather than team goals, which allowed us to create higher-level objectives and encourage more collaboration.

We’ve also structured our OKRs to have long-term goals (roughly three years away), which then translate into annual OKRs.

Where from here?

While I’m reasonably happy with the system we have today, there are still a lot of ways it can improve.

The big one is that I want to build a custom app to run this whole process. We currently have to use multiple different formats and tools, because different meetings require different interactions. I’d love to have a single source of truth. In addition, I want to have the app automatically update any data so I don’t have team members doing manual work that could be automated (I mean, duh, we’re an automation company).

I also want a significantly better retrospective process that truly helps us improve the business by helping us understand how our wonderfully laid plans went wrong. We are good at the work of looking back and being transparent about where we are, but there’s a lot of room for improving how we tie that work to how we operate.

Lastly, I hate that our goals are built around quarters. I think having a cadence for building and validating plans is critical, but it’s silly that this cadence implies that each of our goals will take exactly a single planning cycle. Some obviously do — we have quarterly sales targets that we need to hit during exactly a quarter — but many of our top-level objectives are shoehorned into a quarterly system. I’d much prefer a Kanban-style planning system that would allow us to have a very high-fidelity plan for what we’re working on now, and a quality backlog for what we’ll do as goals complete.

I hope this helps you improve your own plans and execution, even if just by convincing you that they matter.

Luke Kanies is CEO and founder of Puppet.