A Simple Matter of Software

Existentialism, corporate strategy, and the trap of local optimization

Existentialism is one of those words that we all stumbled across at university and never really understood (unless you smoked and read Sartre in the original French).

Even though Existentialism often is an unknowable irrelevant philosophical debate, there are Existential concepts that apply to how  we create strategy in the business world.

For example, a basic Existential concept is that our nature and identity  are defined by the  choices we make.  The same is true for companies and development teams.  We either let things happen to us or we make things happen around us. 

To make things happen you have to make choices.  If you simply make a laundry list of "everything you might want to be, see, and have" then you probably are not creating a strategy that can be executed.   Most likely you are creating what in the short term is an unattainable plan.  This means that instead of making the choices that define who you are, you punt on making those decisions and leave it up to external forces, circumstance, and random chance to define you.  This is an  anti-Existential approach to life.

Sometimes the things that are happening to us are good things (revenues are growing, big customers/partners want our attention and want to influence what we do, etc.).  However, even when good things that are happening to us, we should not let them by default define our strategy, we should make a conscious decision about what our strategy is even if it temporarily takes us away from some of that positive feedback.  Those good things may be leading you to local optimum which is a far less attractive that the global optimum you could reach if you took charge of your own future. 

A New Yorker cartoon did a great job of defining the trap of the local optimum, it depicted two executives in the top floor of an office tower, one saying to the other "During my meteoric rise to the top, I failed to notice I was in the wrong building."

                                                                               copyright 2007 Kerry Champion

Don't leave the trail and fling off your clothes

Software ventures are by definition high-risk operations that will often experience set-backs and failures.  How you react will determine whether you enter a death spiral or power past failure to find real success.

I was reminded of this while reading Bill Bryson's "A Walk in the Woods", in particular his description of hikers struggling with hypothermia had a real resonance.  In his examples the death spiral involved actual not figurative deaths.

Popular impressions to the contrary, relatively few victims of hypothermia die in extreme conditions, stumbling through blizzards or fighting the bite of arctic winds ... [most] die in a much more dopey kind of way, in temperate seasons and with the air temperature nowhere near freezing.  Typically they are caught be an unforeseen change of conditions [for which they are unprepared] ... Nearly always, they compound the problem by doing something foolhardy - leaving a well-marked path in search of a shortcut ... fording streams that get them only wetter and colder.

Hypothermia is a gradual and insidious sort of trauma.  It overtakes you literally by degrees as  ... your natural responses grow sluggish and disordered ... [It leads to] desperate and irrational decisions ...

A person suffering hypothermia experiences several progressive stages ... profound weariness, heaviness of movement, a distorted sense of time and distance, and increasingly helpless confusion resulting in a tendency to make imprudent or illogical decisions and a failure to observe the obvious.  Gradually the sufferer grows thoroughly disoriented and subject to ... decidedly cruel misconceptions .. Many victims tear off clothing, fling away their gloves, or crawl out of their sleeping bags. 

Software ventures that experience some serious difficulty can fall into a similar pattern:

• Conditions prove to be different than you had assumed.  The scope of the problem is bigger, or the number of competitors is greater, or the receptiveness of the market is slower than you had hoped.
• You could use this information to make a one-time fundamental revision to your methods and goals.  However, you are so latched on to your current assumptions and commitments, that you can't bring yourself to make an fresh objective evaluation.
• You refuse to recognize that there is any fundamental barrier to achieving your existing plan.  You steadily warp how you define and report your metrics to support this position.  You develop  "a distorted sense of time and distance" and "a failure to observe the obvious".
• You assume that if everyone just works harder than anything is possible.  Ignoring how the resulting "profound weariness" effects everyone's judgment and perspective.
• Often that hard work is spent pushing down the wrong path.  You don't recognize that superhuman effort is no replacement for good judgment and correct direction.
• As "your natural responses grow sluggish and disordered" you make increasingly "desperate and irrational decisions".
• Finally your "misconceptions" lead to making "foolhardy" decisions and attempting muddleheaded "shortcuts" that actually take you further from your fundamental goal.  In effect you leave the trail and fling off your clothes.

The best way to handle changing conditions is an approach of:

