Friday, March 22, 2013

The 300x Challenge

Could you be 300x more productive?

Although the usual sources are apocryphal, the evidence is clear that individuals and teams vary in productivity over similar domains by 1,000% or more. Supposedly, Google has calculated an individual difference of up to 300x between average and maximum productivity in technologists (such as software engineers).

A 300x difference is worth a pause. This sort of difference would imply that a maximally productive software engineer (in the Google model) could accomplish in one year what an average engineer would require three centuries to complete. A gross oversimplification, but illustrative.

We should find out what causes it, as you can imagine what it would be worth to create productivity like that. Any large company should be willing to spend billions to broadly implement such a change. So what could cause this enormous difference? A real answer requires careful measurement, but there's some value to a conjecture and narrative to get us started looking in the direction of an answer.

I tend to think in terms of teams of engineers working together, so I'm going to switch the focus from the individual to the team, and apply the same productivity amplitude. This seems appropriate.

Here are my raw thoughts on the matter. A 300x team:

  1. Never builds anything they don't have to.
  2. Rapidly constructs working software.
  3. Avoids distraction.
  4. Changes direction without friction.
  5. Does not spend time resolving bugs.
  6. Does not redesign and rebuild software unless they have to, and they almost never have to.
  7. Perfectly distributes tasks to the most qualified team members.
  8. Ships software instead of sitting on it.
How could it be done?
  1. Never builds anything they don't have to.
    • Because they use third party software whenever possible.
        • Because they know what's available.
          • Because they invest time in learning.
          • Because they have a broad network of advisers.
        • Because they have the budget to buy software.
        • Because integrating third party software is easy by technical means and policy.
        • Because they delegate or contract out everything they don't strictly have to build.
    • Because they only work on the most important problems.
      • Because they have a crystal clear understanding of what's needed.
        • Because they understand the purpose of the product.
          • Because they understand the customer.
            • Because they have a perfect feedback loop.
              • Because they have an expert product manager.
      • Because they do not spend time on anything not strategically critical.
        • Because they understand the strategy.
          • Because there is a clearly articulated strategy.
            • Because there is a strategy.
              • Because there is an expert strategist.
  2. Rapidly constructs working software.
    • Because they adopt good designs quickly.
      • Because they are expert designers.
      • Because they get assistance from professionals and domain experts.
        • Because they networked.
        • Because it's facilitated.
          • Because there's a facilitator.
      • Because they understand the problem domain.
      • Because they draw on a deep pool of atomic concepts.
        • Because they have deep computer science knowledge.
    • Because they write working code quickly.
      • Because they are expert coders.
      • Because code once written is always known to work properly.
        • Because it's thoroughly, automatically tested.
          • Because they invest in testing.
          • Because the team includes testing specialists.
        • Because code reviews.
          • Because the team trusts itself.
    • Because integration is simple, quick, and painless.
      • Because components are not developed in isolation.
    • Because they have all the skills they need.
      • Because strong hiring.
      • Because investment in skill acquisition.
      • Because product design leans on existing strengths.
  3. Changes direction without friction.
    • Because they ignore sunk costs.
    • Because they can change or reset development environments instantly.
      • Because they have the most advanced dev and test environments available.
        • Because they invest in tools and environments.
    • Because they keep their eyes on the prize, not the intermediate terrain.
      • Because they measure themselves.
        • Because they have a target.
    • Because they can pick up new ideas quickly.
      • Because they have strong fundamentals.
      • Because they have training, coaching, and mentoring support.
        • Because strong management.
      • Because they teach themselves and each other.
        • Because strong hiring.
        • Because trust.
    • Because they quickly abandon dead ends.
      • Because they watch for them.
  4. Avoids distraction 
    • Because production problems are minimal.
      • Because specialists can deal with production problems.
        • Because there are few to no production problems.
          • Because the software works.
            • Because testing.
            • Because not taking shortcuts.
        • Because there are early warnings before problems become expensive to fix.
          • Because the software has built-in monitors.
          • Because they use they use the most advanced monitoring and alerting systems available.
        • Because it's trivial to deploy and un-deploy.
    • Because they focus on the problem domain.
      • Because office life is easy.
        • Because office politics are minimal.
          • Because disputes are resolved immediately.
            • Because facilitation.
          • Because strong hiring.
          • Because strong advocacy.
        • Because everything but excellence is flexible.
      • Because they organize their continuous experiences around efficiency.
    • Because they use absolutely minimum process.
      • Because unnecessary process is periodically stripped.
        • Because they classify process as necessary or overhead.
        • Because professionals need little process.
  5. Does not spend time resolving bugs.
    • Because there are no bugs.
      • Because they were caught in design.
        • Because design review.
          • Because collaborative design.
        • Because they invest in design.
      • Because they were caught in development.
        • Because collaborative development.
        • Because testing.
      • Because there's a minimum amount of software that could have bugs.
        • Because they built the minimum amount of software.
      • Because developers take every bug personally - but forgive themselves.
  6. Does not redesign and rebuild software.
    • Because they designed it to meet strategic goals.
    • Because meeting strategic goals usually requires new software.
    • Because the team prefers patching to rebuilding.
      • Because they know that rebuilding is usually more expensive.
      • Because they never forget anything.
        • Because communication.
        • Because written communication.
        • Because simplicity.
  7. Perfectly distributes each task to the most effective team member.
    • Because planning and adaptation.
    • Because the team knows its skill structure.
    • Because the team passes work items around without friction.
      • Because trust.
      • Because it's facilitated.
      • Because status is transparent.
        • Because trust.
  8. Ships software instead of sitting on it.
    • Because they release all the time.
      • Because it's almost dangerously easy to release.
      • Because they are confident it will work.
        • Because testing.
    • Because they care about customer happiness.
That's quite a list. Some of the items may be unachievable. Is it enough? Could an 'average' team become 300x more productive if all these were abundantly, lavishly true? Could a team of 4 developers, with a support network of product managers and associated staff, finish in one year what it would take Joe/Jane Average SDE and staff a thousand years?