Areas of Execution / by Nate Westheimer

I have been thinking a lot about what founding teams should look like and how they should be organized. What's the optimal founding team? How can you insure long-term success? As I think about this, I keep in mind that Execution really is everything. If you don't have a plan and you can't execute, you're going to have to rely on more luck than most have in a lifetime to succeed -- and if you're building something to get lucky, you're building something to fail.

So, before I set out on a new endeavor, I want to make sure I -- and my co-founders -- are the right people to do the right jobs. I want to build an Execution Oriented Team.

What does that mean? Below are my 3 Principals of Execution Oriented Teams:

  1. It is important for a company to be organized around business goals with clearly defined “areas of execution” -- that is: a define-able focus area containing, values, sets of tasks, milestones, and to-dos which can be described simply and which add up and create the value which is the enterprise.
  2. A company should be simple, and therefore require as few areas of execution as possible.
  3. Each area of execution should have an owner in the founding team. There should be no more founders than there are areas of execution, and each founder should own, singularly, his or her area of execution. A founder may own more than one area of execution -- and should when two areas are closely linked -- but people should have no more than two areas of execution.

With this framework, I'm not thinking about what titles I presume I need for my next endeavor (i.e. CEO, CTO)... I'm thinking about what each specific idea's "areas of execution" will be and who I'd want to own those. Forget Titles, its about Roles.

In this practice, an Area of Execution is never something vague like "technology," it's something like: "optimize user recommendations" if that's a key area of execution for the business, or "increase customer conversions," if there will be a flow of potential users that need to be converted. If you sell stuff, having someone who can sell Linux to a developer (our world's version of ice to an eskimo?) in her sleep would be key in a founding team.

Chances are, someone who owns conversions and someone who owns algorithmic optimizations inside of an organization will be different people, and if each is critical to a business, it's worth your time (and worth the dilution) to find someone to own each.

As I've been talking to a number of people about working together on a new project, thinking about things in this framework has been quite helpful. Aside from the most important value I'm looking for -- intellectual partnership -- I'm not judging people on their design or their programming experience -- and certainly not on their ability to report to me -- I'm thinking about what the company needs to succeed and then thinking about if there's a specific fit. I ask myself, "Can this person obsess on this specific area of execution day after day?"

I'm asking myself, "Can I?"

We'll see how it turns out, but so far it's been an empowering way of thinking about things.