I like to split work into two types, Immediate and Meta, which I define as follows:

  • Immediate: work that moves us closer to an immediate goal. Examples: bug fixes, development of a feature in a software application
  • Meta: work that improves or changes how we perform Immediate work. Examples: planning, refactoring, employee training, development of programming languages, and communication between teams

Clearly you cannot focus entirely on one or the other. If we focused entirely on immediate work, we would all be programming in assembly language with no communication between engineers. On the other hand, if we spent all of our time planning or writing better programming languages, we'd never sell any product.

Customers directly pay for the results of Immediate work and indirectly how fast you can deliver it.

Meta is tooling and process. ROI determines your investment in Meta. At the conception of a startup, you don't know your business model or market, so investing in tooling is probably foolhardy. You can't afford new programming languages or side innovations, so get 'er done.

However, successfully raising funds changes that equation. With a longer horizon, investing in your iteration loop and tools begins to make sense. It seems Meta ROI is, roughly, ExpectedImmediateTime * ImprovementFactor / CostOfImprovement.

Additionally, Meta work applies to itself. Complex systems are like a dark cave -- every step down a path illuminates further steps. You can also think of this effect as "leveling up", like in a video game. If your team begins Test-Driven Development or Continuous Deployment early, it will begin to see further improvements, compounding the benefits. Process improvement has exponential return (as any Singularitarian is quick to mention).

So how can you balance these types of work? Let's discuss several approaches:

Start 100% Immediate and Asymptotically Approach 100% Meta

Upon learning to program, students invariably have the attitude "How do I quickly solve the problem at hand?" After witnessing the limits of that attitude as their non-trivial programs collapse under their own complexity, their attitude shifts to "How can I make programming easier?" From this you see such rarely-fruitful projects as new operating systems and programming languages.

(This is the story of my life... I haven't finished writing a single game since I learned a language powerful enough to metaprogram.)

Always Balance 50% Immediate and 50% Meta

It seems like there should be an optimal balance of process improvement and immediate value creation. Maybe that's true in the long run, but, in my experience, we punctuate work with process improvement. Intel has its Tick Tock approach. IMVU periodically makes comparitively large investments in build processes, separated by periods of smooth execution. Students go to school for part of the year -- process improvement -- and work in the summers or co-ops. (However, I'd argue that applying tick tock more directly to education would be beneficial: a year of school and a year of work. That's another blog post.)

Nintendo's "Spiral" Analogy

If Nintendo focused entirely on immediate results, they would end up in a death spiral: financial pressure reduces available time, limited time reduces quality, poor quality causes lower game sales, and low game sales increases financial pressure.

If you have the latitude to pay attention to process improvement, you will instead follow an "Upward Spiral". Quality and innovation drive sales, giving you more time to spend on quality and innovation.

I Don't Have the Answer

How do you balance Immediate and Meta? Please comment - I'd love to hear your thoughts.