Rationalize Relentlessly ... or not.

Core to General Electric's strategy is the concept of being #1 or #2 in any business. If they aren't at the top or don't think they can be at the top, they prune the business. A more simple and straightforward strategy doesn't exist. It has also proven to be incredible effective. But the question becomes: can other organizations use this approach? Can they translate such relentless rationalization into a workable strategy?

Last week I was thrilled to be part of our institution's academic strategy planning session.  As I listened carefully throughout the day I wondered if a GE-like strategy could work.  After all, we are facing a constricting economic forecast. If you applied traditional market-driven logic, then a strategy of competitively focused changes could benefit the institution.

However, all strategies are about making choices and accepting the positive and negative consequences of those decisions. A competitive business strategy would certainly improve our future prospects in terms of market share development. Focusing on the academic programs that attract the most students would create growth. But we are a university. Pure grow comes at high cost in terms of our other commitments such as breadth of education and community support.

So is there value to be extracted from the GE strategy?  Can we apply lessons from corporate models to other types of organizations like universities or hospitals or governments?  Or is just not worth it - do we simply accept the fact that strategies cannot translate across different worlds.  I suggest we can learn, but we have to look at it from two different views.

One view is that maybe our currently strategy is actually wrong. Maybe the corporate strategy would make sense. Maybe we do have to rationalize programs to create better focus. Perhaps we should consider only offering degrees in programs where we are the #1 or #2 ranked school. To compete with privatization forces that have made University of Phoenix a success, we may be forced to consider this strategy in the long term.

Alternatively, maybe a literal translation isn't the lesson we should glean from GE.  If we look deeper into why the GE strategy was a success, we might find the intent of the strategy to be more important than the specific strategy statement.  For example, being #1 or #2 was a game changer for GE when it was first announced.  Subsequently it changed the way they managed their portfolio of business on a sustainable basis for decades.

For us, the real lesson might be the concept of treating our organization as a portfolio. To learn from GE we could consider thinking about our academic programs as a portfolio of educational offerings to students. The portfolio transcends the individual courses and becomes an integrated learning experience. With an integrated portfolio, courses from across disciplines can be offered in a seamless manner to help students learn in more innovative ways and to help researchers create in more innovative ways.

Maybe the key lesson is not to necessarily rationalize relentlessly, but to think differently about your product or program offerings. Visualize your organization as a portfolio of related initiatives, not splendidly isolated silos.  

~

Long Live the Crowd

We seem to idolize solo heroes. We feel they are even more special if they act like a cowboy (i.e. Bruce Willis in Die Hard) or if they have a rebellious streak (i.e. James Dean). The solo hero makes a great story and an exciting movie. Somehow this attitude seems to creep into management thinking and the popular press doesn't help the problem. Bill Gates and Steve Jobs both receive the celebrity manager treatment.

They're both talented guys and clearly a force unto themselves. But if we scrape just below the surface, their success was never a solo effort. Initial wins for both were based on partnerships. Mr. Jobs with Steve Wozniak, Mr. Gates with Paul Allen. Even in pop music, the longest and most enduringly successful franchise is Jagger/Richards.

I teach an executive education course a few times each year. When I talk about emphasizing teamwork, the one statement that draws the most agreement in every session is "help the crowd stand out, rather than stand out in a crowd." In other words, good managers build teams and partnerships; they don't focus on their personal profile. They develop relationships, nurture partnerships, and feed friendships. They build a network of mutually supportive links that acts like a crowd moving cohesively in one direction.

Despite what we read, we should not confuse popularity with effectiveness. Managers exist to convert resources into goals. They don't exist to draw publicity to themselves. Getting things done extremely well is not meant to draw attention.

Nevertheless, celebrity managers exist because we need simple ways for the popular press to explain extraordinarily successful organizations like Apple and Microsoft. It's much easier to say Microsoft was a success just because of Bill than it is to explain the intricate web of complexity drawn by market conditions, personal circumstances, and technology innovation that helped to fertilize and grow Microsoft.

All I urge is a sense of caution the next time you read about a superstar leader. Don't try to emulate a simplified notional sketch of a successful manager. Dig deeper. Understand all the reasons for success. I'm pretty sure it was not because the manager was a rebel cowboy.