1. proactively prepare for potential potholes
2. clear-headed measurement of current progress
3. decisive corrective action when needed

However, you don't want environmental changes to be used as an excuse to cover poor performance or a lack of commitment to deliver results.  Part of your role as a leader is to make sure that changes to a committed plan honestly are optimizations in the face of new information and not cover ups for sloppy work.

                                                                                 copyright 2007 Kerry Champion

Seven things to keep in mind when making course corrections

In previous post we have discussed the value of metrics and measuring progress against the plan.  Obviously measurement is not enough, acting on that measurement is also required.

It should be a basic part of your leadership MO to measure progress and take decisive corrective action based on what you see.

However, there are a couple key points to keep in mind in implementing this practice:

1) Don't flip-flop via overcorrection.

Take a lesson from fuzzy logic implementations such as the speed control on the Tokyo monorail and the automatic headlights on your car.  In the automatic headlight example you wouldn't want an implementation that flipped the lights on and off as you drove through brief patches of shadow.  When the light sensor tells the embedded controller that the darkness threshold has been exceeded, you probably want it to wait a little bit to see if that trend continues and is sustained before flipping the lights on.

2) Have a graduated series of corrective actions, starting with paying more attention

Usually the most extreme corrective actions are very disruptive and can have negative side-effects with the law of unintended consequences causing surprising blowback.  Often you want to have a series of corrective actions with less disruptive actions implemented first. 

The very first corrective action (and often the most productive one) is simply to pay more attention to the problematic area.  Once you see a metric going off the tracks, dig in and research further, ask questions, get opinions from others.  Mechanically implementing a predefined corrective action is usually not the right thing to do.

3) Recognize the difference between corrections and resets

You could argue that this difference is just a matter of degree.  Yet it is an important difference.

"Corrections" are changes that are disruptive to varying degrees, but don't change the fundamental direction and don't require a complete re-examination of all assumptions and decisions.

"Resets" on the other hand  are more  fundamental changes  that are  in essence defining a new plan, that may reuse some elements of the previous one but is really a new project.

It is normal to implement multiple corrections during the course of implementing a project.  Most of the time you don't implement a reset to a project.  If you do implement a reset you will only do it once per project as the result is in essence a new project.

One failure mode for ventures is to have the "meantime between project reset" be less than the "meantime required to complete a project".  In this case you will rarely complete anything.

4) Help people see it coming.

There are always a few metrics that involve sensitive data that can not be widely shared.

However, as a rule it is better to share your metrics and measurements broadly within your own organization and with other teams that you work with closely. That sharing should occur as a matter of course before any corrective action, and not just as a justification when actions are announced.

A primary benefit to broad sharing is that it means people are more supportive and less surprised when you do need to change things.

Other benefits include that others may recognize issues in the data that you have overlooked and that people will often self-correct on their own initiative for that subset of items that is within their individual control.

5) Understand downstream impacts.

When considering corrective actions it is natural to focus on the impact within your own organization.  However the downstream impacts on other teams is often as great or greater.  Therefore you need to be conscious of those impacts and often bring folks from those teams into your decision making process.

6) Understand the human impacts.

People are disturbed by change: it knocks them out of their comfort zone, it can make them less productive, if mismanaged it can make them leave the company.

Therefore, in thinking through any changes to the plan you need to consider not just the project management perspective, but the human and emotional considerations.  Those factors should not freeze you into inaction.  However, they may impact your decision on what action to take, and they certainly should impact how those actions are communicated.

7) Explain the "why" of your decision.

Related to the above is the need when announcing a change to explain not just what action is occurring, but also why.

                                                                                copyright 2007 Kerry Champion

Pangloss was wrong - proactively preparing for potholes

Any activity, whether it is building a cabinet in the garage or building a new online service, is subject to a wide range of things that might go wrong.   There are two ways to deal with these potential potholes in your path forward:

• Reactive approach.  Ignore all potential problems, assume that dwelling on them will discourage you from making any attempt at all.  Behave as if there is no chance that there will be any variance from the initial plan.  Take it for granted that we live in the best of all possible worlds and that things will just work out.
                 
