A Simple Matter of Software

Need for nimbleness

The interesting thing about the Microsoft-Yahoo merger to me is not that two companies that lost out to Google now are combining, but rather why they lost to Google in the first place.

 

Here is one common thread in the commentary:

"Yahoo management has not been nimble, Microsoft has not been nimble, Google has a management team that is nimble and dynamic."  - SF Chronicle

Over the past few years, "Yahoo became less nimble ... " -  Diab

"I'd add that since Google is a faster growing, more nimble company than Microsoft or Yahoo ... " - Techsmart

"Word has it that Yahoo's once nimble and entrepreneurial culture has turned sluggish and bureaucratic. The company's organizational structure and compensation system appears to be rewarding silo behavior that inhibits change."  - Steve Tobak

"... what some see as an inability to respond to more nimble (though considerably larger) Google" - CNET

Falling back into a "comfort zone" and building mechanisms (bureaucratic or otherwise) that "ensure stability", is a typical human response to success.  In its time Yahoo had plenty of success and slowed their rate of change as a result. 

For a Internet service business where the "network effect" applies and there are "very low switching costs" for the end user.  It is critical that you respond to success by staying nimble and accelerating your rate of progress.  Otherwise someone else will see what you have achieved so far and take the initiative to eat your lunch.

 

Clinton, Machiavelli and the challenge of change

"It must be considered that there is nothing more difficult to carry out ... than to initiate a new order of things.  For the reformer has enemies in all those who profit by the old order, and only lukewarm defenders in all those who could profit by the new order, this lukewarmness arriving partly from fear of their adversaries ... and partly from the incredulity of mankind, who do not truly believe in anything new until they have had an actual experience of it."
                                                                     - Machiavelli writing in "The Prince"

A favorite quote of former President Clinton. 

 

The good kind of failure

“I have not failed. I have just found ten thousand ways that won’t work.”
                                                                                    - Thomas Edison

Resiliency and learning from your "mistakes" are critical to building a successful venture. 

Organizing your efforts to avoid "mistakes" and to have no risk of "failure" is a bad strategy.  Organizing your efforts to "fail faster" so that you can learn from your mistakes and course correct as you go is a good strategy.

It is important to distinguish between making new mistakes which are the good kind that you learn from; and simply repeating the same mistakes that have been made before and should now be avoidable.

                                                                               copyright 2007 Kerry Champion

Saint-Exupery on Engineering Elegance

"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."
                                - Antoine Saint-Exupery

Traditional Management vs Venture Management

1000ventures.com has an interesting comparison of traditional management vs. venture management.  I don't agree with all their points, but it is worth a look.  Here are some of their main ideas (somewhat modified):

Building Business Around
    TM: Competence-driven idea
    VM: Opportunities: customer-driven idea or a new technology

Market Focus
    TM: Serving established customers
    VM: Entering emerging market that has yet to be recognized and exploited

Results
    TM: Quite predictable
    VM: Quite unpredictable

Time-to-Market
    TM: Willingness to sacrifice speed for thoroughness of analysis
    VM: Speed is critical, get ideas to market to test in real world

Success Measure
    TM: Earnings
    VM: Market capitalization

Market Research
    TM: Analysis, review, methodical consideration of facts.
    VM: "Living the data", agility, experimentation, adaptation, and rapid response

Management Attitude
    TM: Dedicated to delivering an operating plan
    VM: Dedicated to identifying and adapting to unmet, unserved customer needs

Risk Management
    TM: Reason, caution, predictability, avoiding failure at almost any cost
    VM: Experimenting, adapting, failing, and experimenting again

Financial Focus
    TM: Profit
    VM: Cash flow

Design principle from creator of first Wiki

“What is the simplest thing that could possibly work?”
                                                              - Ward Cunningham

Robust KISS

My father would remind me to KISS - Keep It Simple Stupid!

This often came up after I did something that wasn't simple but was stupid.

Dilbert's 9 rules for financial planning provide a great example of the KISS principle.

