How do you balance Immediate and Meta?

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.

Imported Comments [?]

Joe on Jul 30, 2010

I think the way to decide the trade off is by trying to estimate enough factors to do an expected value calculation. Value only ever comes out of immediate work, but the value you get out of each piece of immediate work is multiplied by the total amount of applicable meta work you've done. So, you make a guesses about the lifespan of the meta work (will it eventually be obsolete or die with the company it was written for?), the force multiplier it adds, and the immediate cost to not having anything to show for the work you've done (political costs because managers/stockholders/VCs can't see the value), then decide at every instant whether there's more long term value to be had by doing immediate or meta.

My guess is if you estimated the values / behaviors of functions involved, you'd end up with something like "Start 100% Immediate and Asymptotically Approach 100% Meta", except that you'd be asymptotically approaching a number less than 100. Like 98 maybe. The lifespan of the meta work, and the project, isn't infinite (if for no other reason because the lifespan of the universe isn't infinite), so there's an absolute cap on how useful meta work can be. Also, if you happen to know you're nearing the end of the company/universe, you might find that you go back from mostly meta to 100% immediate.