The solo management genius is a myth. Long live the crowd.

~

99%

Sometimes you see a status report where the author claims a project is 99% complete.  Usually the author is trying to convey the impression that everything is almost done, just about finished, the end is in sight, and it's all over but the cheering.  But very seldom is the truth so rosy.

What usually happens next is that the subsequent status report also says 99% complete.  As a manager you might raise an eyebrow.  But since the project is so close to the end you don't ask any questions.  You let it slide and the author feels like she/he dodged a bullet.  Then the next report is still at 99% done.  You start to feel uncomfortable, but you might be afraid to address the issue.

Now you and the author are both turning a blind eye to the problem.   In reality, if the manager doesn't react early, the manager is becoming complicit with the author in a conspiracy to hide an incomplete job.

One of the reasons the 99% problem is so seductive and can't be solved easily is because no one wants to address the issue.  Managerial avoidance behavior is reinforced by the fact that no one feels compelled to do anything about it.  After all, the project is almost done, so the team must have done a good job.  Right?  Wrong.

99% is one of the biggest and most seductive lies in management.  Who can get in trouble if something is so close?  But without diving into the reasons for the missing 1%, you don't really know if the project is actually done.  The last 1% may represent the most difficult, or most unpleasant, or most complicated part of the project.  Or, it could be the one part that the project manager doesn't want to address.

The next time you see a status report with a 99% complete status, all the alarm bells need to ring.  As a manager, you need to start asking questions right away.  Don't wait for the problem to slip through the cracks and don't assume that the reported 99% complete represents 99% of the work and time and cost.  The last 1% may hide a nasty roadblock that can't be solved easily.

Now that I've written this post I'm going to keep an eye out for 98% complete status reports.

~

A Tale of Two Terminals

By any measure, Terminal 3 at Beijing Capital Airport is impressive. Built in less than four years and officially opened barely four months before the Olympics, the massive terminal has received numerous awards for both its stunning design and its comfortable atmosphere. And it escaped the start-up affliction of many new airport terminals when it commenced full operations on March 26, 2008 without any notable problems.

The next day, half way around the world, Heathrow Terminal 5 opened for business. At one-third the size of Beijing Terminal 3, the new London terminal had taken twice as long to build and cost twice as much. Proud executives at British Airlines and BAA (British Airports Authority) exuded confidence in a flawless opening, but that was not to be. Instead, hundreds of flights were canceled in the first few days of operation, and about 28,000 bags went missing the first weekend. The chaotic opening of Heathrow Terminal 5 was such an embarrassment that it triggered a government investigation.

The smooth opening of Beijing Terminal 3 was not an anomaly – Terminal 2 at Shanghai Pudong International Airport opened the same day, also without newsworthy incident. Given the timing just before the Beijing Olympic games, it was clear that China was keenly interested in projecting an image of competence to the traveling public. But of course, the UK was equally interested in showcasing its proficiency, and the British executives clearly expected that the opening of Heathrow Terminal 5 would go smoothly. So the question to ponder is this: How did the Chinese airports manage two uneventful terminal openings? Did they do something different, or were the problems in London just bad luck?

It’s not like testing was overlooked at Heathrow Terminal 5. In fact, a simulation of the terminal’s systems was developed and all of the technical systems were tested exhaustively, even before they were built. A special testing committee was formed and thousands of people were recruited to be mock passengers, culminating in a test with 2000 volunteer passengers a few weeks before the terminal opened. On the other hand, the planned testing regime was curtailed because the terminal construction was not completed as early as planned; in fact, hard-hats were required in the baggage handling area until shortly before opening day. In addition, a decision was made to move 70% of the flights targeted for Terminal 5 on the very first day of operations, because it was difficult to imagine how to move in smaller increments.[1]

Those of us in the software industry have heard this story before: the time runs out for system testing, but a big-bang cut-over to a mission critical new system proceeds anyway, because the planned date just can’t be delayed. The result is predictable: wishful thinking gives way to various degrees of disaster.

