Founders need to retain their own mission while they build out the company’s.

Photo by Sharon McCutcheon

Managing a high-growth company is the hardest thing I’ve ever done. One big reason is that I only received problems that no one else could figure out. Some were organizational problems that should naturally route to the CEO, but a lot were functional issues that I was no more capable of solving than anyone else.

I eventually discerned a repeated pattern in solving these problems. At first I would just get a few issues. I’d muddle through - do a bit of research, ask for help, and sort things out. As we grew, more and more of my time would be spent on this one kind of problem. I’d become better and better at handling it, and just about the time I’d start feeling like I knew what I was doing, I’d realize, “Oh: There are people out there who specialize in this”. I could just hire someone to do it full time, and they’d be better at it than I ever would. Duh.

I’d then spend three months, or six, or twelve, hiring for the role, and bam, suddenly my time is freed up and I’ve got an actual expert in charge. Well, kind of. At this point I’m a self-taught semi-expert who does not buy into the orthodoxy of the role, and we’ve got a year of my weird solutions, so there’s a lot of friction as we sort out just how to add this new skill set to a growing org. But the point is, my time spent on this problem drops precipitously, and I no longer have much opportunity to put my new-found skills into practice.

Usually just in time for something new to come into focus.

This pattern - gain just enough expertise to hire someone - played out again and again, for me and for other founders I’ve talked to.

In some ways it’s thrilling. You get experience with all of the key areas at the company, and you’re always learning something new.

In other ways, though, it is soul-crushing. Over the eight years I managed Puppet while in fast hiring mode, I rarely got to spend time doing anything I was good at. Humans have a psychological need to feel competent, to feel like they are in control and know what’s going on. I don’t need this all the time, but please, just a little? Sometimes? Nope. Pretty much the second I started to feel like I understood something, I had to hire for it, and my problem changed from doing to managing.

After years of this, I knew just enough about everything to suck at it, but not enough to actually be useful to anyone.

Only as my tenure as CEO came to a close did I begin to see what I uniquely added to the organization. I began being comfortable not delegating certain problems, and felt justified in spending hours on something as an individual contributor, rather than seeking leverage in everything I did.

Only once this happened did I start to feel comfortable as a CEO. I wasn’t just routing problems, I was actually solving some of them. I was not spending 100% of my time in areas I was incompetent; just most of it.

I know the advice as well as you: Great leaders delegate, they empower. If you’re doing the work yourself, you’re not a real leader.

Bullshit.

Yes, building and running a team absolutely requires that you empower the team. But that doesn’t mean you don’t get to do anything yourself, that you hand everything off and have nothing left.

Just like everyone else, you, too, need a reason to show up, to stay engaged. You have to hold on to your own why.

If you don’t remember why you, personally, are in the job, then you’ll look up in a few years and realize it’s not there any more. You’ve moved too far from what gets you up in the morning, and suddenly you can’t do it. Or worse, the company has developed but you haven’t. You’re no better at the thing you want to master than you were when you started, because you haven’t been spending time on the problems you care most about.

Some of this is that you need a place of safety. I am a highly fireable person, and raising venture capital made for downright tenuous tenure. The less confident I was about my own strengths, my own value, the less safe I felt. And humans need to feel safe to do great work.

More than that, though, I needed a platform for learning. I was pursuing mastery, but of what, exactly? Of not mastering things?

I know other leaders really are master delegators, hirers, organizers, etc. But that was never going to be me.

I had to peel things back, really understand why I was there, what I cared about, what I wanted to be the best in the world at. And, really, what I was good enough at that I ended up in this place, running this company. Then, as the problems rolled by, I could be sure to push that forward just a little bit, even if my focus was on the organization’s needs, not my own.

The times I lost this sense of why I was there and what I was getting better at were some of my most depressing days. But the days where I could connect what I felt good at, what I spent my time on, and what the company needed from me were the best days.

I don’t think that’s any different for me, or for other founders, than it is for anyone else.

But all the discussions of leadership I hear leave this bit out: You’re a human, too. You have to provide the why for the whole organization, but every individual deserves to be able to translate that into what they do every day. Even you.

