You are here: Home / Archives for Strategy

Artisans vs. Armies

October 11, 2012 by Leave a Comment

There are moments in the history of software, when a product created by a tiny team has invented or transformed entire markets.  I was struck by evidence for a similar model in evolutionary biology: the theory of punctuated equilibrium, where there are long periods of relatively little change followed by short and dramatic periods of upheaval.

This kind of rapid change, brought on by an insightful act of creation, has happened repeatedly.  Afterwards, the market leaders usually settle into a period of stability and incremental refinement, backed by large teams.  For example:

UNIX: Ken Thompson and Dennis Ritchie were working at Bell Labs, and became disenchanted with a large-scale project to design a novel operating system, called Multics.  In reaction to its complexity, they created a much simpler alternative and impishly called it “Unics” (later renamed to Unix).  Thompson described Multics as “overdesigned and overbuilt and over everything” (a common complain about systems built by armies!).  Unix went on to become one of the two dominant server operating systems; it is now enhanced and maintained by an army of its own – thousands of developers around the world.

Visicalc: while a student at Harvard Business School, Dan Bricklin got tired of doing spreadsheets on paper.  He thought that he could use a personal computer to help, so he wrote Visicalc for the Apple II and transformed the role of the personal computer in business.  The spreadsheet has long since moved to the other model – Microsoft Excel has dominated the market for many years.

Electronic Arts: The company was originally created by Trip Hawkins in 1982 with a vision: find the brilliant programmers who could create amazing games for small computers, and celebrate those artists and their creations just as we do with great musicians.  One of my friends from junior high school wrote an early EA game (called Axis Assassin).  It was a very impressive homage to his favorite arcade game, Tempest, and he was the sole programmer who built it.  I still have the packaging with his picture and bio in it (at the ripe age of 18).  But that notion of the individual artist was abandoned by EA many years ago.  Now they make games like Madden NFL, which is built by 30 developers and has more than 10 million lines of source code.  The big PC and console games involve massive multi-year investments.  The artisans have moved to mobile, a disruptive domain where very popular games with millions of users are still being created by tiny teams of people.

American culture, I think, has always been caught between a celebration of the small (the lone inventor in a workshop building a better mousetrap, the small farmer setting forth in a Conestoga wagon on the Oregon trail, the “small is beautiful” philosophy of the 70s) and a celebration of the large (the great skyscrapers – “cathedrals of the machine age”, the massive industrial output that powered our economy and made us victorious in the world wars, the space program that landed astronauts on the moon).  Like the technology industry, our culture is tugged back and forth between these two extremes.

The Model

Across all of these examples, I find that there is a somewhat consistent pattern.  Typically, a new opportunity opens up due to some key technology transformation (like the advent of the PC or the Internet), which is not yet dominated by large established organizations.  Some ground-breaking programmers dream up a new kind of product and create it, often as an act of passion rather than of calculation. The new idea gathers popularity, and over time it either grows a large company around it or (occasionally) is taken over by some existing player that wakes up quickly enough and buys or builds their way into a dominant position.

Once a kind of software has become well-established, it usually stops being the realm of the artisan and becomes dominated by large, well-financed teams.  Division of labor was one of the foundational ideas of the machine age, allowing our society to generate massively more output than it ever could have from the labors of loosely organized artisans in their guilds.  The artisans in most industries were washed to the sea by mega-giants.

But division of labor has a great flaw in times of turbulence – it is extremely hard to rapidly re-architect large products or large teams.  At scale, nobody knows the full story of how either one functions.  In software, the products may be millions of lines of code.  The working relationships among hundreds of specialized experts on an engineering team is a tremendously complex system of its own – redesigning it can be even harder than redesigning the software.  Clayton Christenson and others have eloquently written about how hard it is for established players to reinvent themselves.

It’s Not Just Software

This alternation between artisan and army is not restricted to software.  I was fascinated to learn what happened in the 1800’s in manufacturing, elegantly described in the book The Tycoons (which I highly recommend).

During the Industrial Revolution, British industry was transformed by machine-based manufacturing.  Individual artisans were unable to compete and were largely supplanted.  That part I knew.  What I didn’t know, is that there were some key inventions in manufacturing that had the side-effect of making the roles within a factory require far less individual skill and judgment.  The British were slow to adopt them, and most British plant workers were artisans – in the 1890s, three-quarters of them were highly trained crafts-people with a lifetime of expertise.  By contrast, American plants had virtually none – somebody could be trained for almost any role in the plant relatively quickly.