1. Make a will.
2. Pay off your credit cards.
3. Get term life insurance if you have a family to support.
4. Fund your 401(k) to the maximum.
5. Fund your IRA to the maximum.
6. Buy a house if you want to live in a house and you can afford it.
7. Put six months’ expenses in a money market fund.
8. Take whatever money is left over and invest 70% in a stock index fund and 30% in a bond fund through any discount broker and never touch it until retirement.
9. If any of this confuses you, or you have something special going on (retirement, college planning, tax issues) hire a fee-based financial planner, not one who charges a percentage of your portfolio.
   From Dilbert and the Way of the Weasel

These are simple rules that provide excellent guidance in a very complex field.

For 95% of the people in the country following these rules would improve their personal finances and would save in aggregate $100 of billions.   

These rules may be the optimum strategy for only a fraction of us.  I don't claim they are optimal for 95%.  My claim is that for 95% of the population these rules will provide a better outcome compared to what they are actually doing today.

What lessons can we take from Dilbert's financial advice that will apply to growing a software venture?

A-list software ventures tend to be populated with smart driven type-A personalities.  Who are capable of dealing with a  high degree of complexity and who like to demonstrate that ability.  People who often are more skilled at coming up with clever insights than they are at communicating simple actionable ideas.  Many of these folks tend towards a paradoxical combination of perfectionism and a fire-fighting mentality.   Which in turn leads to strategies/policies/plans that are either

    A) truly baroque and complex in an effort to create fine-tuned optimization
    OR
    B) non-existent - replaced instead by reactive ad hoc  behavior

With this context I see 3 key lessons from Dilbert's fine example of KISS in action.

1) Simple is better than none

Most people don't have a financial plan of any kind.  Clearly following Dilbert's simple rules would make them much better off, even if it does not provide the best of all possible worlds.

Similarly, it is incredibly common for fast-growing software ventures to live without clearly stated and widely understood strategies, policies, and plans. 

In some of these cases a few individuals have in their heads sophisticated ideas for how to address these needs.  Ideas that don't translate easily to simple declarative statements that get immediately written down.  The expectation seems to be that through example and osmosis these sophisticated ideas will transfer to the rest of the team.

In other cases, everyone is too busy reacting, firefighting, and addressing the 'obvious' urgent needs to bother writing down specific plans or practices.

In other cases, the desire to create a very elaborate and complete plan leads to  a long planning cycle, so that many such cycles are started but none are every completed before they are interrupted. This is one reason why striving for a truly complete specification can be the wrong thing to do a simple spec that is up to date and conveys critical info is better than striving for a 'complete' spec and in effect living with none.

In all cases, it would be better to write down, clearly communicate, and then consistently live by some simple plan than to live without any at all.

2) Communication and execution matter more than cleverness and optimization

When it comes to personal finance many people do too much rather than too little.  People tend to overestimate their ability to optimize their financial results through cleverness and activity.  They tend to underestimate the value of simplicity, consistency, and low-costs.  This is why almost everyone who actively trades stocks does worse than if they just paid credit cards and then invested in a cross section of index funds. 

Similarly at software ventures we tend to use our cleverness to try and get the best possible results through creation of a complicated plan.  We tend to underestimate the value of simplicity.  Simple plans are easier to communicate, easier to execute, and easier to adjust as you get new data. 

These benefits from simplicity apply both in business planning and to software design.  The most elegant technical improvements often come when we innovate via simplification.

One clever person with an intricate vision of how all the pieces fit together, isn't enough to make a team succeed. Coming up with a simple approach that can be effectively communicated to everyone is a mark of true understanding.   

As Pooh pointed out in the Tao of Pooh:

"Rabbit's clever," said Pooh thoughtfully.
"Yes,"said Piglet, "Rabbit's clever."
"And he has Brain."
"Yes," said Piglet, "Rabbit has Brain."
There was a long silence.
"I suppose," said Pooh, "that that's why he never understands anything."