• Proactive approach. Once a plan is proposed, ask the team what are the three most likely things that could go wrong (my experience is that these forecasts are 70%+ accurate).  Make a point of sharing this forecast widely and publicly (team meeting and internal wiki are good mechanisms).  Use a combination of explicit preventative measures and conscious contingency planning to minimize the impact of these potential potholes.

It is obvious which approach is better.  However, it amazes me how often the Panglossian approach is  followed instead.

                                                                                 copyright 2007 Kerry Champion

Make New Mistakes

There are some bits of wisdom that are so often repeated that we become desensitized to the need to take action based on that truth.

For example, we have all heard and agreed with some version of:

"Insanity is doing the same thing, over and over again, but expecting different results." - Rita Mae Brown

“Progress ... depends on retentiveness. Those who cannot remember the past are condemned to repeat it.” - George Santayana

"Always make new mistakes" - Esther Dyson

Yet it is common for software ventures to repeat the same mistakes made in the past.  Why is that?

I don't claim to know the full answer, but here are some contributing factors:

1) Reactive vs. Proactive mind-set

If you manage by waiting for bad things to happen and then reacting to them you are more likely to fall in the same bad patterns again and again.

If you manage by proactively defining and driving an agenda for change you are more likely to avoid old mistakes and discover new ones.

2) Deferred Gratification and Impulse Control

Organizations with poor impulse control tend to repeat the same mistakes again and again.  Software ventures that master the art of deferred gratification will have better long term results.

3) Wish-based Planning

You often see old mistakes repeated anew, when organizations make plans based on how they "wish" things were rather than based on a more realistic assessment.

Lots of examples of this sort of behavior in:

• assessing feedback from customers
• dealing with unpleasant truths
• assessing how feature commitments will impact your ability to innovate
• defining your market
• deciding how to throttle your spending plan
• etc. etc.
  

4) Urgent vs. Important

Organizations that only react to the urgent and never focus on the important, tend let avoidable mistakes occur and than run a fire-drill to respond to them. They then repeat the process again and again.

It is critical that you know how to distinguish urgent from important and why that matters.

5) Low Investment in Lessons Learned Exercises

One important activity that is often pushed aside in favor of more urgent ones, is the "lesson learned exercise."  This goes by different names in different organizations:  "after action report", "debriefing", and "postmortem" (my least favorite term).  In all cases it involves a conscious systematic process to look at what as been going well, what has been going badly, and how the team can learn and improve.

Investing in a "lessons learned" process will decrease the chance of repeating old mistakes.

6) Split Incentives

If different parts of the organization have different incentives and priorities you can easily create situations where specific individuals are motivated to lead the team into making the same mistake again and again.

If you build an engineering team that is motivated by a desire to "build frameworks" and you don't clearly communicate the organizational imperatives that might motivate them to "buy the framework and build a solution on top" than you will repeatedly err on the side of investing too much in building frameworks and not enough in building solutions.

If you have a sales team where there cash compensation is based 100% on "signing new contracts" and 0% on "keeping customers happy through deployment and use", than you will consistently make mistakes around over-committing and under-executing.

In both the above examples the motivations of parts of the team are out of alignment with the organization as a whole.

   

                                                                                 copyright 2007 Kerry Champion

Does your team pass the marshmallow test?

Predicting the adult success of a 4 year old is a tricky business.  Understanding how income differentials arise in primitive economies is a tricky business.  Guiding a software venture to long term success is also a tricky business.  I believe there is at least one common lesson that applies to all three.

It is very hard to look at a 4 year old child and predict how successful they will be as an adult.  At that age all the normal aptitude and intelligence tests don't seem to be good predictors of ultimate life outcomes.  However an exception are tests of deferred gratification, such as the famous marshmallow experiment.  Wikipedia does a good job of summarizing:

The marshmallow experiment is a famous test of this concept conducted by Walter Mischel at Stanford University and discussed by Daniel Goleman in his popular work. In the 1960s a group of four-year olds were tested by being given a marshmallow and promised another, only if they could wait 20 minutes before eating the first one. Some children could wait and others could not. The researchers then followed the progress of each child into adolescence, and demonstrated that those with the ability to wait were better adjusted and more dependable ...

