The Lean Software Enterprise

A young friend of mine, Amber, just got promoted to manage a customer support team for a satellite company.   Amber described her team as frustrated by seemingly conflicting goals, including spending less time on each call while improving the resolution rate. Team members would keep improving in one area while compromising in another.  Most of them lacked a sense progress and were losing their motivation.  Her attempts to correct them felt futile.  How, she asked, could she get them energized and unstuck?

I suggested that she work with the team to create a vision of success that was free of contradiction.  After all, unless the team members could tell what the perfect caller experience was, how would they strive to recreate it?   I also suggested that she should think of herself less like a boss and more like a teacher or coach.  We talked about her holding regular "reflection sessions" where people could discuss their calls and the issues they were seeing.  The group could then capture and share knowledge about how to improve.

Amber thanked me and seemed excited about these ideas, but I wondered what her peers and bosses would think.  It was discouraging to learn that she had not been given any sort management training.  As is often the case, she was promoted based on her own experience as a customer support representative.

No doubt Amber is one of many managers in that organization struggling because the executives have not paid much attention to developing their managers.  But even when they do, what ideas are being taught?  The conventional view of management is that is consists of "utilizing resources, including people, to get acceptable results within known constraints."  That's a direct quote from a lecture Carly Fiorina gave at Stanford after her ouster from Hewlett Packard. 

For me, this description brings to mind Dilbert-style middle management drones devoid of imagination and initiative.  I picture them working for executives whose focus is on “making the numbers” and who care little about the longer term vitality of the organization and its people.   This is not the stuff of greatness, but I'm sure it's "acceptable".

In contrast, a learning organization is one where short-term execution targets are complemented by learning goals.  Continuous improvement is a way of life, and it is reflected by a rapid rate of innovation in products, services, and processes.In a learning organization, the purpose of management is to establish clear goals and then organize a productive doing-learning loop.  The objective is not merely to “make the numbers”, but to always get smarter.  Managers work with individuals and groups to facilitate learning and problem resolution, but tend to avoid telling people what to do. 

Sounds too soft?  Try this one on for size: If you are micromanaging people you are being too easy on them!  By doing their thinking for them, you are relieving them of the necessity to grow and learn.  So be their teacher, explain everything they need to do know, but let them do their own homework.

So what's a manager to do?   Achieve rapidly improving business results by working with your people to help them grow and learn.   That's the purpose of management in a learning organization.

I am at the San Jose airport waiting to board my flight back to San Diego.  It has been an interesting trip up to Silicon Valley as usual.  This week I attended the first annual Lean conference of BAE Systems.  BAE is a global $27B aerospace & defense enterprise with 96,000 employees in a dozen countries and they appear to be getting quite serious about their Lean initiative. 

While I would have liked to come back with some photos, this conference was held at a secure facility, so no cameras were allowed.  I will do better next time -- I have two more talks coming up in the middle of next month, in San Diego and Palo Alto.

The BAE conference was two and a half days in duration and the agenda consisted mostly of experience reports by BAE managers with a few outside experts invited to provide new perspectives, ideas, and case stories.  I gave two presentations - one on Lean Product Development applied to software, and another on Information Architecture in Lean Product Development.  More about those two topics soon.

There were also a couple of other folks talking about Lean Product Development, including Ron Mascitelli and Mike Gnam.  Mike Gnam is the excutive director of the Lean Product Development Initiative at NCMS, the organization that did the original benchmarking study of the Toyota Product Development System back in 2000.  Bob Stow, BAE's CTO, also discussed the application of Lean to software-intensive programs in his opening remarks.

The Lean Manufacturing presentations looked great -- lots of solid, practical results with justifiably fired-up presenters.   They have done enough now to encounter their first set of practical obstacles in scaling their efforts, and that is a good place to be.  There was clearly a lot of learning going on.  That included learning about how to teach Lean -- one business unit in the UK reported great success with a three-week program for Lean Manufacturing that involved a mix of 25% theory, 25% homework, and 50% hands-on classroom learning with exercises.

The BAE conference was remarkable in that the leadership is clearly trying to encourage practitioners to learn from each other.  It is not just a classical top-down effort.  The internal experience reports were given by smart, talented, and energized middle managers who are in many instances given a lot of leadership support and a lot of latitude.

BAE is in the process of launching an internal Community of Practice using SharePoint to host discussion groups, share files, etc.   This mirrors what a customer of ours that is also in the defense sector has done.  I think it will be very helpful. My only worry is that they will emphasize too much the IT aspect of a Community of Practice and miss out on the in-person aspect.  Getting people together is really important, and this conference was a good example of that.

My main interest at this conference was to learn about what other people were doing with (and saying about) Lean Product Development.  Clearly there was still a fair amount of confusion about what Lean Product Development is really supposed to be about.  In his presentation, Mike Gnam very correctly pointed out how focusing only on individual Lean tools (value stream mapping, kanban, etc.) will NOT yield breakthrough results beyond all the low-hanging fruit that one will catch the first time around.  

I know it sounds like a cliche, but Toyota's approach to product development really DOES represent a paradigm shift.  I do not think holding on to existing frameworks (whether CMMI or Agile) will be helpful in the long run. Organizations that want breakthrough improvements have to revisit and rethink their fundamental premises about how work is structured.