The true story of trying to put Google’s planning system into use

When Google was less than a year old, they began using a planning system presented by legendary venture capitalist John Doerr of Kleiner Perkins. When I went to put it into practice at Puppet in the early days of growing the team, things were not as easy as they appeared. Success involved creation of a complete solution, not just a description of the documents you need to create.

When I went to try to use the system as described by Doerr, I had multiple questions it didn’t answer. Just to start with, when and how do you make and update these OKRs? It’s great to say you should have this recording of your goals, but I could easily come up with multiple conflicting mechanisms for developing it, none of which are obviously better:

• The CEO could develop them independently and deliver them to the team
• The executive team could develop them collaboratively
• They could be sourced from the front-line team

None of these is obviously right or wrong, and of course, neither are they sufficient explanations for how to do it. Do you do it one sitting? Multiple revisions? How long should you spend on it? How often should you update them? Can you change them mid-stream if your situation obviously changes? There’s a lot left to the reader. You can say it doesn’t matter, but of course, it does, and even if you’re right, you still have to pick one. Why go through the effort of describing the output but skip the whole process you used to create and maintain it?

Here’s how we did it.

Startup Days

Starting by reading John Doerr’s original presentation, even though it’s relatively thin. In summary, you should have three to five 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. This is a useful high-level tool for communication and focus, even in small teams. (Note that I’ll use ‘goals’ and ‘objectives’ interchangeably here; far more people use the shorter term in practice, and we treated them equivalently.)

At Puppet, we spoke of an operational rhythm, which is essentially the set of repetitious tasks we run and the cadence we execute them on to keep the business working. But the OKR system as presented includes no operational rhythm, no indication that people are involved in creating these goals or that doing so takes any time. So we invented our own rhythm:

• As early as possible each period, the management team meets to decide the company OKRs. This started out as a 45-minute meeting that just recorded the goals that were in my head, but evolved over years into a two-day offsite where the leadership team first acquired a shared understanding of where the business was and what we needed to do, then built the goals from there. In retrospect we should have put in these longer days earlier; your team should frequently think deeply about what you should be working on, rather than just running all the time.
• The rest of the company has some time to build its OKRs from the top-level goals. Initially this was a couple of days, but it eventually morphed into a couple of weeks.
• These cascaded goals are then used to modify the company OKRs if needed. (In other words, we supported a merged top-down and bottom-up planning model.) This is when management would learn if our view of reality was materially different from that of the people at the front line.
• 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 grew to become a more complete retrospective run by a project manager. This meeting it at most a couple of hours long, and just includes the leadership team.

When we began this process, we wanted short-term goals, 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 15 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 a mistake that took too much of my time, resulted in too centralized of an organization, and limited our effectiveness because I suck at project management.

Note that these are pointedly not plans; that is, they are not step by step instructions for how to achieve a goal. We’re declaring what we want done, but not how we expect to do it. This is both a blessing and a curse. On the one hand, it provides a lot of freedom for people at the front line to figure out the right way of accomplishing something, but it also leaves a gaping hole in your organization. At some point, someone has to actually do the work, but where in your operational rhythm does a team translate goals into a plan for accomplishing them? Do you make that time? We didn’t until far too late, and it mattered.

Scaling

As we scaled the company and this system, we found a few critical gaps.

The biggest one is obvious enough that I cringe now just thinking about it. You would never try to build a product without being clear on who would do the work and, of course, you shouldn’t try to accomplish your company’s goals without assigning each objective and key result to an individual, yet our initial version (and the one presented by Doerr) had nothing to say on people. At some point we added the requirement that every objective had a name assigned to it, which was a huge change for us - and a really positive one.

The 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. We’d frequently only find out at the end of a quarter that a goal was going to be missed, when it was far too late to do anything about it. So we built a weekly operations review (“ops review”) where we reviewed 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 or changing our expectations.

It’s worth reiterating, because this was so hard to get people to understand: The goal of the ops review was not to describe the status of each goal; it was to build a shared understanding of whether we were likely to achieve our goals and then build an action plan to resolve the predicted misses. The majority of people entered that meeting with a belief that they needed to justify their paycheck, and it took a lot of education to get them to understand the real purpose.