... Shoda, Y., Mischel, W., Peake, P. K. (1990). Predicting adolescent cognitive and self-regulatory competencies from preschool delay of gratification: Identifying diagnostic conditions. Developmental Psychology, 26(6), 978–986.

An analogous study was done to try and explain the rise of income differential.   An experiment was conducted among the Tsimane', a group of Amerindians who live in the Amazon.  The Economist summarized it well in Economics and Anthropology - Patience is a virtue, Feb 8th 2007:

... Exactly why some people were able to accumulate more than others has been something of an anthropological mystery ... the main hypotheses have been luck, intelligence and aggression. These all, of course, play their part, but now a fourth phenomenon has been added to the list: patience

... One phenomenon that is almost unique to humans is deferred gratification ... the researchers offered all 151 adults in two Tsimane' villages a choice between receiving a small amount of money or food immediately, getting a larger amount if they were willing to wait a week, and getting a larger amount still in exchange for several months' wait for payment. ... Five years later, Dr Reyes-Garcia and her colleagues came back again ... and found that those who had shown most patience in the original experiment had also seen their incomes increase more than those of their less patient counterparts ...

The same concept applies to software ventures. Organizations that master the art of deferred gratification will have greater success over time.

There are plenty of times when you will be tempted to do something that feels good at the moment, but won't be the optimal step for the long term.  Previous posts talked about situations where it makes sense to pass on a customer or hold off committing to additional features, even though there is a lot of immediate pressure to take those steps.  Sometimes you just have to say no to the marshmallow right in front of you, to get more marshmallows later on.

However, like any good idea it is possible to misapply it.  It is critical to remember that software enabled ventures usually have limited windows of opportunity, so that being too late often means failure.  If you don't quickly package up a useful set of features, if you don't close a critical mass of reference customers early, you may miss your window altogether and never have a chance to collect any marshmallows.  Implicit in the concept of "deferred gratification" is the idea that you are selectively choosing to defer some benefit only in cases where that deferral increases the total benefit.  Buying into the concept of deferred gratification is not a license to lose your sense of urgency.

Using deferred gratification to your advantage is just one part of a broader proactive leadership style.  The most success goes to those who don't just react to opportunities and problems that pop-up in front of them, but rather take charge of the agenda and proactively manage the team with a clear vision of where they are going.

                                                                                 copyright 2007 Kerry Champion

When to fire a customer

The Welch Way column in Business Week tackled the interesting question of when should you fire a customer.  One of their three scenarios is particularly relevant to the software venture:

".. when a customer demands a one-off product that sends your R&D group in the wrong direction, away from your own strategy and financial goals.  Again, this is a case where your salespeople might be hollering for support but where the long-term diversion of resources is a killer.  Unless it is an exceedingly profitable customer, you have to just say no."

New software ventures must be flexible and listen carefully to their prospective users.  They also must have a clear model of what they are trying to build, how they will earn a profit and who are their target customers.   You most recognize that not every prospective customer fits within the model.  You need to proactively decide which customers will help drive you to where you want to be, and which will take you into a cul-de-sac.

The Welch's make an exception for "exceedingly profitable" customers.  Those are good exceptions to make, as real profits can feed your ability to build to your ultimate goal.  But it is important to make the distinction between "high revenue/commission" vs. "high profits".  When all expenses are truly taken to account, high revenue may not be high profit.  In general we tend to underestimate the cost of doing customer specific enhancements, so we need to be careful to get those estimates right.  From a short term revenue growth perspective it may feel good to do these high revenue no profit deals (especially if the revenue is front-loaded and the cost is back-loaded), but in the long run it is actually destructive to have a big chunk of revenue that drives an equally big chunk of expense that is spent on building something that is not your target product and does not have  repeatable sales model.

Just as important as the income statement costs, we need to understand the "opportunity cost".  If we are spending management and technical team time on something customer specific, that is time spent not pursuing your central value proposition.

Paying this opportunity cost can kill your ability to innovate and build real differentiation.  In economics there is the concept of "disposable income" meaning the income you have left over after the basics (taxes, rent, food) are paid, where you actually have a lot of latitude on how you spend that money.  You can imagine a similar concept in time management of "assignable time", meaning the time you have left over after doing all the "must do" tasks.  The mgmt/tech team at a software venture typically has very limited "assignable time", spending that time on customer specific distractions means you not spending it driving forward the differentiating innovation that will be the real basis of your long term success.