That is my take on this, anyway.  I think there is going to be a lot of good debate around this -- just how should leaders help their organizations transition to Lean?  Some speakers were clearly influenced by the Six Sigma approach to organizational change, advocating a model where trained and certified blackbelts do improvement projects.

Developing Lean Leaders is crucial, I agree, but I do not think continuous improvement and improvement is a project with a beginning and an end.  It is something very fundamental that must be embedded in the culture, something every single employee is engaged in on a daily basis.  Dr. Norman Bodek, referred to by some as "the godfather of Lean in the United States", gave a rousing keynote in which he pointed out precisely that.  He showed how companies could achieve two improvement ideas developed and implemented every month by all employees, yielding huge cost savings.  Without a doubt he was one of the most entertaining speakers I have seen in a long time.

All in all, it was a really good conference.  The Lean team at BAE in Santa Clara did an outstanding job putting it all together.  I met a lot of interesting and impressive people, made some good contacts, and made great progress on a couple of initiatives I cannot discuss just yet.  Now it is back to the "real world", so to speak.   Better get the laptop packed up and grab some coffee before my flight boards..

Business leaders use employees, contractors, and suppliers to meet current commitments to customers, partners, and shareholders.  When they need to make a significant change in the business, however, they often seek outside help from a consultant.  A consultant is a non-employee who provides advice and assistance to bring about positive change.

In this article we will examine four ways that leaders use consultants and discuss advantages and drawbacks for each.  The four consulting roles are as follows:

1. Consultants as implementers of a client-devised strategy

In this role, clients provide relatively narrow goals and constraints, and the consultant's role is primarily to implement a predetermined strategy.  The client benefits from the consultant's knowledge and expertise, but only to a certain degree.  The consultant is really just a contractor in this instance, and may not be positioned to help clients realize it when their strategy is not the right one.

Seeking outside assistance with strategy execution can certainly be fruitful, but my advice is for leaders to use this approach only when they are 100% certain the change strategy is the right one, and have benefited from working with another consultant who has provided feedback and outside perspective.  If at all possible, leaders should try to make implementers part of the initial strategy formation.

2. The consultant as an analyst and provider of an "expert opinion"

As providers of an "expert opinion", consultants are (at least initially) limited to developing a report with findings and recommendations.  The recommendations often amount to a change strategy for the client to implement. Unfortunately, such a report is often developed without active client participation. Leaders and staff members are relatively passive participants and merely provide input; they are not part of performing the analysis or developing the recommendations.

It is not uncommon for the consulting firm to view the report as an opportunity to generate more business, hoping to be engaged to implement the recommendations.  They may even structure fees accordingly, and develop the report at a loss.   Clients are aware of this, and stakeholders on the client side may view the report with a certain amount of cynicism.  Also, because the client has not participated in the development of the report on an equal level, there is little accountability for implementation practicality.

Getting an expert opinion can be legitimate when leaders themselves feel that they do not have sufficient understanding of the problem area, or want to develop additional strategies and options in order to make better decisions.  The expert opinion should not be used to develop a single scenario, however.  It should provide leaders with an improved understanding of a problem or opportunity, a set of options for what to do and how, and pros and cons for those options.

Quantification is a must for problem/opportunity analysis, options, and trade-offs.  An expert opinion can enhance a decision-making process, but it does not relieve leaders of responsibility for carefully weighing options before choosing, and afterwards, being able to explain and justify how they came to a decision.

3. The consultant as a substitute leader

Consultants like to be regarded as "trusted advisors", and love it when leaders give them lots of latitude to "make changes happen".  Unfortunately, leaders sometimes rely too much on the consultant.  They become passive, and sink into the background.   This is especially common when potentially unpopular changes need to be made, or when a leader is not positioned to communicate with subordinates in a trusted manner.  The following YouTube clip from "Charlie's Angels" demonstrates this in a tongue-in-cheek fashion:

In this scenario, client executives are nowhere to be found.  They have empowered the consultant and the staff to generate and implement ideas, but they themselves are not involved in the process.  The result is often that when the consultant is gone, the leaders (or middle management) will at some point feel compelled to reassert their influence and reverse or veto some (or all) of the changes.  The staff will soon lose their temporary illusion of empowerment, and leaders will go back to complaining about how people seem passive and how they don't take initiative.

I recall reading about a gruff Lean sensei (coach) ordering client managers and staff around and making abrupt changes, which were poorly understood and implemented with a certain degree of resentment.  It made me think of clichés from martial arts B-movies, until I realized that even I have been guilty of this in the past (see below).  It is so tempting to let the consultants take the wheel, because they are obviously better drivers, right?   The problem is that this does not transfer knowledge, skill, and courage to your people.

4. The consultant as a trusted collaborator and guide

The healthiest way to use a consultant, I believe, is for leaders to work with him or her as a trusted collaborator and guide.  In such a relationship, the leader wants outside perspective and ideas to help bring about positive change.  He or she is prepared to learn and grow in the process, and views change as something that starts with the leadership, not just something that affects employees.

Consultants should bring perspective, wisdom, knowledge, skills, and a proven framework for diagnosis and bringing about change.  The actual implementation of change strategies, however, is best done by client executives and staff themselves.  This ensures buy-in and crucial input on what will and will not work in practice.    Consultants should seek to transfer knowledge and skills related to situational diagnosis, problem solving, and relevant remedies to the client.  Additional involvement should focus on coaching, helping the client's organization implement and adopt the changes.

Credibility and accountability

Leaders and consultants gain and lose credibility with each other as a result of their actions.  An implementer usually has less credibility with the client than an expert advisor, while the trusted collaborator and guide enjoys the highest degree of credibility.

Credibility is more easily lost than gained, but sometimes consultants voluntarily allow themselves to be demoted. In one scenario I learned about recently, a very capable IT consulting firm came in as a "hired gun" to provide an expert opinion on software development practices to a Fortune 1000  company.  They soon found themselves becoming deeply involved with implementation and running a large software project, but somehow they and the client no longer saw eye to eye with respect to how the project should be run.  Unfortunately, it was no longer possible to get the client to listen to ideas on how the project could be managed better.  The consulting firm was stuck in an implementer role, and the project was behind schedule and desperately needed to be rethought.

In another scenario from some years ago, I recall one client with whom I thought I had a trusted collaborator relationship beginning to view me as the outside expert instead.  The shift was gradual and subtle.  Big changes in the client's business environment were beginning affecting the organizational changes we were working on.  However, no one had stepped back to acknowledge this.  The client's leadership and middle management found themselves swamped with new challenges.  While seemingly committed to the engagement's original goals, they were in fact emotionally withdrawing from their responsibilities in the engagement. 

I gradually found myself being too forgiving of their failure to acknowledge that the basic assumptions behind the engagement needed revisiting.  Irritated, I begun to act more like a substitute leader, pressuring middle managers and executives to stick to our agreed-upon deadlines, show up for key meetings, and ensure that their people were signing up for the right courses.  I eventually ceased working with this client, having concluded that they would not be able to realize business value from our work together.  In this scenario, both sides lost perspective, but the consultant failed to hold the client accountable for being an equal partner in the change process.

Conclusion

Establishing and maintaining the mutual trust and credibility required for a trusted collaborator role requires real work for both the client and the consultant.   Consultants and client executives should meet on a regular basis to review the engagement, the premises behind it, and discuss all the surrounding business issues.  These meetings must be more than status reviews; they must be in-depth conversations in which the consultant contributes as a coach and provides fresh perspectives.

I am a strong believer in client executives themselves having skin in the game, committing to read articles and books, and participating in key activities in the change process.  Lasting performance improvement requires leadership direction, understanding, and participation.  A crucial role for consultants should be to help leaders change and grow themselves. Only with such change will leaders succeed with a change process, secure staff participation and ownership, and strengthen their own credibility as leaders.

Finally, not every consultant out there is capable of working as a collaborator and guide.  Leaders need to ensure that a consultant really can act in that capacity.  Before engaging, ask to speak with one or two recent clients about what the consultant is like as a guide and as a collaborator.  Business outcomes are necessary, but not sufficient.  Ask instead what they, personally, learned from working with the consultant, and how that has affected their work.  If they don’t have much to say, chances are the consultant was viewed not as a guide, but as an implementer or provider of an expert opinion.  If organizational change did take place, but the leader you are speaking to was not involved much, chances are there was little collaboration.

We must look beyond software development to the application of Lean to the entire software ecosystem.

As exciting as the development of Lean Thinking in the realm of software development has been, I fear many people are not seeing the bigger picture.   What is afoot here is not just an improvement in the way we build software.  It is much, much more.  A whole industry has the potential to be transformed by these ideas.  More than an industry, in fact: the whole software ecosystem.

The software industry is now global both in terms of product development and its customer base.  It is increasingly adopting a just-in-time delivery and payment model - Software as a Service (SaaS).  Agile methods have helped facilitate this, and Lean is reasonably seen as the next step, though few realize that Lean is perhaps just as radical a departure from Agile as Agile was from waterfall.  

But let us look beyond software development.  If we look at the software industry as it now stands, much is lacking from a Lean perspective:

Organizations remain siloed, with wasteful walls between marketing, sales, support, and development. Hiring and staff development is haphazard. Product management, customer support, and sales remain largely untouched by Lean. 

Financial resource allocation is still done in big batches.  Financial processes may be better documented (and certainly much more costly and complex) as a result of SOX, but they are not Lean.  Push-based estimation and planning are still mainstream.

Short-term thinking prevails  over strategy.  Executives do not appear preoccupied with continuous improvement and organizational learning, focusing instead on short-term revenue. Investors have yet to discover what a difference Lean will make in financial performance; they remain largely unaware of Lean.

Software is a high-clockspeed industry, with tremendous pressure for young companies to perform in the short term, and then move towards an exit strategy.   There are few companies working towards a long-term vision.  Larger software companies remain focused on quarterly results.

IT organizations in mid-sized and large companies develop tremendous amounts of software as well, and are certainly part of the broader software ecosystem.  Unfortunately, they remain burdened by a bureaucratic mindset where people are punished for being wrong instead of rewarded for learning.   Innovation and creativity are not viewed as core values in most of these organizations.

Aerospace and Defense Companies, the Health Care Industry, and the Financial Services Industry, which also develop and depend on software as part of their products, suffer the same problems.  This is partially due to Government Regulation, but they also labor under a command-and-control managment culture. 

So before we get too excited about how the Agile Movement is beginning to discover Lean Thinking, let  us take a hard look at the big picture.  There is so much more that needs to be addressed.   It is not developers and other staff members who are most in need of education about Lean - they take to Lean because it feels like a more natural and less obstructed way of working.  The people who really need to discover Lean are the folks on executive row and in the boardroom.  At least that seems to be the case in the software industry.

In the seminar we held recently here in San Diego, a Chief Technology Officer of a mid-sized ($100M+) company made a salient comment.  She remarked that as the day progressed, the scope of the people she thought she needed to have involved in her company's Lean Transformation grew from a handful of key managers to dozens of people, including her entire management team.  Applying Lean to Software Development, or even Product Development, is not enough.  All business functions are ultimately related to all others, in spite of seemingly heroic efforts to manage businesses as largely disconnected silos.  "I want to get the whole company on board with this," she said.

A different kind of flow

In Womack and Jones' classic, "Lean Thinking", the concept of flow denotes a state of unobstructed progression through a value stream, unhampered by waiting or wasteful steps.  This only occurs during a small fraction of a product's lead time, of course.  But as we synchronize operations, reduce inventory, and remove wasteful steps, we get more flow.  And more flow means lower costs and faster delivery to the customer.

I always found it interesting that Womack and Jones used psychological flow as an analogy to introduce the concept of flow in a value stream.  Mihaly Csikszentmihalyi (pronounced "chick-sent-me-high-ee") described psychological flow in his 1990 book "Flow: The Psychology of Optimal Experience."   The book provided a scientific study of a phenomenon we have all experienced, when we effortlessly focus on a task for a long time, allowing ourselves to be completely absorbed. We often refer to a flow experience as "being in the zone" or "in the groove". 

Flow is a relaxed, joyful, and hyper-productive state.  When we experience flow, we can get tremendous amounts of work done without any sense of effort, and it is usually very good work.  Superstar athletes and great artists are always pursuing flow experiences.  Just watch Tiger Woods play golf, or attend a recital by a world-class concert pianist.

Knowledge workers also pursue flow experiences.  As a young man I wrote the code for the core of an Object-Oriented Database System during a forty-hour session where I hardly slept at all.  So much for work-life balance, but flow experiences are just that wonderful.  They really help bring meaning to work, making worthwhile the tasks that are not as fun.

Getting Things Done (or: Getting Flow Back)

As my career evolved and my work life became more complex, flow experiences became less frequent.  The work I loved doing (writing, abstract thinking, teaching, mentoring, reading, reflecting) was constantly "chopped up" and interrupted by the day-to-day turbulence of building a small company (I'm on my third now).  There were too many hats to wear, too much work to be done, and never enough time to just sit down and think. Sound familiar?

I always wished there was a way to find flow experiences more frequently and more reliably.   Willpower, when exercised, helps.  Meditation and martial arts help too, I'm told, because they strengthen our ability to focus.  But I always thought something more proactive was needed, something that would help us identify and remove obstacles to psychological flow.

The good news is that such a tool exists.  Over the past two years, I and several of my friends and colleagues have been benefiting from GTD, David Allen's system for maximizing personal productivity.  As we shall see, GTD has very interesting similarities with Lean and I will detail some of them here.

Allen’s book, “Getting Things Done: The Art of Stress-Free Productivity”, is now a New York Times bestseller.  Fast Company Magazine called David Allen “one of the world’s most influential thinkers on productivity”, and Jeff Irby at Bearing Point referred to him as “The Henry Ford for the Digital Age”.  Business 2.0 Magazine placed David Allen on its 2006 list of the fifty most influential people changing the world of business today.  So what is behind all this excitement?

GTD is not a time management system as much as a set of practices for focus management.   It helps people achieve short-term and long-term goals while effectively coping with day-to-day surprises, opportunities, and setbacks.  GTD amounts to a very effective methodology for resilient goal-directed action.  And, it yields immediate practical results.

GTD: Designed for your brain

David Allen’s work is based on his observations of the strengths and weaknesses of the human mind.  In-process inventory is not just found in business processes.  Perhaps the most wasteful inventory is found in our own heads.  The set of unacknowledged or unfulfilled commitments to ourselves or others; everything from our life goals to our grocery list - it's all inventory.  Unless we have our mental inventory under control, each of these commitments  continue tugging at us, draining our energy, and distracting us from what we are trying to focus on. The bigger that pile of commitments is, the more overwhelmed and less in control we feel.

Another observation Allen makes is about the limits of human memory.  Short-term memory is good for generating ideas, solving problems, and making decisions.  Keeping appointments and to-do lists in memory is rather more difficult.   Human memory is also fairly limited in terms of the amount of context that can be considered at any given time.  All this implies that we should not be trying to do too many things at once, and that we should divide work up into small, manageable chunks. 

Allen stresses the necessity of setting aside time for defining work, so that when we have a task to do, we don't have to second-guess ourselves and revert to project planning or goal-setting.  By collecting and processing our own mental inventory, we reduce the stress and anxiety generated from unacknowledged commitments.

How GTD works

When we process our mental inventory (as well as incoming email and items in our physical inbasket) it has to go somewhere.  GTD helps us develop a trusted information system to reliably store different types of information (projects, actions, checklists, documents, , etc.)   This system is usually implemented as a combination of a physical filing system (for documents and statements that need to be stored in paper form), an electronic filing system as a hierarchy of folders on our computer, and a specially configured calendar/task manager.  I myself use Outlook with a special GTD plug-in.  My rolodex, calendar, and task lists are synched with my mobile phone, a Palm Treo. 

Most people can only focus on a single action from a few minutes up to a couple of hours.   Anything that requires more than one action step is deemed a project in GTD, and each project should have a well-defined next action that allows progress to be made.  Aside from projects, GTD also identifies higher-level horizons of focus, such as areas of responsibility, yearly goals, five-year vision, and purpose & principles.  These are usually represented as mind maps.

Weekly and daily reviews help GTD practitioners define their work in terms of projects with well-defined outcomes and ready-to-execute next actions.  Higher-level horizons are revisited less frequently or on an as-needed basis.

Instead of a single overwhelming to-do list, next actions are classified by contexts, such as calls to make, emails to write, things to do on the computer, errands to run, things to do at home, etc.   Actions must be doable - they cannot be projects in themselves, and they must be small enough to be performed within minutes rather than hours.  (My only exception to this is writing, which I usually do by allocating several hours on my calendar.)  A special "waiting for" list allows us to register that we are awaiting a response or a deliverable from someone. 

Life in the GTD lane

By ensuring that action lists stay relatively short, our personal productivity is enhanced tremendously.  This is analogous to what inventory reduction does for value stream performance in businesses. We can prioritize our work on the fly and rapidly refocus on different contexts and projects.  For example, if I find myself arriving early for an appointment, I can look at my calls list on my handheld and make a couple of calls.  That is the advantage of well-defined work -- when we are in "doing mode" the work we did in "defining mode" pays off in spades.  We always have doable and relevant next actions lined up.

This sense of “being on top of things” and being able to fully focus without interrupting ourselves is what Allen refers to as "mind like water".  Just like a body of water reacts to a pebble hitting it and then regains its smooth surface, an advanced GTD practitioner is able to perform previously defined work as a rapid-fire sequence of next actions while smoothly adjusting to big and small surprises as they emerge.  Sounds a bit like the Pull concept in Lean, doesn't it?

Conclusion

Just like Lean helps us achieve flow in value streams, GTD helps remove obstacles to psychological flow for individual knowledge workers.   When all of our unresolved committments have been processed, defined, and placed in a trusted system, there is much less distraction caused by our own subconscious.  GTD also lets us deal robustly with external interrupts.   We are taught to negotiate uninterrupted time, handle interrupts on the spot and resume where we left off, or simply agree to handle the matter at a better time. 

There is a lot more to GTD than I have been able to convey in this brief posting, but I hope I have convinced you that it is worth further investigation.  I would go so far as to say that familiarity with GTD should be mandatory for any serious Lean practitioner.

Here are some online information resources for those who want to learn more:

• David Allen Company web site – www.davidco.co
• GTD|Connect online community – www.gtdconnect.com
• GTD plug-in for MS Outlook: http://www.davidco.com/store/other.php
• Other useful products: http://www.davidco.com/store/catalog/
• Office Zealot blog: http://www.officezealot.com/gtd/
• 43 Folders Blog: http://www.43folders.com
• Other Blogs – mentions of David Allen - http://www.technorati.com/tags/david+allen
• Yahoo Groups:
• GTD - http://finance.groups.yahoo.com/group/Getting_Things_Done (4300+ members)
• Ready For Anything: http://finance.groups.yahoo.com/group/Ready4Anything (1300+)

Here are some tools you may find useful in conjunction with implementing GTD:

• Mind Manager from MindJet - a mind mapping tool
• Anagram – automacting extraction of address information in Outlook emails
• Jott - free service: send voice notes to yourself or others by phone;
  automatially converted to text and sent by SMS or email or even to your blog
• ActiveWords - improve productivity with keyboard shotcuts on Windows, reduces time to find files and lauch applications
• Outlook GTD Add-In from NetCentrics
• Vitalist.com - a web-based system for supporting GTD, looks very slick

Last week, PDA pioneer Palm announced that it was canceling its soon-to-be released laptop, the Foleo.  The company will have to take a ten million dollar charge as a result. Product development is an unforgiving business. 

While many were enthusiastic about a companion to the Treo that could be used for email and web browsing, the product was said to be plagued by software problems and deemed not to be ready for prime time.  Palm also faced increasing pressure to complete its next-generation handheld operating system, especially with the launch of Apple’s iPhone, which was astonishing users with its innovative user interface.

So it was decided, according to Palm’s CEO, to refocus the company’s resources on completing its new platform.   From everything I have read in the press it was the right decision, though no doubt it was a very tough decision to make.  But all leaders face these situations from time to time, even in very successful companies.  Tom Peters would tell us that unless we experience a significant failure once in a while, we are not really trying. 

The real issue is, what do we learn from these moments?

Western companies tend to be fairly adept at implementing mechanisms, techniques such as root cause analysis.  But what really matters (and is usually missing) is a certain attitude, one that says that things can and should always be improved.  Japanese culture has the concept of Hansei, deep reflection for the purpose of self-improvement.  Hansei has been part of Toyota’s culture from the very beginning.

In contrast, most high-tech companies I talk to engage in deliberate reflection only when there is a real crisis.  A slight struggle is usually not sufficient to make people step back and question whether they are doing the right things and doing them in the right way.  Instead, people tend to just work a little harder and find workarounds for minor issues.  This is known in American business as “blocking and tackling”.  Leaders are expected to focus on getting things done, and looking back with regrets or doubts can make them look weak. 

When an organization continues in this manner for too long, it can easily go blind to dangerous problems and threats.   Software companies and IT departments often find themselves finding and fixing the same types of problems again and again.  Not a good way to impress customers and shareholders.

Many experts recommend that leaders manufacture the perception of a crisis even when there isn’t one (yet), just to get people to think and stay on their toes.  Leaders at Microsoft and Intel are known to try to maintain a sense of healthy “paranoia”. True to form, Toyota refuses to expend any energy boasting about how it is now passing GM to become the #1 automaker.  It is more concerned with meeting the challenges that its rapid growth brings.

Real or imagined competitive pressures do not make the ONLY good starting points for Hansei, however.  There is a saying in sales that the best time for a salesperson to do prospecting in product development, the most fruitful time for deep reflection in product development is probably when a team has experienced a big win or met a big milestone.   When people are at their most relaxed they also tend to be more mentally agile, energized, and creative.  That is a great moment to challenge your people to think of something even better.

I am a very happy Treo user, so I hope Palm learns its ten million dollar lesson.  That lesson probably goes something like the following: “Why did we not cancel this project much sooner?  We need to get better at listening to customers and responding by aggressively improving our existing product platform even when we are leading the market.”  And hurry.  If the iPhone had a capable task manager and a faster Internet connection I would probably switch.

When companies begin applying Lean practices, there is often much excitement about the initial results.  Dramatic reductions in lead time are not uncommon. But for Lean to have a sustained impact beyond that initial success, what really matters is leadership.

A recent Lean Enterprise Institute survey on the “State of Lean” rated middle management resistance as the biggest obstacle faced by implementers.  Top-level leadership support is critical and not without challenges.  But, let's face it, there are more middle managers than executives, and they are more deeply affected by operational changes. 

Some of these changes can be quite uncomfortable. They involve breaking down boundaries between groups and departments, empowering teams, and increasing the visibility of work, so bottlenecks become much more evident.  Mapping and improving value streams comes into conflcit with a traditional top-down view of leadership.

Leadership is the process of formulating a shared vision and inducing others to implement it.  Because organizations are traditionally structured around specialization of skills and knowledge, most enterprises have significant vertical boundaries between teams, groups, and departments.  Formulation of strategy, resource allocation, and hiring are all is done in a top-down fashion.  So it is perhaps not surprising that leadership is regarded as a top-down activity.

Leadership, however, is primarily about integration – understanding how the pieces fit together.  Now that we have better ideas for how to structure operations, namely with horizontal flow and customer pull, the way we view organizational formats has to change as well.  We need to decouple the process of leadership from the traditional organizational format.

Not only are operations increasingly being viewed as horizontal, but the type of work that most people perform is also evolving.  Even the “doing” now is about learning, especially in organizations implementing Lean.  The more knowledge-intensive a business is the more leadership is about leading groups of learners.  

So what can we offer middle managers as we transition to a Lean Enterprise?  I see three types of leadership roles that will be needed:

I. Vertical leadership, to develop organizational capabilities across value streams

Departments, as we understand them today, will likely look very different in the near future. The knowledge and skill specialization that form the basis for departments will result in more flexible learning communities (a.k.a. Communities of Practice).  Domain experts will lead learning efforts centered on critical fields of knowledge (e.g. negotiation, user interface design, new technologies, Lean, etc.) 

A good candidate for vertical leadership is someone who has deep (and relevant) domain expertise for which he or she is well respected. He or she must also be a great teacher and mentor who genuinely cares about developing people and guiding a collaborative learning process.

II. Horizontal leadership, to deliver products and services

Horizontal leadership is focused on the design, operation and improvement of value streams.  Value stream managers lead teams who collaborate to deliver a product or a service.  They are also held accountable for continuous value stream improvement.

A good candidate for horizontal leadership possesses a broad range of experience, including the ability to lead multiple project teams to meet external commitments.  Another necessity is engaging everyone in continuous participation and learning.  Toyota’s Chief Engineer is a good example of a horizontal leadership role.

III. Strategic leadership, to design and execute top-level strategy

Strategic leadership involves devising, launching and governing organization-wide initiatives to ensure continued growth and prosperity in a changing business environment.  It also serves as an integration point for vertical and horizontal leadership.

A strategic leader must have a clear understanding of outside trends as well as internal operations.  He or she must be able to guide the formulation of longer-term strategies.  This is a collaborative learning process involving cross-functional team members and sometimes even customers and suppliers.

Common to all three roles is that they require that leaders acts as guides and facilitators to stimulate learning and problem-solving.  Middle managers who cannot work this way should probably not have leadership roles unless they receive extensive coaching support. 

Competitive product development is all about listening, learning and executing faster and better than the competition.    This is especially true in the software industry, where product updates must sometimes be provided within hours.

Tomorrow I am giving a talk here in San Diego about Knowledge-Driven Product Development.  I will discuss how product development should be viewed as a Learning Game.  Instead of focusing on activities, we should be looking at knowledge flow and how to remove obstacles to learning.   In order to do this effectively, we should look beyond processes and focus on the product development function as an integrated system - a Product Development System.

A Lean Product Development System is one that facilitates rapid learning with a minimum of waste and bureaucratic obstacles.  Every organization that wishes to remain competitive should have a strategy for pursuing such an ideal, or risk being left behind by smarter, nimbler competitors.

What does a Lean Journey consist of for a Product Development System?  I think there are five basic questions that must be asked and answered - again and again:

• What is the known and potential demand out there?
• How well are we doing now?
• How can we solve the problems that remain in order to meet demand?
• What should our focus be on right now?
• What can we do to answer these questions faster and better?

These questions look suspiciously like the five classic Lean principles, Value, Value Stream, Flow, Pull, and Perfection.  We really need to look at the product development system as a whole, however.  It is more than a portfolio of value streams - it is a system for organizational learning. 

This has significant implications for leadership in product development.  Instead of asking how we can get more efficient, ask about how we can learn faster.  Instead of focusing testing on finding defects, think more broadly about how we can use it as a source of information about how well our design solutions are working.  Instead of asking for elaborate project plans, ask for a tree diagram showing what problems and subproblems need to be solved.

When product development is a Learning Game, the successful leader is more like a coach or a cool professor in graduate school who is facilitating learning. problem-solving, and growth for a team.  Leaders who continue to treat product development as "production work" do so at their professional peril.

They say that immigrants to the United States are often the biggest patriots and in my case that is certainly true.  This year, however, I'm spending Fourth of July at home working hard on a new paper about Product Development Systems.

A Product Development System is the set of resources, assets, and activities used by an organization to develop new products.  In the paper I lay out five distinct aspects of a PDS:

• Information Architecture (how we manage specs, checklists, etc.)
• Value Stream Architecture (processes and inventory queues)
• Organization Architecture (how we structure groups, teams, etc., including locations)
• Product Architecture (relationships between products, subsystems, components)
• Social Architecture (the “soft” interactions that build trust and enhance learning)

As organizations grow, they tend to emphasize the process dimension as they seek improved performance.  Experience suggests, however, that problems and remedies usually relate to two or more of these aspects.  Successful improvement of a PDS, therefore, must diagnose and improve all its aspects, not just processes. 

Hopefully the paper will be done and announced in the e-newsletter in the next few days.  I will update this  posting with a link when it is completed.

The iPhone officially became available in the United States today, at Apple and AT&T company stores.  I stopped by an Apple store in San Diego, to have a look at the crowds and play with the product that has caused so much passion and interest.

 Apple store employees greet customers and manage the lineup

Although initial reviews have been mostly positive, we don't yet know how well the iPhone will sell.  But one thing struck me about the launch: it was exciting.  The store employees seemed genuinely enthusiastic about it.  The visitors to the store could not get enough of holding the iPhone, playing with it, looking at it, touching it.  The employees around the store entrance clapped and hollered whenever a customer exited the store, especially if they had bought an iPhone.

When we start a new product development effort, formulating requirements is not enough.  We need to formulate a compelling vision of what success will look like and feel like for all the stakeholders, for employees as well as customers. 

Productivity expert David Allen uses the term "statement of wild success", and suggests building mind maps to capture different aspects of a vision.  Another idea I learned about from David Allen is to write an imaginary newspaper article or product review.  Indeed, prior to beginning work on his first book, Allen wrote an imagined book review.  The more ambitious the undertaking is, the more compelling the vision of success must be for the participants.

The Apple store employees I encountered clearly felt like winners.  I bet the engineers who worked on the iPhone feel that way too.  How do your people feel?  If they are lack passion for the project or if they are working hard and feel stuck, perhaps you need to ask the most basic of questions:

"Is this what success look like, and if not, what are we going to do about it?"

It is always interesting to watch of signs that more IT executives are becoming more aware of Lean and what it might do to improve their world.  McKinsey recently published a whitepaper endorsing Lean and encouraging CIOs to explore it.  They even cited case studies with encouraging results.

But how much impact will such an endorsement really have?

A few days after the paper was published, I had a meeting with the CIO of a billion-dollar public company. The very morning of our meeting, someone had sent him the paper, and he had already printed it out and skimmed it. McKinsey is a powerful brand indeed.

Over the next two or three years I think we will see an increasing number of Lean related articles published in the mainstream IT press. Where IT executives used to ask “What is Lean?” or “How does Lean apply to IT?” they will now themselves be asked “Are you doing Lean yet and what results are you getting?”

To download a copy of McKinsey's article, go here .

I recently had an interesting conversation with a client after we had facilitated what everyone thought was a very successful value stream mapping workshop.  It was an important value stream, and the team had reduced customer response time by 72%.  Nevertheless, something was bothering me.

"Why," I thought out loud, "do we end up with so much wasteful complexity in the first place?"

The client seized upon this and pointed out that there was no cultural force in his organization to push back on complexity. Simplicity was just not a virtue in in an organization as large as his.  Quite the opposite.  Everyone had lots of ideas, and they all wanted to contribute to products and processes by adding more.

Even with the press attention that the Toyota story has enjoyed in recent months, most executives are still uncertain about what "Lean" really refers to.   Here are some misconceptions I find myself encountering on a frequent basis:

1. Lean is not the same as resource starvation

I often hear the phrase "we are running a lean organization."  Lean does not refer to a lack of resources. When there is a lack of resources, it is often an indication of the opposite, waste!  Either that, or the company isn't successfully and profitably delivering value to its customers, causing revenues to shrink. The only exception to this would be an early-stage company that is still developing its initial products, but even here there is often plenty of waste.

2. Lean is not "mean"

We often hear the phrase "lean and mean". But Lean isn't about "getting tough" with employees.  It is about working together to identify and eliminate useless work, and create more customer value faster.  This won't succeed with a draconian attitude towards employees.  A profound respect for people forms part of the cultural foundation for a Lean transformation in a company.

3. Lean is not a substitute for a good strategy

Lean is primarily about execution.  A Lean initiative mobilizes people to work smarter, innovate faster, remove waste, and create more customer and shareholder value.  This does not take place in a vaccuum, however.  Your strategy defines what markets you are in, who your customers are, and what you need to accomplish in order to win.  Lean will make you a better athlete, if you will, but it won't tell you what sport you are playing.  That is what strategy is for, and Lean is no substitute for strategy. It can be part of your strategy, however, to ensure that you execute better than your competitors.

4. Lean is not a substitute for good leadership

Leadership is the process of inducing others to pursue a common vision [1].  Any new initiative or project depends on good leadership to succeed. So does day-to-day management of the business. Without good leadership, there will be no clarity in direction, no motivation for people to go there, or both.  Lean is about organizational improvement and change.  It too depends on a clear vision of what to work towards.  It also requires us to motivate people to think about the business differently and work to continuously improve it.  Leadership coaching and development will often be a key part of a Lean initiative.

5. Lean is not a substitute for hiring and developing good talent

It is true that Lean helps unleash creativity and allows people to discover better ways of working.  All else being equal, however, the organization with the best people will still win.  When I talk about the "pursuit of perfection", I always discuss three aspects: People, Processes, and Products. The three of these should be integrated: Hire great people, help them grow, use Lean to unleash them to innovate and develop truly great products and processes, and reward them for results.  Far too often I see companies ignore the talent side. A good indication of this is a weak HR function that is primarily concerned with regulatory compliance and reducing the risk of lawsuits.

6. Lean is about enabling profitable growth, not just waste reduction

The Lean literature focuses a lot on waste reduction.  This may be exciting to management in mature companies with modest aspirations for growth, but in general I think it is not the best way to make executives interested in Lean.   Growth is a better story.  There is almost always tremendous potential for creating new products and coming up with more ways to deliver customer value.  Unfortunately, precious resources needed to pursue such opportunities are wasted on non-value-added work.  Lean is really about improving the organization's capacity for innovation and growth.

What Lean is

So how should we define Lean?   Lean is a comprehensive business methodology with a set of practices to help people rapidly and continuously innovate to deliver more customer value faster and at a lower cost. 

Lean is comprehensive, because it applies to all industries and all portions of a business, including those with internal customers (like hiring and payroll).  It can even be used to improve the performance of an entire supply chain.  Lean is a methodology that contains specific, practical methods that can deliver exciting results very quickly.  It helps people across organizations, departments, groups, and teams work together to find end-to-end solutions.

Lean helps people focus on what really matters to the customer.  Because customer needs change and because there is always something that can be improved, an organization's Lean journey is a never-ending one.

References:

1. I attribute this definition of leadership to Dr. Edwin Locke, Dean's Professor Emeritus of Leadership and Motivation at the University of Maryland.  URL: http://www.edwinlocke.com

As we begin 2007, it is interesting to note that Lean seems to be increasingly in the mainstream media.  Here are two recent examples:

(1) A mention in today's Dilbert strip (January 19, 2007).   Launching a new initiative requires a good deal of leadership credibility, and in most organizations employees and managers are understandably skeptical of "yet another" initiative.   The relevant Dilbert strip can be found at www.dilbert.com and if you are reading this past today, you can try this archive URL at http://www.dilbert.com/comics/dilbert/archive/dilbert-20070119.html

(2) This NBC story from earlier in the week (January 15,  2007) cites the culture at Toyota as their real secret (surprise!).   NBC's Ron Mott visits a Toyota plant in Georgetown, KY, and reports on why the company is so successful in getting people to work smarter.   http://www.msnbc.msn.com/id/16639567/

Then again, a major insurance company I am using needed more than a month to update one of my policies because they, and I quote, "were so busy over the holidays".

Dilbert, indeed.

I believe there are three aspects of an organization's Lean Journey:

Business Philosophy: Involve everyone in continuous improvement and innovation; have a deep respect for people and their knowledge. 

Operating Framework: Common metrics and concepts across the entire business.  New way of looking at operations: horizontal portfolio of value streams. 

Breakthrough Tools: Quickly understand how a value stream really works and dramatically improve its performance.

Initial tactical success through training, coaching, and implementation will not be sustainable without paying attention to infrastructure. 

Initial steps on the infrastructure level include identification of value streams, setting improvement goals for these, appointing value stream managers, scheduling Lean-related activities, and tracking results. 

Infrastructure-level work will in turn not be sustainable without hands-on leadership involvement, which will gradually help transform the culture.

The Lean Journey is not a straight line. I envision it more as an ascending spiral, as we develop more experience and sophisitication with Lean as a philosophy, Lean as an operating framework, and Lean as a set of tools to improve the organization's performance.