A Simple Matter of Software

Leverage

To quickly generate dramatic growth in usage ventures need to use "leverage" to their advantage.

Marc Andreessen provided a simple definition of leverage, while discussing which businesses fit the "venture-backed startup model":

Startups that have a credible potential to be sold or go public for a 10x gain on invested capital within 4 to 6 years of the date of funding should consider raising venture capital.

Most other startups should not raise venture capital. This includes: ... startups where there's no inherent leverage in the business model that could result in a 10x gain in 4 to 6 years ...

Notably, there are many fine businesses in the world -- many of them highly profitable, and very satisfying to run -- that do not have leverage in their model that makes them suitable for venture capital investment.

By leverage in this context, I mean: the ability to make something once (a piece of software, a chip design, a web site) and sell it (directly or indirectly) to a lot of people (1,000 business customers or 10 million consumers) -- which leads to the classic "hockey stick" revenue projection.

While the above is acknowledged as true in the abstract, in practice actual startups often lose sight of this point and create patterns where there is not enough leverage.

Here is one typical software venture scenario:

• Start-up with no revenue and no market presence feels intense pressure to land some key large customers to establish their credibility and prove the value of their business proposition.
     
• Those initial large customers are hesitant to work with a small unproven company.  The start-up responds by saying "we may be small, but that is an advantage as we can be nimble and quickly deliver to you a product/service that exactly matches your specific individual requirements"
     
• This pitch succeeds and lands some important initial customers.  Because they see something working (after a long period of struggling) the sales team repeats the same pitch to other potential customers.
     
• Under pressure to move quickly the software team does not build a configurable platform but rather does customer-specific source modifications to the core product to deliver on what each customer expects.  Which leads to multiple source branches, high maintenance cost.  low ability to deploy new features across all customers, high incremental costs per each new customer, etc.

The above scenario is common and can lead directly to falling into a low leverage trap.

There are absolutely times when doing a low leverage special feature for a specific launch customer is the right thing to do.  The question is, do you want this to be a rare exception or is it a pattern you want to replicate?

Here are two models:

1. .“On-demand individualized customer service" model focused on directly  responding to unique needs of large customers, through a negotiated delivery plan.  “Professional services” companies such as IBM Global Services and Infosys fit this model.  As does a large part of the Defense industry: companies such as SAIC.
      
   
   B.
2. "Market service" model focused on executing roadmap that delivers high leverage: creating a single unified service/product that meets the needs of the broad market. Examples here include: eBay, Amazon, Google, Adobe, and Microsoft.

Successful businesses can be built using either model.  However, the "market service" model has higher leverage, higher valuations, and greater probability of leading to fundamental changes to how we work and live. 

If you have the opportunity to pursue this "market service" model you should clearly do so, even if it means extra effort and extra risk.

If your business does not lend itself to pursuing the "market service" model that is ok too, you can build a good business creating custom solutions for large customers.  However, that approach will mean slower growth than a successfull "market service" model and you need to make sure your team and investors understand that.

The one thing that absolutely does not work is to be mis-aligned:  you claim you are aimed at one of the models and some of your activities reflect that, but a large part of your actual behavior fits the other model the one you are not targeting.  This is a recipe for painful failure.

Committing to building a high leverage model takes real discipline: the engineering team has to avoid taking tempting (but non-scalable) shortcuts, the sales team will sometimes need to pass on a customer which goes against all instincts.  However, if you can recognize the difference between urgent and important, and instill that self-discipline you will be well rewarded.

                                                                               copyright 2007 Kerry Champion

At the start, what is more important than a business plan?

Rob Schultz has an excellent post on what are the key issues an early stage venture needs to focus on.

It is a common mistake to get so wrapped up in the mechanics of a business plan that you lose sight of more fundamental priorities (talk to users, make prototypes, envision specifics of how you will make money, etc.)   

Obviously you will need a formal business plan as you grow, but it can be a mistake to get too wrapped around the axle about it right at the start.

My take-away from Rob's post is that it is a good example of a more fundamental issue: "you need an attitude and practices that steer you away from wish-based planning and steer your towards practical reality checks".

Guy Kawasaki has a post on "Top Ten Lies of Entrepreneurs" that is done in a supportive way (he actually loves entrepreneurs) and highlights a different set of ways that new ventures can kid themselves (and their investors) with wish-based planning.

By the way, one comment in Rob's post that might be surprising but is certainly true is:

"I can't tell you how many plans or pitches I see where the entrepreneur has never spoken to the market they are trying to address.  What?!"

This post gives some more color on the particular issue of what gets in the way of hearing your customer.

                                                                                 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

Lessons from Iwo Jima

It has often stuck me that self-identity is the most powerful force driving human behavior.

The two recent Iwo Jima films by Clint Eastwood reminded me of this point. Why did the Soldiers, Sailors, and Marines on both sides fight and die so bravely. 

Were they, as the economists would have you believe, "rational utility-maximizers" who could lay out in detail why their behavior was in their narrowly defined self-interest?  No ..  I don't think so.

Didn't natural instinct tell them to behave differently ... don't storm up that beach ... don't fight to the point of starvation, dehydration, and death?  Well of course it did. 

Yet people ignored those instincts and did what would seem impossible.  If you asked them why, you might get an answer like the one my father heard as he drove the landing craft into the beach: “we are Marines and this is what Marines do”.

When they were given a clear connection between a crisply defined goal (take that Island) and their self-identity, their definition of themselves drove them to what seemed like extreme behaviors.

Luckily, no one faces machine gun nests on a software project.  Yet this insight still applies. How people define themselves will have a huge impact on what they accomplish and how good they feel about the time that they invest on the job.

Engineers self-identity includes not just how they define themselves, but also how they define their team, and what distinguishes their product. Engineers have a surprisingly large part of their self-identity wrapped up in the cool things that they build.

There is a lot of room for you to change what it is that distinguishes and defines the product and the team. As the manager a central part of your job is to understand what self-definitions support success and consciously work with the team to shape and articulate those definitions.

For the specific individuals on the team the scope you have to change their self-identity will be limited. (Just count all the disappointed spouses who thought his/her spouse “will change once we are married”.) However at minimum you want to understand how each person thinks of themselves and take that into account in how you help them stay motivated, how you relate their role to the overall effort, and how you help them develop as a professional.

While it is true that you may not be able to dramatically change the basic characteristics of the people already on the team. You should certainly be conscious of what team identity you want to build as you make choices on how to add to the team or subtract from the team.

It does not have to be true that the personality of a team always comes to mirror the personality of its leader. What you really want is the personality and identity of the team to be shaped by the nature of the challenges you are facing. And it is certainly true that a good leader can help guide the creation of that team personality and identity.

Here are some signs that your team has a clear identity:

• Team members can finish this sentence without having to think about it “The cool thing about working here is …”
• Candidates say at the end of the interview cycle: “I really liked the fact that I heard consistent answers to my questions from everyone I talked to.”
• Team members can answer the question: “What does our software do better then any other?”
• New hires say: “I think I am going to like it here because everyone is so …”
• Users of the software say “It is obvious that you really care about …”
• Everyone involved can say how the world will be different after you succeed.

In “Good To Great” Jim Collins has a general discussion of the importance of articulating the differentiating characteristics that define your organization. He has examples that show why it is so important that your team can answer: “What is it that you can be the best in the world at? What is it that you are deeply passionate about?”  Those are questions that every top quality team should be able to answer.

Related Posts:  discussed tendency to under invest in team development, highlighted need to think about both additions and subtractions when shaping the character of the team.

P.S. I am rooting for "Letters from Iwo Jima" in the Oscar race.  Seems unlikely it will get the prize but here's hoping.

                                                                                 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

Local optimization and global failure.

local optimum  definition:
1) A solution to a problem that is better than all other solutions that are slightly different, but worse than the global optimum.
2) We absolutely perfected what we were doing, only to discover that we should have been doing something different.

A recent New Yorker cartoon depicted two executives in the penthouse office of a business district tower, one said to the other "During my meteoric rise to the top, I failed to notice I was in the wrong building." This is a great example of the trap laid by local optimization.

Two common failure modes for mission critical software projects:

• Locally optimized to produce a solution that does not achieve our big audacious goal and does not provide the right answer to our defining questions.  But did cause us to feel good that we were "executing well".
• Go on a quest (unbounded by time or money) for the absolute global optimum among all the various local optimums.  Makes us feel good about our "commitment to excellence" but causes us to not actually deliver anything.

How to avoid these failures:

• Have a clear sense of what your audacious goal is and what defining questions need to be answered to get to that goal.
• Pick the first locally optimal solution that achieves the goal and answers the questions.  Once you find such a local optimum point don't continue searching for an alternative local optimum point that might be even better.

Finding the best path to delivering a software project is similar to picking a spouse:

• Once you find a significant other who you can find a lifetime of happiness with, marry them immediately.  Don't tell them "Well I love you, but would it be OK if I dated a couple of others before we marry just in case I can find someone even better?"
• Similarly if your current significant other doesn't fire your jets, then don't marry them no matter what, even if you have been looking for a while.

Translating that to the software world:

• Once you have a clear path to drive down to get your project to its audacious goals.  Then start pushing it down that path, don't look for an even better one.
• However, if good execution on the current path won't achieve your audacious goals, then you must step back and make fundamental changes.  Don't just reactively go through the process of local optimization, when that local optimization is not going to achieve what is required.

                                                                                 copyright 2007 Kerry Champion

Run the rapids with your helmet on

Shouting Distance has an interesting post on risk-taking and innovation in software (they are in favor of it :-). 

While I fundamentally agree with the post, there is an additional aspect of risk-taking that is important to emphasize: it is critical that you match the nature of your risk-taking to the nature of your goals and challenges.

If your team is doing maintenance of embedded software for a pacemaker, than general risk aversion is probably the right strategy.  If you are at a Web 2.0 venture backed start-up than a knee-jerk risk-aversion is a bad thing.

However, even in the case of the Web 2.0 start-up it is important to be selective about what risks you take, and match the risks to the goals.  Push-hard and take risks where the pay-off from that risk directly addresses your audacious goals and defining questions.  However in all other aspects of what you are doing, avoid risks and do what is proven to work.

If you travel 7000 miles to Futaleufu Valley so you can raft the river, than you certainly should not portage around the Level 5 rapids.  You should take the risk and run the rapids, that is the whole reason you are there.  Taking that risk is needed to achieve the objective.  However you should not tell the driver to drive 60 mph down the cliff-hugging dirt road and when you get in raft you should not leave your helmet on the shore, taking that risk does not help you achieve your goal.

Once your realize that taking a particular risk provides no meaningful acceleration towards your big goals, than you need do no more research and no further cost benefit analysis.  For example if one of your crew says "Ok using one of these new 'aerogel' helmets does not help us achieve the main goal, but it is cheaper and more comfortable and it is cool!  Can't we at least look into it and learn more about it."  than a good response might be "No, lets avoid the distraction, lets use the conventional tried-and-true helmets and lets focus 100% of our mental energy making sure we succeed where we are taking big risks, because those risks are the ones that matter."

In the case of the Web 2.0 start-up you may need to bet the project on your ability to add some fundamental new capabilities in AJAX, that others have not delivered before.  Because those capabilities are required to deliver the user experience which is your goal.  Once it is clear you need to take that risk you should embrace it and get everyone jazzed about taking on this challenge However, in other aspects of the project my advice is be conventional , and stick to the tried-and-true.  You are much better off taking on a small number of big risks and making making sure they pay-off, than you would be if you took on a larger number of smaller risks and had one blow up in your face because you were distracted.

                                                                                 copyright 2007 Kerry Champion

Finding the defining questions.

Over the course of a major software project there will be tens of thousands of issues to be resolved, actions to be taken, and results to be delivered. I have found that a surprisingly small number of those represent the “defining questions”. These are the questions where there is a real room for debate about what should be done and the answer will have a fundamental impact on what you build and how you build it.

The other surprise is how often these questions are decided in a backhanded ill-considered fashion. We will spend hours and hours debating “who goes in a cube and who goes in an office”; or “should the release date be on the 9^th or the 16^th” but for far more fundamental questions we will often latch on to the first reasonably sounding answer and give it no more consideration.

These defining questions are sometimes product/engineering specific, but they can also be more fundamental business issues whose resolution drives the product/engineering team.

Real world examples of such questions include:

• Will we deliver a thick client, thin client, or both?  
• Will we commit to performance as our product differentiator, even though that means making compromises elsewhere?    
• Will we reuse the data store from a related open source product or build our own?      
• Do we need a non-traditional processing/threading model to achieve our performance goals?
• Will we limit our initial users to folks who already have this popular user directory installed?
• Are we targeting small installations that must be self-service or big installation where we can expect to provide some technical hand-holding?    
• Do we create our own scripting environment or can we leverage a relevant standard?  
• Will we have all development at one site, or multiple development centers on multiple continents?     
• What is our critical IP and what can we buy in or contract out?       

It is a truism that “sometimes the hardest part of solving a problem is correctly posing the question”. That is absolutely the case.