That kind of disaster wasn’t going to happen in Beijing. I was in Beijing a month before the Olympics, and every single person I met – from tour guide to restaurant worker – seemed to feel personally responsible for projecting a favorable image as the eyes of the world focused on their city. I imagine that for every worker in Terminal 3, a smooth startup was a matter of national pride. But the terminal didn’t open smoothly just because everyone wanted things to go well. It opened smoothly because the airport authorities understood how to orchestrate such a large, complex undertaking that involved hundreds of people. After all, they had just finished building the airport at amazing speed.[2]

The opening ceremony of the Beijing Olympics was also a large, complex undertaking that involved hundreds of people. It’s easy to imagine the many rehearsals that took place to make sure that everyone knew their part. When it comes to opening a new terminal, the idea of rehearsals doesn’t usually occur to the authorities, but at Beijing Capital Airport, rehearsals started in early February. First a couple of thousand mock passengers took part in a rehearsal, then five thousand, and finally, on February 23rd, 8000 mock passengers checked in luggage for 146 flights. This was the average daily load expected a week later, when six minor airlines moved into Terminal 3. During the month of March, Terminal 3 operated on a trial basis, ironing out any problems that arose. Meanwhile, staff from the large airlines about to move to the terminal rehearsed their jobs in the new terminal day after day, so that when the big moving day arrived, everyone knew what to do. On March 26, all the practice paid off when the Terminal was opened with very few problems.

This certainly wasn’t the approach taken at Heathrow Terminal 5. It’s pretty clear that the opening chaos was caused because people did not know what to do: they didn’t know where to park, couldn’t get through security, didn’t know how to sign on to the new PDA’s to get their work assignments, didn’t know where to get help, and didn’t know how to stop all the luggage from coming at them until their problems got sorted out. Even the worst of the technical problems was actually a people problem: the baggage handling software had been put in a ‘safe’ mode for testing, and apparently no one was responsible for removing the patch which cut off communication to other terminals in the airport. It took three days to realize that this very human error was the main cause of the software problems![3]

In testimony to the British House of Commons, union Shop Steward Iggy Vaid testified:[4]

We raised [worker concerns] with our senior management team especially in British Airways. … [Their response was to] involve what we call process engineers who came in and decided what type of process needed to be installed. They only wanted the union to implement that process and it was decided by somebody else, not the people who really worked it. The fact is that they paid lip service to, ignored or did not implement any suggestion we made.

… as early as January there was a meeting with the senior management team at which we highlighted our concerns about how the baggage system and everything else would fail, that the process introduced would not work and so on. We highlighted all these concerns, but there was no time to change the whole plan.

... [Workers] had two days of familiarization in a van or were shown slides; they were shown where their lockers were and so on, but there was no training for hands-on work.….

The opening of a new airport terminal is an exercise in dealing with complexity. At Heathrow Terminal 5, new technical systems and new work arrangements had to come together virtually overnight – and changing the date once it has been set would have been difficult and expensive. Hundreds of people were involved, and every glitch in the work system had a tendency to cascade into ever larger problems.

If this sounds familiar, it’s because this scenario has been played out several times in the lives of many of us in software development. Over time, we have learned a lot about handling unforgiving, complex systems, particularly systems that include people interacting with new technology. But every time we encounter messy transition like the one at Heathrow Terminal 5, we wonder if our hard-learned lessons for dealing with complexity couldn’t be spread a bit wider.

Socio-technical Systems
Not very far from Heathrow, the Tavistock Institute of London has spent some decades researching work designs that deal effectively with turbulence and complexity. In the 1950’s and 60’s, renowned scientists such as Eric Trist and Fred Emery documented novel working arrangements that were particularly effective in the coal mines and factories of Great Britain. They found that especially effective work systems were designed (and continually improved) by semi-autonomous work teams of between 10 and 100 people that accepted responsibility for meaningful (end-to-end) tasks. The teams used their knowledge of the work and of high-level objectives to design a system to accomplish the job in a manner that optimized the overall results. Moreover, these teams were much better at managing uncertainty and rapidly adapting to various problems as they were encountered. The researchers found that the most effective work design occurs when the social aspects of the work are balanced with its technical aspects, so they called these balanced work systems Socio-technical systems.

In 1981, Eric Trist published “The Evolution of Socio-technical Systems,” an engaging history of his work. He attributes the “old paradigm” of work design to Max Weber (bureaucracy) and Frederick Taylor (work fragmentation). He proposed that a “new paradigm” would be far more effective for organizations in turbulent, competitive, or rapidly changing situations:[5]