For this and other reasons, American industry production sky-rocketed past the British.  In 1860, US output was one-third of Britain’s.  Fifty years later, it was 2.3 times larger (!).  Manufacturing has remained dominated by mass scale ever since, though there are interesting early signs of another major shift.  The rise of 3D printing technology makes it cost effective to do very small runs – we may see a new renaissance for the artisan manufacturer.

Another example is movie-making.  United Artists was founded in 1919 by four directors and actors, including Charlie Chaplin and Mary Pickford (two of the most popular actors of the day).  The vision, embodied in its name, was to create a place where the artists dominated, not what today we might call the “suits”.  The company struggled because the industry was moving to longer movies with high production values that required large teams and big investments (sound familiar?).

The company, and the broader industry, seesawed back and forth.  In the 1960s, United Artists created the Bond blockbuster franchise.  In the 1970s, they were involved in the shift towards small “auteur” movies that represented the singular vision of a one person (like Midnight Cowboy).  Then back to blockbusters in the 1980s.  Lately, “indie” pictures are all the rage.  The dynamics of the movie industry have interesting similarities to software, shifting back and forth across the spectrum between creation by artisan or by army.

We’re In a Time of Radical Change

As I’ve written elsewhere, because of the cloud and devices, technology is in a time of radical transformation – a lot of equilibriums are being punctured right now.  It’s a hard time to be an established leader – a threat can develop out of nowhere from a couple of passionate developers with a new idea, and it can grow to massive size in the relative blink of an eye.

But it’s a magical time for the artisans – they can challenge the dominions of the giants, tweaking the noses of the biggest companies in the industry.  And if they are right and they have a winning idea, they can have a tremendous impact.  You don’t need an army to change the shape of an industry – you can build a program and, with no capital investment at all, make it available to a billion people in an hour.  If you crack the code and build something that has real demand, there are ready accelerants poised to support you.  Investment capital is abundantly available to companies that have gotten traction, and people with every kind of specialized skill are ready to jump on the train once it has begun gathering speed.  I call it “scale fast or fail fast”.

I believe that during the next several years, many domains of human endeavor will be radically reshaped by small teams of scrappy challengers.  They will seize this period of transformation to forge and pursue new visions that will change the dynamics of whole industries.  It will be fascinating to see what they come up with.

Filed Under: 10x, 1x Tagged With: , ,

The Physics of Software

September 4, 2012 by Leave a Comment

Physics – the natural laws defining the behavior of matter and energy – determines  what is possible in the universe.  I have found that engineering projects have a kind of physics as well.  But as technology undergoes fundamental transformations, that physics changes.

Enterprise Servers

Let’s look at large-scale commercial enterprise servers composed of millions of lines of code, which in my experience follow a pretty well defined model.  It’s dictated by the needs of the customer and by the constraints of the problem.

In a typical release that makes real but evolutionary steps forward, you take two years to do a version.  During those two years, you get three coding milestones, each of which is eight coding weeks.  Each developer on the project might do four coding days per work week, three if they are a lead.  Roughly 40% of the team is developers (the rest are testers, project managers, designers, etc).  That means that for every person-year spent by the engineering team, you are getting an average of 18 days of actual production coding on the product.

Ouch – no wonder those products take large teams to build and evolve so slowly.  What’s the deal?  The absolute killer .. the single thing that takes away the most productivity from the team, is the need to test and stabilize the product for the vast array of configurations that customers will use it in.  We called it The Matrix – the multi-dimensional matrix of every possible operating system (at different patch levels), every possible storage system, every possible database that customers might be using.  The combinatorics are brutal.

You have to test and retest and retest your product .. not just that it works, but that it is stable under load, that it performs as well as it needs to, that it fails in the same predictable ways, that it recovers from failure, that it can be managed, and backed up, and diagnosed when it goes wrong, and is secure, that you can smoothly migrate to it from older versions, that it integrates with all kinds of other systems that customers want to use it with, and on and on.

We called these “the basics”, and they soaked up far more time than actually writing the code that makes the product function.  Even if you are a very wealthy company, your test lab can’t possibly have every configuration that customers actually use (which is in fact unknowable, since everybody does weird things to customize their datacenter), so you put out a beta and work with early adopters to deploy and test the code in even more configurations.