Lots of folks at software ventures are like Rabbit.  They show off their cleverness with intricate plans that they never get everyone to understand and that are impossible for mere mortals to execute.  When what is really required to get an effective common understanding is simplicity.

3) Robustness matters

Of course not all simple plans are created equal.  Simple by itself does not guarantee success. The plan needs to be simple and effective.

One measure of effectiveness is robustness.  Wikipedia has a nice definition:

Robustness is the quality of being able to withstand stresses, pressures, or changes in procedure or circumstance. A system, organism or design may be said to be "robust" if it is capable of coping well with variations (sometimes unpredictable variations) in its operating environment with minimal damage, alteration or loss of functionality.

Dilbert's financial plan seems robust to me and that is a very good thing.

Simplicity often improves robustness, as it is easier for a simple system to adapt to changing circumstances.

However, it is possible to go too far.  As we strive for simplicity in our software designs and business plans, we don't want to make a plan that will only work in our immediate circumstances.  We want to create something that is "as simple as possible but no simpler" and one good measure of that is the likely robustness of that plan in the face of a changing environment.

                                                                               copyright 2007 Kerry Champion

Innovation: once is not enough

Here is an striking quote from the New Yorker ("The Typing Life" April 9, 2007):

... historians estimate that the typewriter was invented at least fifty-two times, as one tinkerer after another groped toward a usable design 

Highlighting one of the key usability issues the author, Joan Acocella, goes on to note:

... Until about the eighteen-thirties, all typewriters lacked a keyboard, and when they got one it was usually modeled on that of the piano.

Acocella points out that the first widely used model did not come onto the market till 1873.

Given that it was 1450 when Gutenberg got the whole movable type thing going in Europe, 1873 seems like a long time to wait to get a usable typewriter.

Three things came to mind as I read this article:

1) First is that usability matters.  It was not the case that the first fifty-one typewriters did not work, from the inventors point of view they "worked per the spec" and did what was intended.  Obviously working as designed is not enough, you must make your invention more inviting and usable in the context of the users existing experiences and expectations.

2) It is hard to predict how long innovation will take, but we can consciously become more effective innovators.  In 1878 if you had asked "so Mr Edison how long is it going to take you to invent the light bulb?"  what kind of answer do you think you would have gotten? 

It was not an unreasonable question, Edison was not doing some fundamental basic research.  The first incandescent light was invented 70 years earlier (using platinum filaments which were unfortunately not very cost effective.)  A lot of useful work had happened since then.  Edison himself had bought the patent rights to a carbon filament bulb as a starting point for his own work.  So given that he was doing an incremental improvement to a 70 year old body of research, you might think he could give you a schedule, wouldn't you? 

Of course in reality he could not give you an exact schedule.  What he could and did do, was use efficient techniques (good metrics and measurements, multiple simultaneous research paths, efficient organization of multiple researchers, good tracking of results) to make the innovation process better than it had been the past: faster, more focused on a practical result, more alternatives and fall-back options, with better reporting as he went.  Using these techniques his lab produced a usable result in less than two years, rather than spending another 70 on it.

3) Version 1.0 failing does not prove that you are pursuing the wrong opportunity.  The old saw about Microsoft is that for each product they finally got it right on version 3.0.  For the typewriter it was version 53.0 that finally got some real use. 

Someone else capturing the opportunity is a good reason to quit pursuing a particular innovation.   Another good reason to quit, would be gathering new evidence about  your users' needs that convinces you that you are building the wrong offering.   However, having your 1.0 version fail to fulfill your vision, is a bad reason whipsaw your team and fundamentally change your target.  Rather it is a good opportunity to learn from some real-world feedback and accelerate your efforts.

                                                                               copyright 2007 Kerry Champion

Out of the comfort zone

Wikipedia defines "comfort zone" as a set of "artificially created mental boundaries, within which an individual derives a sense of security."

It is natural for humans to build a comfort zone for themselves and in many situations this is an excellent life strategy.  When our Paleolithic ancestors were wrestling hyenas for the right to scavenge the best bits off the gazelle carcase, finding a secure niche and staying in it made a lot of sense.  So long as you are getting your basic needs met in the valley you are in, why move to the next valley over?