This addition to our rhythm was pretty awesome. In one move, it basically eliminated the firefighting that had driven so much of our execution. We still had fires periodically, but they were actual surprises, not just sudden surfacing of old information, or realizing at the end of the quarter that a goal never had an owner.

The downside of the ops review is that it’s expensive (it necessarily includes a lot of top people at the company) and it takes a lot of work to make this kind of meeting worthwhile every week. I got the idea for this meeting from the excellent American Icon, about how Alan Mulally turned around Ford. A long, weekly operations review with his senior team was one of his key tactics. My team often complained that weekly was too frequent, but if a company as big as Ford was responding weekly to the conditions on the ground, shouldn’t a small startup be at least that responsive?

Around this time, we integrated the budgeting process into the planning process. It’s important to recognize they’re different - you should build the plan you want then find a way to budget for it, rather than building a budget for your departments then letting them decide how to spend it. It’s important that your should be good at both, though, and it was around this stage we started to develop the budgeting skill and learning how to integrate it into planning. That was painful, to put it mildly.

As we scaled, the company goals tended to get expressed in terms of departmental targets within sales, marketing, engineering, etc. When we were small, this seemed like a feature because it had natural lines of ownership, but as we grew it became clear it was a critical flaw. It’s important to translate plans to people and teams, but this was dysfunctional. It discouraged people from building goals that relied on other teams, and thus encouraged silos in the company. Talk about a failure mode. When we added names to each objective, we rebuilt the whole process to be structured from the top down around company goals rather than team goals, which allowed us to crack this departmental view and force shared goals and collaborative execution.

We also eventually added a layer of OKRs above our annual goals, giving us a roughly three year time horizon. These became crucial in sharing and deciding what the priorities were for a given year.

What might come next?

The above roughly describes the system as it stood when I stepped down from Puppet in 2016. It was obvious at the time that we were in need of another step-change in capability in our planning system, but the new CEO took responsibility for driving that. By the time I left, we could see many opportunities to improve what we were doing.

The big one is that we needed to push all the local knowledge about this process into code. We were using multiple different formats and tools, because different meetings require different interactions, and it was too difficult for most people to track what was happening, where, and why. For instance, our source of truth for the OKRs themselves tended to reside in Trello, but it’s a poor fit for storing updates and presenting the predictions of whether a goal would land. I couldn’t imagine trying to run a report on quantitive goals based on Trello data. Thus, we ended up storing the weekly updates in spreadsheets, which are exactly as powerful and readable as shell scripts. It meant we couldn’t trust most people to update the data, because the document was so complicated. I would have loved a single source of truth that anyone could use. In addition, I wanted to have an app automatically pull any data from original sources so I didn’t have team members doing manual work that could be automated (I mean, duh, Puppet is an automation company).

I also wanted a significantly better retrospective process that truly helped us improve the business by laying bare how our wonderfully laid plans went wrong. We were good at the work of looking back and being transparent about where we were, but there was a lot of room for improving how we tie that work to how we operate.

Lastly, I hate that our goals were built around quarters. I think having a cadence for building and validating plans is critical, but it’s silly that this cadence got translated into the timelines for the goals themselves. It often implied that each of our goals would 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 were shoehorned into a quarterly system. I’d much prefer a Kanban-style on-demand planning system that would allow us to have a high-fidelity plan for what we’re working on now, and a quality backlog for what we’ll do as goals complete.

Conclusion

I’m not convinced it matters much what planning and execution system you use, but I’m utterly convinced you should have one. In the end, it’s merely a team-wide mechanism for developing, communicating, and tracking what you’re trying to achieve. It’s obviously important to have goals. I think most of us would agree you should, in some way, share those goals with the team so everyone is working toward the same ends. And, of course, your goals tomorrow should probably be somehow related to your goals today. (This is surprisingly hard.)

If you don’t have one yet, you could do worse than building an operational rhythm from what we built at Puppet. You’ll have to work through a lot of initial discomfort as you translate vague words into technical terms whose meaning is widely agreed upon around your team. But it’ll be worth it.