The sad thing is that even if you could go faster, customers often don’t want you to – from their point of view, you are going too fast.  Once you finish your shiny new version, you have to get them to deploy the darned thing.  They frequently don’t want to, since the old one is working and they are risk-averse and have other and better things to do.  So you work on them, and gradually persuade some of them (often it takes years, and plenty of them will just skip a version).  Then they do a test deployment.  Then they come up with a migration plan.  Then they gradually spin up the new system and move over to it.  Multiple years after a new release, it is quite likely that the great majority of your customer base is running the older ones.  So you have to support every version until the support window runs out – for Microsoft that is ten years, or longer in some cases where the customers were very insistent.  If you are shipping every two years, that might mean supporting five different versions.

And worst of all, once you finally have the customer running live on your system, you basically have no idea what they are doing with it.   Are they using those features that you sweated blood to build?  Is the product working well and delivering the results they need?  You have virtually no data and hence there is a lot of guesswork in figuring out what to do next.  You prioritize things that users complain about or that the engineering team is excited about, never really sure if your priorities match the real needs of the customer.

Cloud Services Change the Physics

Contrast that with running a service.  When you host the service yourself, you have one configuration to support.  You have one team operating it that all works for one company and that works closely together.  You have perfect knowledge of, and control over, the environment where the system is going to be run.  When you deploy a new version, everyone is instantly running on it.

The result is a dramatic change in the size of the team that you need and the efficiency with which you can deliver to customers.  And keeping team sizes down pays off in many ways that are hard to quantify but nevertheless crucial – less communication overhead, a stronger sense of unity, and the ability to make changes in plan more quickly.

Even more important, when customers use your service, you know everything.  You know what features they use, what kind of performance you are delivering, whether searches are yielding results that users are interested in, whether one version or the other of your software gets better results.  You can spot and fix problems in real time without desperately trying to diagnose a critical live system in a customer’s facility based on the few clues that they are able and willing to share with you.

What Does It Mean?

In the history of computer technology, there have been several times when the physics changed profoundly.  Moving from batch to interactive systems was one.  The advent of the PC, where computing became ubiquitous and under your own control.  The standardization of key building blocks like operating systems and databases, so applications could focus on the unique logic of the problems they were targeting.

Every time the physics changed in the past, it enabled a massive acceleration of innovation and disruption.  New markets opened up, software was able to do things it had never been able to do before, and established companies faced tremendous pressure.  The traditional way of doing things doesn’t always go away – mainframes running COBOL process enormous numbers of transactions every day.  People still buy PC software, and servers will be deployed into data centers for decades.  But companies and communities that miss out on one of these fundamental transformations usually have a difficult time.  They often end up living in a perpetual twilight world of stasis and conservatism.  The frontiers of technical development, the best developers, and the biggest new opportunities leave them behind.

I believe that this transition, from servers to services, is one of those abiding changes in the physics of software.  The benefits of services are so compelling in terms of efficiency, of deeply understanding your customers and what they need, and of adjusting and adapting software in real time, that I think they will be the place where the white-heat of innovation happens.  If you are on the wrong side of that divide and your competitor is not, it will be very difficult to compete toe to toe.

Filed Under: 1x Tagged With: ,

Rubber Gloves, Not White Gloves

June 14, 2012 by Leave a Comment

I’ve always loved to be involved in making things happen, on the ground.  The detail of execution, the individual decisions that mount up to determine success or failure – I like to plunge my hands into the engine grease.  Hence, rubber gloves, not white gloves.

That enthusiasm hasn’t always been embraced by the environment I’m in – places where the focus was on Big Ideas™, not the minutia of execution.  In academia, research labs, and staff or management roles, I was often supposed to step back, see the bigger picture, and identify the key trends and leverage points.  I love to do that, but I find that big ideas often become irrelevant if you are disconnected from the details.  In studying many projects that both succeeded and failed, my conviction has only deepened that the combination is where the magic lies.

Combining Vision and Execution

A great example is Brunelleschi, the architect who designed the beautiful Duomo – the dome that sits atop the famous cathedral that dominates the skyline of Florence.

It took 140 years to complete the building; the dome had remained a puzzle for decades because nobody could figure out how to build it.  The solution called for rediscovering ideas that had been forgotten since the days of the Roman Empire, and new inventions that had never been tried before.