You can look at any software project and generate dozens and dozens of questions similar to the ones above. But only a fraction of them are really worth examining. First you need to parse out the questions that are secondary (at least for now) and can be answered later. Second you need to parse out those questions that are indeed important but where there really isn’t a basis debate, but rather you should just stick to the obvious consensus answer. Having parsed down the list you should have a half dozen or less defining questions

Once you have identified the defining questions you need to invest the time to:

• analyze and answer each question
• build a common understanding among the whole team of what the decision is and why it was made
• get everyone’s day-to-day activities aligned with those decisions

This is harder than it sounds. Partly because these critical questions sometimes sound rather distant and theoretical, as opposed to the current “crisis” that needs to be dealt with “today”. It is always tempting to go fight a fire rather than to steadily build towards a big goal that takes multiple layers of accomplishment to really fulfill. The crisis of the day may be “large prospective customer has an old Windows version that does not work with our thick client, how quickly can we generate a patch?”, but the key defining question maybe “should we have a thick client at all, or can we succeed with an AJAX implementation?” To succeed you have to pick and chose what are those defining questions and figure out how to carve out time to answer them.

                                                                                  copyright 2007 Kerry Champion

Congratulations! It is do-or-die time. What now?

So you have just been given the burden opportunity of managing a high profile software development project with an aggressive set of goals that are critical to your organization’s future success. A true “do-or-die” project.

The expectations have been set high. The time frame is short, the feature content is ground-breaking, the competition is moving quickly to leap-frog over you, and the customers have critical needs many of which have not yet been uncovered.

Cool! So what do you do now?

Certainly step one is to make an assessment of the state of the project, where one of the key things you are looking to learn is: what is within my control and what is outside my control. You almost never have the luxury of putting everything on hold while making that assessment, so this will need to be an in-flight evaluation. (A later post will discuss this process.)

You will discover a dispiritingly large number of things that are outside your control. But there is one thing certain to be in your control: how you will behave, what example you will set for others.

Luckily that is the one thing that will matter the most to your sanity. This is a project that will consume a meaningful chunk of your life. You will accomplish more and feel better about the experience if you have a directed conscious agenda for how you get things done.

Sometimes you get things done by proactively defining what issues need attention and then pushing those to the front-burner. Other times you will reactively respond to issues raised by others. The accepted wisdom is: Proactive = Good, Reactive=Bad. Two interesting points about this truism: first it is not always true; second when it is true it is almost never fully put into action.

90% of the time falling into a reactive management mode is the wrong thing to do. Yet there are exceptions, for example if you have a solid team in place with good candidates banging on the door to join, and your product is being caught up into a tornado of user acceptance then it very well may make sense to respond to the obvious issues that are right in front of your face and scramble up the user acceptance curve as fast as you can go. Moore’s classic Inside the Tornado does a good job of describing this state.

Remember though riding the tornado is the exception, even teams that do eventually “bang it out of the park” can spend long stretches of time pushing to get all the right pieces in place. The fact that you were just given the burden opportunity of managing this project suggests there is something that needs to be fixed before you get to that whirlwind of user acceptance. If nothing needed changing no one would shake up such a critical project by putting a new manager in place.

So you know change is required and it makes sense that a conscious proactive effort is the right way to approach that change. What then are the seductive forces that so often pulls managers into a reactive mindset:

• Confusion of the urgent and the important      
  
  
• Wish based planning       
  
  
• Misunderstanding what it means to support your team       

We will talk about each of the above in coming posts.

Having navigated around the above landmines and completed your assessment of the state of the project you are ready to start you informed proactive management of the team. What now?

You can start by doing following the time-honored maxim: “when in doubt – create a PowerPoint”. A presentation covering the key topics has some advantages:

• by writing it down you are forced to think clearly about the issues     
   
• the presentation format means a minimum number of words which means a minimum amount of time spent on crafting and wordsmithing the document itself
   
• having taken the time to create a “presentation” you will feel a moral imperative to actually show it to somebody. No matter how salient your insights they really have no value if you don’t test them, evolve them and put them into practice, To do that you most communicate them early and often, hording them for a special occasion tends not to work as well

The topics to hit in this first presentation depend on the specifics of the project. Generically there are three things you will want to cover:

• Do you have the right people on the team?    
   
  
• Have you articulated a set of defining questions/actions/results?           
     
• How will you refine your process, so that with each turn of the wheel you get better and better at what you are doing?        

We will talk about each of the above in coming posts.

                                                                                 copyright 2007 Kerry Champion