It is hard to strike the right balance: being flexible and really listening is critical; chasing every opportunity you see is destructive.  I have seen errors in both directions.  If you believe that the opinions around the conference table are more valuable then the opinions of your target customers, than you are almost certainly making the first sort of mistake.  If you never make the hard decision to walk away from a high revenue but distracting deal, than you are almost certainly making the second sort of mistake.

Previous posts have touched on related topics:  Lilliput vs Innovation, Local Optimization, and Finding The Defining Questions.

                                                                                 copyright 2007 Kerry Champion

Success Delusion

Marshall Goldsmith has an interesting article titled "The Success Delusion" in The Conference Board Review.  For those of you who (like me) are not subscribers, the New York Times has a summary here.

As historians like to point out Generals almost always start the current war be trying to re-fight the last one.  The tendency applies to the business world as well.  It is a bad idea to simply apply to your current situation what has worked for you before, without thinking through why it worked and what has changed.

Goldsmith was not focused on high-tech but lessons from Silicon Valley suggest that his central message applies to the software world as well.

Anytime you do a multi-year mission critical software project (in-house or startup) you will find that it breaks into distinct phases.  Phase definitions will vary, here is one example:

1. Conception and exploration
2. Proving viability of implementation and value proposition
3. Building pilot system and initial production use
4. Scaling up
5. Line extensions into neighboring spaces

What approach works in one phase that gets you to certain level of tangible success, may be exactly the wrong approach for the next phase. 

This is a hard lesson to internalize.  You will work hard for a year and finally break through by achieving a major goal, and then you need to immediately question everything about how you should move forward.  The talent mix, the practices, the attitudes that got you your current success may very well be the wrong ones to get you to the next dramatically higher level of success.

As Goldsmith puts it:

“Any human will tend to repeat behavior that is followed by positive reinforcement ... The more successful we become, the more positive reinforcement we get — and the more likely we are to experience the success delusion: I behave this way. I am successful. Therefore, I must be successful because I behave this way.”

... therefore I should continue to behave this way. 

There are two obvious fallacies here.  One that Goldsmith emphasizes is the fact that not all of your behaviors were directly relevant to your success and therefore you are attributing causation to a behavior-result when the behavior was really just noise.   

Another fallacy in this mindset is that it fails to recognize changes in the environment and circumstances.  This fallacy is the more critical one in the high-tech world.  High-profile software projects inherently have changing circumstances as they move from phase to phase,  they also almost always have very rapidly changing external environments.  The high-tech landscape is defined by constant motion.

In the high-tech world an archetypal example of phase to phase environmental changes is the difference between defining a break-through innovation vs. standardizing and scaling up that innovation.   Each of those steps requires a dramatically different approach to staffing, organizing, motivating, and measuring progress. 

Obviously there should be some critical continuities between the phases.  Key people, key goals, key philosophies that are constant throughout.  So while you should question everything you should not blindly throw out everything.  What is needed is to recognize that the normal tendency is to question too little rather than too much.  Then having recognized that and taken your blinders off, you must use the right judgment to make sure you strike the right balance.

It is human nature to believe that what worked last year will work next year.  People naturally want to build a stable environment: a comfort zone.  But when working on multi-year mission critical software projects that is almost always wrong.  With each significant success you need to question everything;  recognize those defining questions and critical success factors that matter the most in getting to the next phase; and where it is needed you must tear up what you have built and reconstruct it to meet the new challenge.

                                                                                       copyright 2007 Kerry Champion

The Replacement

Mission-critical software projects typically have:

• high expectations
• high stress
• multiple phases (spread over years) where each phase requires a significantly different mix of skills/behavior from the team and the manager
• a need to be very agile and to adapt quickly in the face of new information

If the team needs to evolve in response to the above characteristics, that typically can be done through various additions/subtractions while keeping a core group that provides continuity. 

If the manager needs to change, you sometimes can keep the previous manager in a new role, but often you end up replacing one manager with another.   What should you keep in mind if you are the replacement coming into this situation?

Business Week had a surprisingly relevant sidebar this week.  The nominal topic was how to replace a CEO, but it applies just as well for a VP of engineering coming into the latest Web 2.0 company, or a just assigned project manager trying to release a new service from eBay.

The four key points are quoted below.

"Be Your Own Person 
Don’t try to be someone you’re not. ... Also, introduce (or reintroduce) yourself to the company and let them know who you are and what you want to accomplish."

You should have a point of view, you should have a philosophy and you should have a history.  You don't want to lecture the team about any of those things, and you certainly don't want to talk more than you listen.  But anyone who spends time with you should get a clear sense of where you are coming from.

However, even more important than who you are is what you expect from the team and individuals.  You should have a clear set of expectations and you should communicate those every chance you get.  Initially your expectations may be rather general ("we will build a team that says what it will do, and then delivers it").  But as you learn more about the situation, and given everyone a chance to provide their input, those expectations should get much more specific ("our AJAX implementation will have large file upload performance that is 5x what it is now") and even more specific ("Tom, by the end of the month we need your component implemented to match the spec that you proposed to the team this morning").

"It’s Not About You
It’s about the company and the people who work there, the customers you serve, and the investors who are looking for an attractive return. Give credit to others for successes and use “we,” not “I”—except when shouldering blame."

While you should certainly have opinions and a point of view, you should not redefine the world based on your experiences and biases.  Those team practices that are working well should be left alone, even if they are different from how you worked in the past.  You should be adaptable and learn from the team.

In some professions (sales for example) a certain amount of "marking your territory" behavior is expected.  In engineering it is not respected at all.  Everyone has better things to do then deal with unnecessary changes that are only being made so the new boss can establish his authority or create a comfort zone for himself by making his new environment just like his old one.

"Establish Three Powerful Themes
Make them straightforward and use them consistently and relentlessly. The three themes (two seem incomplete, and people won’t remember four) need to be sufficiently specific to be meaningful, yet general enough to serve as organizing principles."

Beyond avoiding unnecessary (negative value) changes, I recommend you avoid immediately implementing a bunch of positive but low-payback changes.  You can always make those additional optimizations later on.  It works so much better to focus all your energy on a small number of high-payback changes instead of a large number of low-payback changes. 

Like a newly elected politician a new manager has a certain amount of goodwill and capital to spend.  I strongly recommend you use that honeymoon period when everyone is listening closely to what you have to say, to define and implemented a very focused agenda.  Pick those three key themes that may involve big changes (but have big-payoffs) and push on those.  After showing some success (and building some team confidence) with those, you can push on to other issues and themes.

"Never Speak Ill of Your Predecessor"

Even if the team hated the guy, it will earn you no credit to belittle him.  Most people won't respect that approach.  And the folks who do want to sit around and bitch about the previous guy are folks that you certainly don't want to encourage and may want to subtract from the team.

Of course you may need to raise concerns and even completely reverse certain practices and decisions.  In each of these cases you will be fine if you focus on the issue (advantages/disadvantages, fit with current direction) and avoid attacking the person who made the original decision.

Failing to implement the four ideas above is usually a sign of being too reactive and emotional.  When you don't have a plan but simply parachute in and react, it is natural to:

• get pulled into a million little firefights
  instead of having some big themes
• to bitch about your predecessor
  instead of staying focused on the way forward
• to try and build a comfort zone for yourself by recreating your previous environment
  remember it is not all about you, marking your territory by making things work your way does not help.  It is implementing changes that have a direct connection to your themes that helps
• to not make it clear what your expectations are
  because it is not clear in your own mind

It is tough being the replacement.  However, there is no question that you can make it easier on yourself and your team.  The four rules of thumb in the Business Week article are good rules to live by, but you could probably invent another set of guidelines that are equally good.  What is important is that you:

• listen
• build a plan
• communicate the plan
• don't fall into the reactive trap

If you do that you will do fine.

P.S.
Business Week used James Citrin of Spencer Stuart as the source for their article.  More detail on his thoughts can be found here and here.

P.P.S
If you have never listened to The Replacements version of Red Red Wine, you might want to give it a try, it is unique ;-)

                                                                                       copyright 2007 Kerry Champion