Brunelleschi solved the problem in 1419 and got the commission, dedicating most of his adult life to constructing the dome and other parts of the cathedral.  The dome took more than four million bricks (37,000 tons of material!), and with the lantern on top stood 375 feet high.  He got a couple of the first patents ever issued to protect his ideas for a new kind of hoisting machine and a river transport vessel.  Brunelleschi was intimately involved in every step of the construction, laid some of the bricks himself, and immersed himself in every detail (including the work schedule and diet of the people doing the construction).  If you are interested, check out the Wikipedia entry; Ross King did a great job telling the story in more detail in the book, Brunelleschi’s Dome.

Another interesting case study was the race to reach the South Pole first in 1911.   Two expeditions were involved.  One party, led by Robert Scott, was less focused on the details of planning and preparation.  The other, led by Roald Amundsen, was a great example of deep focus on every detail.  Amundsen insisted that every member of the expedition be an expert skier who had been practicing the sport since they were children.  Scott’s team mostly couldn’t ski.  Amundsen prepared navigation sheets so that they wouldn’t have to make complex calculations when they were exhausted.  Four out of five members of his final team were experienced navigators.  Scott had one, and used a technique that required more calculation.  Amundsen relied heavily on sled dogs and figured out how to keep them properly fed and cared for.  Scott’s team didn’t want to rely as much on dogs so they were dependent on horses, which turned out to be poorly adapted for the conditions.

Both teams were staffed with brave and seasoned explorers, but the results starkly illustrate the cost of poor focus on execution basics.  Amundsen got to the pole first and returned successfully without losing a man.  Scott, and the four companions who made it to the pole with him, all died.

Right Vision, Bad Execution

There are many, many examples where a compelling vision but poor execution leads to disaster.  It often happens even if the vision is a great and achievable one.

I thought it was very interesting to learn about the history of the Panama Canal in the excellent book by David McCullough called Path Between The Seas.  Basically, there was a competition to come up with the design for a canal that would connect the Atlantic and Pacific Ocean and avoid the laborious and dangerous trip around South America into the treacherous waters of Drake’s Passage.  A Frenchman, Ferdinand de Lesseps, had been the leading spirit behind the Suez Canal and came up with a hastily slapped together plan that chose a sub-optimal path and paid little heed to the enormous engineering challenges.  An American team very carefully and thoughtfully developed an alternative based on extensive surveys.  Lesseps, who was a charismatic, larger than life figure with little engineering knowledge, carried the day anyway and inspired investors to finance the effort.

An engineering group estimated it would cost $214 million; Lesseps cut that to $120 million with no real justification.  After eight years, 22,000 people had died (mostly of malaria and yellow fever – nobody realized that they were spread by mosquitos) and $235 million dollars had been spent, but the project was only partially done with the hardest issues unresolved.  The company went bankrupt.   The project was eventually taken over by the American government, after a fifteen year delay, and it took another $375 million and nine years to complete (but came in under the budget estimate!).  I think it’s a powerful example of a great vision, uncoupled to strong execution, leading to horrible results.  Then that same vision, carried forward in more pragmatic and expert hands, created a vital global resource.

Vision is Crucial .. but Must Not Become Decoupled From Reality

I’m a great believer in the importance of vision and strategy.  But strategy has to be deeply, deeply informed by all the infinite detail of execution.  And in looking at brilliantly successful strategies in technology, I’ve found that they are often emergent properties.  They were glimpsed, and then refined, by someone steeped in a deep understanding of their markets and the technology forces transforming them.  A kernel of insight evolves into a huge success – it doesn’t leap forth from the mind fully formed, like Athena from the forehead of Zeus.   Having a big and bold goal is fantastic .. but strategy is shaped, and success or failure is determined, by the execution.

Great execution is hard and requires endless focus and obsessiveness to achieve.  I’ve mostly worked on large software projects, and when you are building something that has millions of lines of code in it, the team must work together extraordinary well.  Such projects call for Herculean efforts and tiny bits of friction can lead to huge problems.  The code, the test suites, the shiproom triage meeting, the bug count, the milestone definition .. those are the clay and brick from which the great cathedrals are forged.  Lose your connection to the grit and the glue at your peril.

That’s why I love being in a startup .. we have a bold vision for what we hope to achieve, but our days are full of designing and building the product with endless and loving focus on every detail.  Hopefully we are achieving a combination of vision and execution that will let us have the impact we aspire to make in the lives of our users.

Filed Under: 1000x, 100x, 10x, 1x Tagged With: ,
%d bloggers like this: