Jacob Kaplan-Moss

The Innovation/Execution Spectrum

Lately I’ve been working with our startups to establish their engineering strategies. One model I’ve found useful is to place their technical challenge on an innovation/execution spectrum:

Innovation <------------------------------------------------> Execution

unsolved (unsolvable?) problems            known solutions, new context
unprecedented scale                             scaling isn't a concern
entirely novel solutions                   iteratively better solutions

Innovation challenges are ones where you’re trying to solve truly novel problems. You’re trying to building something that has never existed before (e.g. self-driving cars). Or perhaps you’re doing something at a scale that’s unprecedented. Or you’re working on problems that themself haven’t existed before (e.g., climate change).These are thorny problems: there are many “unknown unknowns”. The destination may be clear but that path really isn’t. It may even be unclear that it’s possible to solve the problem you’re tackling.

When your challenge is execution the path is clear. The hard part is executing effectively. The problem is well-known, and there are likely existing solutions. You’ve obviously got some novel spin — usually a cheaper/faster/more efficient solution. Or maybe you’re bringing a known solution into a novel domain.

Thinking about problems in this way has led to two important and non-obvious observations:

  1. Innovation challenges are rare. Most startups want to believe — or want their investors to believe — that they’re tackling these kinds of problems, but don’t believe the bullshit. (See: WeWork, most AI companies, and anything calling itself “Uber for X”). The tech hype cycle has trained us to think of most problems in this way. But if you think deeply most problems end up being iterative rather than innovative.

    For example, take login.gov. It was initially tempting to think of this as an innovation challenge. After all, we were building something novel: a single-sign-on solution for everyone who interacted with the US Federal Government. That’s never been done before! But dig a little deeper, and you’ll realize, as I did, that this isn’t quite true. Single-sign-on is a mostly solved problem: there are known better and worse practices. Scaling isn’t particularly complex (authentication services shard well, and sharding is an extremely well-known technique). The novelly and difficulty come from context: SSO in a government context is a serious challenge. But the problem itself is most closer to an execution problem than an innovation one.

  2. Execution challenges aren’t easy! Again, we’re conditioned by the hype cycle to think that they’re “just” execution. But that “just” does a huge amount of work. Tackling a known problem in a new context, or bringing new efficiency to a stale domain, can be extremely difficult (or impossible). Execution challenges are often “simple but not easy.”

    Stripe is my favorite example here: Stripe is “just” a better payment processor. As a product, there’s very little novel about better payment APIs. It’s simple… but if it’s so “easy” why didn’t PayPal, Visa or Mastercard get there?  Saying that what Stripe accomplished was “easy” is naive to the point of comedy.

    Stripe executed the fuck out of payment processing, and built a terrifically successful business.

(Of course, I’m over-simplifying a bit. This is a spectrum, and most businesses aren’t totally to one side or the other. For example, there’s one company in my portfolio I’d place on the “innovation” side because a core part of its challenge is dealing with a dataset at unprecedented scale. But the rest of the business is more commoditized. So depending on what part of the business I’m looking at, I might make more innovation- or execution-focused strategy decisions.)

There are many ramifications of breaking down engineering problems along this spectrum. A few that have been valuable to me are:

  1. Hiring — engineers themselves often prefer and/or are better at problems closer to one end or the other. Some engineers thrive when asked to tackle novel problems but will struggle to build a CRUD web app on a deadline. Others thrive on cranking out clean solutions to known problems, but will struggle without a roadmap. To put a fine point on it: if you hire someone with a PhD in machine learning to work on a problem that could be solved with Excel and linear regressions, everyone’s gonna be really unhappy.
  2. Leveling — innovation problems typically require more senior (and more specialized) staff. If you’re trying to make a breakthrough in distributed systems, you kinda need at least one distributed systems expert (and probably many). If, on the other hand, execution is key, you can have a much more junior-heavy team. In fact, I’ve sometimes seen entirely new developers seriously outperform ones with many years of experience: more experienced developers can be prone to turning their noses up at “boring” problems.
  3. Technology choice — most of the time, we should choose boring software. This is particularly true of execution businesses: if you’re trying to build a better web app, why make your life harder by choosing a brand-new web framework? But for innovation businesses, sometimes it does make sense to take a risk on something new; sometimes novel problems are only tractable given novel solutions.
  4. Workflow and project planning — more formal agile methods (Scrum, Kanban) tend to work best in execution-heavy environments where the work is more easily broken down and analyzed. Trying to fit novel problems into a 2-week sprint leads to perverse outcomes like time-boxing discovery just to fit into a sprint when a more open-ended exploration would have been well worth the risk.