Unfortunately finding a comfort zone that meets our basic needs and staying there is not the best strategy for guiding a software team to deliver world-class performance.

Our paleolithic ancestors defined their comfort zones in terms of what geographic area they would search for food; and what animals they would fight vs. which they would fly from.

Software teams tend to define their comfort zone in terms of how they respond to change. 

• Will they limit themselves to incremental changes to existing product or will they create category defining new products? 
• Will they obsessively cling to keeping the current team as is, or will they reorganize the team and add new members as needed to address new challenges? 
• Will they be primarily motivated by risk-aversion or will they be primarily motivated by reward-seeking? 
• Will they train others and share responsibility for their code, or will they have a very proprietary attitude towards the code they wrote?
• etc. etc.

Often  these limitations are not driven by any rational analysis of risks and rewards, but rather is driven by specific previous bad experiences, a desire for control, and a general free-floating anxiety.

Given the natural human tendency to define a fairly constricted comfort zone, it is part of a leader's responsibility to know when and how to break down those boundaries.

Of course creating change for changes' sake or pushing people just to see them squirm is not productive.  Being a "loose canon" who has a new "priority of the week" is not how to guide a team to real success.

Instead your should carefully and consciously call your shots.  You should push people out of their comfort zone when doing so is directly tied to addressing organizational imperatives that are critical to your overall success.  And you should take the time to explain why there is a direct connection between these changes and those imperatives.

Even as you change what needs to be changed, you need to highlight to the team what is remaining stable.  Often people will fixate on the changes and risks, and lose sight of elements which are remaining stable and resources which will provide extra resiliency if things don't go exactly as planned.  Take the time to remind folks of these stable elements and resilient resources.

Let's talk through an example of when taking people out of their comfort zone was the right thing to do.  I was SVP of Development at a software company that had recently acquired another firm of about the same size.  We were just a few miles down the road from each other so we could combine offices.  Each of the predecessor companies had a stable software engineering team run by a VP of Engineering.  In both cases the teams liked and trusted their VPs and the VPs had intimate knowledge of the teams.

After the merger I had several goals including:

1. Maintain rapid progress in the development of both the original and the acquired product lines
2. Find opportunities to integrate the product lines
3. Form an objective assessment of the relative strengths of the two VPs, of the two teams, and of specific individuals on each team

Because of the first goal I did not want to just immediately tear apart both teams and form a new fully integrated team.  Also, until I had fully succeeded at the third goal I as not in a good position to ensure that such a drastic reorganization would be successful.

Therefore, what I did in the short-term was to maintain the teams as-is but to ask the two VPs to switch jobs.  This certainly pushed people out of their comfort zones, everyone involved was hesitant to see this change made and everyone needed to be talked into it.  Each team would have a brand-new top boss and each VP would have a wholly new team.

While people were uncomfortable with this change they accepted it because we could show how it made sense given the goals:

1. By just changing the two VPs, but not reorganizing the teams overall, we could maintain enough continuity to allow rapid progress on both the original and the acquired product lines
2. The switch of the two VPs forced them to rapidly learn the "new" team's product line and technologies which put us in a good position to assess what integration points made sense.
   
3. Also the switch of the two VPs put me in a much better position to get objective assessments of each sub-team and individual; as we now had two senior folks (the VPs) who could provide relevant analysis about everyone.  It also gave me a chance to assess the VPs themselves as I could see if switching them had much impact on the relative productivity of their teams.

The above is an example of a change that was highly useful to make and was directly driven by our imperative goals.  However, it was also a change that was non-obvious and was perceived as a "surprise".  This change was outside those "artificially created mental boundaries" that defined our current comfort zone, that is why it was a "surprise" and why we almost did not implement it.

                                                                                 copyright 2007 Kerry Champion

The View From Mount Improbable