Old Paradigm	New Paradigm
The technological imperative	Joint optimization [of social & technical systems]
Man as an extension of the machine	Man as complementary to the machine
Man as an expendable spare part	Man as a resource to be developed
Maximum task breakdown, simple narrow skills	Optimum task grouping, multiple broad skills
External controls (supervisors, specialist staffs, procedures)	Internal controls (self-regulating subsystems)
Tall organization chart, autocratic style	Flat organization chart, participative style
Competition, gamesmanship	Collaboration, collegiality
Organization’s purposes only	Members’ and society’s purposes also
Alienation	Commitment
Low risk taking	Innovation

In the 1980’s the socio-technical paradigm gained increased popularity when team work practices from Japan were widely copied in Europe and America. In the 1990’s socio-technical ideas merged with general systems theory, and the term “socio-technical systems” fell into disuse. But the ideas lived on. These days, it is generally accepted that the most effective way to deal with complex or fast-changing situations is by structuring work around semi-autonomous teams that have the leadership and training to respond effectively to any situation the groups are likely to encounter.

The clearest example we have of semi-autonomous work teams are emergency response teams – firefighters, paramedics, emergency room staff. Their job is to respond to challenging, complex, rapidly changing situations, frequently in dangerous surroundings and often with lives at stake. Emergency response teams prepare for these difficult situations by rehearsing their roles, so everyone knows what to do. During a real emergency, that training coupled with the experience of internal leaders enables the teams to respond dynamically and creatively to the emergency as events unfold.

Design Social Systems Along with Technical Systems
Developing a software system that automates a work system is fraught with just about as much danger as moving to a new airport terminal. There are many things we can do to mitigate that risk:

1. Cutover to any new system should be in small increments. Impossible? Don’t give up on increments too quickly – and don’t leave this to “customers” to decide! The technical risk of a big-bang cut-over is immense. And it’s almost always easier to divide the system in some way to facilitate incremental deployment than it is to deal with the virtually guaranteed chaos of a big-bang cutover.

2. Simplify before you automate. Never automate a work process until the work teams have devised as simple a work process as they possibly can. Automating the right thing is at least as important as automating it right.

3. Do not freeze work design into code! Leave as much work design as possible for work teams to determine and modify. If that is not possible, make sure that the people who will live with the new system are involved in the design of their work.

4. Rehearse! Don’t just test the technical part, include the people who will use the new system in end-to-end rehearsals. Be prepared to adapt the technical system to the social system and to refine the social system as well. Be sure everyone knows what to do; be sure that the new work design makes sense. Leave time to adjust and adapt. Don’t cut this part short.

5. Organize to manage complexity. Structure work around work teams that can adapt to changing situations, especially if the environment is complex, could change rapidly, or is mission critical. At minimum, have emergency response teams on hand when the new system goes live.

Much of the software we write ends up having an impact on the lives of other people; in other words, our work creates changes in social systems. We would do well to consider those social systems as we develop the technical systems. If we want to create systems that are truly successful, the technical and social aspects of our systems must be designed together and kept in balance.
___________________
Footnotes:
[1] “The opening of Heathrow Terminal 5” report to the House of Commons Transportation Committee pages 13-14.

[2] Contrast this with the absence of the BAA management team that oversaw the on-time, on-budget construction of Heathrow Terminal 5; they were replaced after a 2006 takeover of BAA by the Spanish company Ferrovial.

[3] See “The opening of Heathrow Terminal 5” report to the House of Commons Transportation Committee.

[4] “The opening of Heathrow Terminal 5” report to the House of Commons Transportation Committee pages 22-25.

[5] From "The Evolution of Socio-technical Systems" by Eric Trist, 1981. p 42.

The Value of Storytelling

One Saturday afternoon more than a couple of decades years ago I was at work writing software for a difficult project.  The software wasn't difficult, but the user certainly was.  I heard someone walk by and it was the VP of technology for the organization.  I asked him what he was doing there ... and he asked me what I was doing there.  So I told him all my woes about how unreasonable my user was being.  He responded with one simple line "non carborundum illegitimus."

My former VP's advice, roughly translated from Latin, means don't let the b*stards get you down.  Good advice to keep your opinions to yourself and get the job done.  His advice may not have changed the issue one iota, but it helped me to manage my own emotions around the situation.

I had completely forgotten the incident until this evening when one of my staff complained about to me about an unreasonable client. I decided to relate the story of my similar situation from the past.  The story may have been simple, but the message remains consistent and useful over time.

If I had just said "don't behave that way" I'm sure the impact wouldn't have been the same.  But a simple factual story resonates more effectively.  I'm not sure the advice was particularly brilliant, but the parallelism over the decades was strikingly interesting.

The value of storytelling as a management technique is in the power of conveying a simple and effective message without lecturing.  In this particular case, it is reassuring to know that no matter how much the technology changes over the decades the same fundamental issues remain.  Technology is easy, people are complicated.

I still don't know why the VP was in the office on a Saturday afternoon ...

~

Freedom

If I spend more than half my day talking to clients, my day was a success.  Today I'm happy to say that many days seem to fit this criteria for me.  But it didn't used to be this way.  When I first started in my current management role five years ago I was busier than I had ever been in my entire life.  Every day was a struggle to find the appropriate time balance between internal management issues and external client relationships.  Because they were more immediate and urgent, the internal issues usually got the upper hand.

Slowly over time I began to get more personal control and flexibility into my schedule. The reasons for getting time to do what I want to do stem from several sources such as improved processes, better organization, whittling down the project backlog, and so on.  But the single biggest factor in freeing up my time has been building a brilliant management team.  Today I have a series of direct reports I who I can trust to handle the boundless complexity of directly managing the business of a large organization.

Over the period of several years we have built up a world class management team.  With precision, insight, and compassion this team leads the core components of our organization.  Their excellence frees me to deal with the strategic issues of my job and gives me the luxury of spending more time with our clients.  A great management team gives you freedom - freedom to focus on the truly challenging and exciting aspects of your role.

Gosh, I even have time to write a blog!

~

Victims of History

All managers inherit an organizational history.  In any human institution, outside of new start-ups, someone came before you.  That someone designed processes (consciously or not), molded culture, hired staff, and made decisions.  These were not your ideas.  You may not have made similar choices given the original circumstances, nonetheless they are now yours.

Being a victim of history is neither bad nor good.  It is simply is a fact of life.  The trick is whether you want to behave like a victim or not.  Managers who accept what they have inherited as inevitable become victims of history.  Managers who challenge every aspect of the past create the future.  They accept nothing as status quo and make a difference by denying the tyranny of organizational history.

~

And now for something completely different ...

I have a collection of books about management that I've accrued over the years.  From Peter Drucker to Tom Peters to Jim Collins, the shelf covers several decades of management theory and practice.  As I look at the shelf I realize one consistent feature across most of those books.  Each one attempts to create a simple unified theory of management.  Many of the books attempt to boil management into a few guiding principles.  These simple clear principles can then be applied by the reader in a general-purpose manner to solve most management problems.

What is interesting is how convincing each book's ideas can be.  For example, no one can read "In Search of Excellence" without developing a passion for culture.  Consistently across each of these books there are a few key messages containing extraordinarily compelling management advice.  The only problem: although there is some overlap and some consistency, most of the messages are quite different.  Each author has her or his separate message.  So, who is right?  But if one author is right, then someone has to be wrong.

Maybe what is missing is the realization that you cannot boil management down into a few key guiding principles.  Maybe management is so circumstance based that there can be no grand unification theory.  Maybe each instance of applied management requires specific and unique skills.  Maybe the case study method taught in business school is the right way to go - teach managers how to react to unique circumstances rather than attempt to to teach them how to apply management theory.

In management there are no silver bullets.  There is no single theory or idea that solves every management problem.  It may be human nature to look for ways to simplify our lives.  We may cling to the idea that a single brilliant idea will solve all our challenges and issues.  However, with so many brilliant authors providing so many compelling ideas, I suspect they are all right to a certain extent.  Our challenge as practicing managers is to undertand when to apply the material we've learned and when to just throw the book out the window and try something completely different.

Maybe I should throw out that dusty bookshelf.

~