Penguin has published a nifty little book called "The View From Mount Improbable" in it Richard Dawkins explains how the eye evolved through a series of incremental steps.  This is an important argument to make, as creationists often use the eye as an example of an organ that is so complicated and so perfect that it could not have evolved but must have been created in one master stroke.  (Central concepts from Dawkins argument have analogs that are critical in planning software architectures, we will get to that  in a little bit, first the biology.)

Darwin himself admits the difficulty:

"To suppose that the eye, with all  its inimitable contrivances for adjusting the focus to different distances, for admitting different amounts of light,  and for the correction of spherical and chromatic aberration, could have been formed by natural selection, seems, I freely confess, absurd to the highest degree."

What Darwin, Dawkins, and the other evolutionists have done is show how the human eye was formed through a series of incremental steps, where each step required only a limited change, and each step resulted in a functioning organ.  In fact many of these intermediate forms still exist today in other creatures, the "non-directional light sensitive skins of starfish" are a good example of an early form.  While it is impossible to imagine that you could go from no eye to a fully formed human eye in a single mutation, it is possible to imagine a single mutation triggering each of these individual intermediate steps.  And since each intermediate step is a functioning organ that has at least slightly improved upon its predecessor it is easy to see how natural selection would spread that new version through the population.

In software development we also have arguments about what is the most plausible way to create something that is complex and perfect.  Two typical options can be thought of as the "creationist" approach and the "evolutionist" approach:

1. Creationist: Assign a very smart design team.  Have them create an elegant design that fulfills your full concept for the product.  Immediately start to implement this final form of the product.
      
2. Evolutionist:  Lay out a plan for series of intermediate versions of the product.  Carefully design the first step  (keeping in mind that the codebase will be evolved and reused, so put emphasis on compartmentalization, factoring, and good interfaces), don't take the time to fully design the later steps.  Make each intermediate step something that is deployed with users, or at least with beta users.  Be prepared to adjust the plan based on feedback you get at each intermediate step.

The "creationists"  argue:

• It takes too long to make all these intermediate versions.
• What is the point of writing a bunch of code that will only get reworked or replaced as you evolve the product.
• Intermediate versions lead to legacy problems (interfaces you have to support, migration plans you have to implement, etc.) that you will regret.
• The competition is not going to waste time with these intermediate versions.  They will leapfrog us.
• Why limit yourself to designs that can be reached through incremental steps, what if the "best possible design" can not be reached through incremental steps.

The "evolutionists" argue:

• Not understanding the real requirements is the biggest issue.  Users themselves typically don't know what they ultimately want.  Only getting something in use can resolve this issue.
• It is only after you have written it once that you really understand how to write it right.
• Naval gazing in your conference room does not lead to true understanding.  Putting software into use, careful analysis of the reaction, and rapidly evolving the offering is what leads to true enlightenment
• Having working intermediate versions gives you more flexibility when it comes to the point of making the features vs. schedule trade-offs.
• Working intermediate versions improves your ability to get continued funding.  This is true whether your funding comes from a VC firm or a senior management budget committee.
• The goal is not finding the "best possible design", the goal is finding a great design that meets your audacious goals with minimum risk.

Which approach is best depends on your specific circumstances: scope of the project, relevance of team's previous experience, clarity of requirements, etc.  However, most of the time I am an "evolutionist". 

Smart people tend to over-estimate their ability to go directly (via their own mental horsepower) to the correct final answer.  Usually getting the optimum offering requires interaction and evolution.

Let's return to biology for a moment.  The eye is not perfect.  Remember those exercises you did in Junior High science class, they proved that we all have a blind spot, none of us can see in the infrared and some of us are color blind.  A perfect design would not have these traits.  However, as Darwin pointed out the eye is a great design.  So great that many believed omnipotence was required to create it.  I believe it ended up great, because each modification was tested in real use before it was incorporated in the final result.  This lesson is worth keeping in mind when you go to create your next great design.

Previous posts touched on some related topics: why great is often better than perfect; why we so often miss the real requirements; why interfaces are more important than code; and why a "truly complete" design is not what you want.
                                                                                 copyright 2007 Kerry Champion