Chapter 3. WHAT RADICAL MANAGEMENT MEANS

 

Equipping organizations to tackle the future would require a management revolution no less momentous than the one that spawned modern industry.

 
 --Gary Hamel[47]

Radical management entails a journey—one that will never end. The journey needs to be conducted not through detached contemplation, but from immersion in the nitty-gritty of work, the kind that sings when clients are delighted and kicks back when they're not. It's about creating a workplace based on agency and responsibility.

It means exploring what's involved in replacing the daily grind with discovery and surprise. It's about becoming more productive by working smarter.

It involves examining what choice-worthy work looks like and understanding what kind of activity enlivens the human spirit. It builds on intuitions that many people have had for a long time but have rarely been pursued to their conclusion in business forums.

Ultimately it's about generating work that involves doing things with people who share a common passion for the activity and for being excellent at it, in service of other people whose ever-increasing delight we can see and experience.

It means implementing seven basic principles of continuous innovation.

SEVEN BASIC PRINCIPLES OF CONTINUOUS INNOVATION

Principle #1: Focus Work on Delighting the Client

Radical management begins by clarifying the goal of work. In the twentieth century, the traditional view of an organization was an entity principally aimed at the production of goods and services or making money for the company. These goals don't get anyone's juices flowing. That's because goods, services, and money are means, not ends.

In today's world of global competition and continuous change, a firm that isn't delighting its clients and turning them into active promoters of its goods and services is unlikely to endure. If the firm is making profits while leaving customers disgruntled, then the profits are "bad profits" and are generating brand liabilities that will have to be repaid one day. The true bottom line of any organization is whether and to what extent it is delighting clients and stakeholders.[48]

A firm that adopts client delight as its goal is also making inroads on improving job satisfaction. Improving the lives of others is something worth believing in and fighting for.

Principle #2: Do Work Through Self-Organizing Teams

Adopting the goal of client delight leads to the self-organizing team. That's because inspiring client delight requires continuous innovation, and a self-organizing team is the management arrangement most likely to generate innovation. Self-organizing teams are well suited to accomplish this complex task; when they are properly executed, they draw on all the talents, energies, and passion of the workforce.

Self-organizing teams also speak to the economics of work: self-organizing teams have the potential to be radically more productive because when they are properly supported, they tend to evolve into high-performance teams.

Principle #3: Do Work in Client-Driven Iterations

Principle #2 leads to working in an iterative fashion, with teams completing work in relatively short time slices aimed at delivering value to clients. In part, this is because delighting clients can be approached only with successive approximations as to what might succeed or fail. Continuous feedback from the clients or their proxy is needed as to whether they are in fact being delighted by the direction in which the work is heading.

In part, it is because delegating work to self-organizing teams is a risky undertaking that requires constant vigilance to ensure that teams are focused on delighting the client and evolving toward high performance. And in part, it is because doing work in short iterations is generally more economical overall than long production runs.[49]

Principle #4: Deliver Value to Clients Each Iteration

Iterative work patterns necessitate a focus on getting things done by the end of each iteration of work.

Rather than issuing progress reports about where the project stands, the teams produce finished work each iteration so that clients or their proxies can touch, feel, use, and experience it and find out whether this is something that delights them.[50] Whereas traditional management focuses principally on reducing costs, radical management focuses principally on reducing time to market and delivering more value to clients sooner. It turns out that being more responsive in terms of time also tends to be more efficient.

The origins of this principle lie partly in lean manufacturing: inventory is a problem because it ties up money and, even more important, tends to delay the discovery and resolution of quality problems. A focus on delivering value to clients each iteration also tends to lower costs.

Similarly, in knowledge work, having a lot of work in process is damaging to productivity. Hence, efficiency also requires that once work is started, it should be completed as soon as possible so that work in progress is kept to a minimum.

Principle #5: Be Totally Open About Impediments to Improvement

Working in an iterative fashion both enables and requires the workplace to be radically transparent so that the team goes on improving. Firms cannot accomplish the complex task of delighting clients or establish genuine responsibility for work if people are telling each other what they want to hear or limiting their communications to what they think listeners need to know.

The openness is multidirectional: the team members with each other, the team with management, and management with the team. This multidimensionality is accomplished not simply by urging people to be more open, but by implementing a set of management practices that systematically catalyzes transparency aimed at removing impediments.

Principle #6: Create a Context for Continuous Self-Improvement by the Team Itself

Once the arrangements promoted by Principles #1 to #5 are in place, the team can accept responsibility for getting work done and enjoy the freedom to proceed without interruption or second-guessing while impediments are being identified and removed. Teams know their velocity and trajectory. In such a setting, they typically want to get better and generally do improve.

This is not about the management imposing a pace of work that undermines quality or pressing for unreasonably long working hours. Rather it creates conditions under which teams enjoy what they are doing and want to become more productive.

Principle #7: Communicate Through Interactive Conversations

Implementing Principles #1 to #6 requires communication that is different from traditional management. Instead of telling people what to do, radical managers have interactive conversations, using authentic narratives, posing open-ended questions, and engaging in deep listening, as well as encouraging horizontal communications to enhance learning. It entails a willingness to see what is really happening in the workplace and to have the open-mindedness to learn. It involves getting things done with people, not doing things to people.

Interactive communication flows from the purpose of work: inspiring workers to find ways to delight clients. To achieve these goals, communication practices need to be people-centric inside and outside the firm.

An Inexorable Sequence

These seven principles form an inexorable, mutually reinforcing sequence. They begin by identifying the goal that is appropriate to the twenty-first century: client delight. This becomes the basis for everything—the guiding light to which all work should aspire.

Focusing on client delight leads inevitably to self-organizing teams, the management arrangement most likely to generate the continuous innovation that delights clients. Doing work through self-organizing teams leads to working in client-driven iterations, because delighting clients can be approached only by successive approximations. And self-organizing teams, being a life form that lives on the edge of chaos, need checkpoints to see whether they are evolving positively or decaying into chaos.

Client-driven iterations require a focus on delivering value to clients each iteration. This forces closure and enables the productivity gains that flow from delivering value to clients sooner rather than later. Self-organizing teams working in client-driven iterations both enable and require radical transparency, so they continue to improve of their own accord and evolve naturally into high-performance teams.

An underlying requirement of all of these steps is interactive communication. Unless managers and workers are dealing with people as people, with respect and dignity, rather than as things to be manipulated, none of the other six principles are likely to work.

AN INTEGRATED SET OF MEASURES

Individually none of these seven principles is new. Each principle has been implemented by some organizations for many years:

  • Finding ways to measure client delight and the consequent impact on firm growth has been systematically studied by Fred Reichheld and his colleagues at the consulting firm Bain & Company for over twenty-five years.[51]

  • Self-organizing teams have been the staple of new product development for several decades.[52]

  • Iterative work practices have been promoted since the 1930s by Walter Shewhart, a quality expert at Bell Labs.[53]

  • Reducing inventory and delivering value to clients each iteration lie at the heart of lean manufacturing, which was invented by Toyota some fifty years ago.[54]

  • Radical transparency has been a guiding principle of software development practices known as Scrum and Agile for several decades.

  • Continuous self-improvement is a legacy from the total quality movement for more than half a century.[55]

  • Interactive communication—storytelling, questions, conversations—has a rapidly growing literature and practice in the past decade.[56]

Individually, then, none of the seven principles is new. What is new is for organizations to break free from the interlocking assumptions of traditional management and put all the principles of radical management together as an integrated, mutually supporting whole. It's the integrated implementation of all the pieces that gives the approach its full power. Each of the components adds an increment: when they are combined, the increment becomes exponential.

When the principles are linked, we can see the sequence and the causal connections. We can see why the principles fit together and reinforce each other. We can see how any one of these seven principles will lead to some benefit. We begin to grasp the extraordinary benefits that accrue by implementing all of the principles together.

The practices work consistently, efficiently, and with minimal risk for a number of reasons. For one thing, they are aligned with the true purpose of work: delighting clients. For another, they pay careful attention to the intrinsic value of and satisfaction inherent in performing excellent work within the limitations of pace arising from the nature of the work itself. And finally, they lead to a radically more productive way of doing work.

THE IDEA IN ACTION: EASEL CORPORATION

Let's look at an example of a firm that explicitly implemented this approach. It occurred in Boston in 1993 at the very moment when traditional management was jumping on the bandwagon of business process reengineering.

In 1993, Jeff Sutherland joined a Boston-based software development firm called the Easel Corporation. Today Sutherland is a vigorous man in his sixties with silver hair and sharp, sparkling eyes. He dresses neatly in a black shirt with a button-down collar, black pants, and sneakers. A devotee of tai chi and Buddhist thinking, he was a fighter pilot in the U.S. Air Force and flew scores of combat missions over North Vietnam, achieving Top Gun status in 1967. He still has the military bearing of a man who has been through many battles, which have given him a keen sense of the ironies of life.

In 1983, Sutherland began working as a systems architect and chief technical officer in a series of companies, trying to figure out what could be done about the software developers whose work was always late, over budget, and plagued by quality problems. Clients were upset, and firms lost money. The developers were seen as culprits and were punished. They worked harder and harder. They labored evenings and weekends. They got divorced. It made no difference. The software was still late, over budget, and full of bugs. They were fired, but their replacements did no better. Something was amiss in this picture, and Sutherland set out to fix it.

By the early 1990s, he was working for a firm that was shipping software to big customers like the Ford Motor Company, which had around a thousand developers using its products. Ford's developers were fairly ordinary performers, and Sutherland wondered: Is there some way I could transform these developers from ordinary to extraordinary?

The conventional wisdom said no. But Sutherland was not the kind of person to accept the conventional wisdom. He knew the value of persistence. When studying at West Point, he had trained as a gymnast on the parallel bars under a man who was also the coach for the Olympic team. Sutherland recalls coming to the gym every afternoon and getting up on the parallel bars. When he did a flip, the coach would say, "That's not quite right. Get up and do it again." For three hours every day for three years, including some weekends, it was never right. And every once in a while, just to show him that it wasn't right, the coach would get up on the parallel bars and do a perfect flip just to rub it in. But at the end of those three years, Sutherland could do the flip better than most of the people that he was competing with. From that experience, he learned about constantly failing and retrying in order to reach for a higher level where he had never been before.

The Surgical Team

The first thing Sutherland did was to review thirty years of IBM's system journals. IBM had done research on the best way to develop software, and its conclusion was the surgical team: a team where one brilliant person had all the architecture, all the designs, in his or her head, and wrote every single line of code. It was like the surgeon in the operating room. The surgeon was the only one who cut the patient. Everyone else passed the scalpel or monitored the vital signs.

That was the level of performance that Sutherland was looking for. But there was a problem: companies like Ford weren't staffed with "surgeons." And even if they had been, the project would fail if the surgeon were run over by a bus, so it was a high-risk way to develop software. It was also inefficient because it didn't draw on the full talents of the team. Moreover, it didn't scale. There was only so much that one mind, even a brilliant mind, could master. In really big projects, with millions of lines of code, it didn't work. The projects were just too big. There had to be another way.

The High-Performance Product Development Team

Sutherland's challenge was how to get surgical performance from a team of fairly ordinary developers. So he began researching the computer science literature and talking to everybody, looking for high-performance teams.

He found that the best-performing teams for handling innovation were self-organizing teams.[57] The model had generally been used to deal with one-time crises. But why wait for the crisis? Why not get this kind of performance on a daily basis?

The elements were clear. The teams would need to see the goal as something that was important, something special, and to see it as a challenge. They would need to have a deadline so that projects didn't go on forever. They would need to have the space—mental and physical—in which they were free to get work done, as opposed to talking about the work or doing rework due to second-guessing. They would need to be cross-functional teams and have the leeway to organize themselves, including the responsibility for figuring out how to do the work. The teams would be small, with no more than eight or nine people—preferably smaller, but still with cross-functionality. And the team would be expected to produce something that was completely done by the deadline.

The role of management was not to manipulate the people doing the work; it was to set direction, eliminate anything that was preventing the team from performing at an extraordinary level, and then get out of the way.

Putting the Pieces Together

By 1993 Sutherland could see how to put the pieces together, and a financial crisis at the Easel Corporation gave him the opportunity to try out his ideas in practice. The traditional way of producing software had just failed miserably, and the firm was on the brink of being put out of business. Unless new software could be developed within six months, it would be history.

Sutherland went to the CEO and asked him how long he had been overseeing software development.

"Twenty-five years."

Sutherland asked him whether, in all that time, the plans that were supported by Gantt charts and looked good on paper had ever led to software being delivered on time.

The CEO said, "Never." Worse, slippage was rarely discovered until it was too late to do anything about it.

Now the situation was desperate, and Sutherland proposed doing something different. Instead of trying to manage the team more tightly, with detailed plans and Gantt charts, Sutherland proposed standing back and asking the team to manage itself.

The CEO was skeptical of putting the future of the firm in the hands of a team when he had never seen a team deliver on time and within budget even once during the previous twenty-five years. Sutherland then pointed out the definition of a fool: someone who keeps doing the same thing and expects a different result. They had to do something different.

So Sutherland got his mandate to set up the team according to the principles he had developed. He created a container in which the team could operate: the team itself was given the responsibility of figuring out how long each piece of work would take and how to do the work.

Within the team, he introduced the communication practices that he had observed in the best self-organizing teams. It was an iterative process with frank daily communication among the team members, with the manager serving as a coach to remove impediments and help the team improve. This radically altered the nature of the work going on within the team. It allowed sharing of information about the state of software components so that development tasks that had been expected to take days could be accomplished in hours using someone else's code as a starting point. By having every member of the team see every day what every other team member was doing, they began to get suggestions: one developer would see that if he changed a few lines of code, he could eliminate days of work for another developer.

A process was put in place for setting priorities on a monthly basis. It could be adjusted as the work evolved, so that the team worked only on issues of the highest priority. During the monthly increment of work, the team was not to be interrupted. The team was under the gun to produce the solution by the six-month deadline, or the firm would fail.

Sutherland also took steps to bring in outside ideas. He held demonstrations, usually on a Friday, and brought in development experts from other companies to look at the evolving product. As a result, the developers had to show their work to their peers. This was a powerful accelerator. The outside experts would say, "That sucks. Look at product X to see how it should be done." Or, "How could you possibly have a dumb bug like that?"

And the next week, everything would be fixed! The developers refused to be embarrassed again in front of their peers. Sutherland also sought feedback from software developers in MIT and companies along Route 128.

At the end of each month, the CEO got his demo. He could use the software himself and see how it was evolving. Sutherland also gave the software to the firm's consulting staff to use in prototyping consulting projects. This generated ideas to incorporate into the list of features that were desirable to have. At the beginning of each month's work, the list of features to be worked on was reprioritized before transformation into development tasks. This allowed the CEO to steer product development.

And in that very first team that Sutherland set up at Easel Corporation in 1993, the team went into a hyperproductive state. This effect was so dramatic that the project accelerated to the point that it began to overwhelm the documentation staff and testing engineers. The team was delivering so much software that management said it was too much. "Slow down!" they cried.

The CEO saw significant step-by-step progress in each monthly increment and agreed the software was ready to ship in the fifth increment, one month ahead of schedule. The firm offered a money-back guarantee that this new software would double developer productivity in the first month of use. It sold well, and the company had won a reprieve.

Although Sutherland's team had saved Easel from bankruptcy, the company didn't go on to become another Microsoft. The market hole into which it had already dug itself was too deep. In the topsy-turvy world of software development, Easel prospered for a while and then was swallowed by another firm. It no longer exists as a separate entity.

Nevertheless, something important had happened. Sutherland had shown that a high-performance team could be deliberately seeded. He had shown that the conventional wisdom was wrong: high-performance teams are not matters of luck or chemistry. Once the teams were set up right, it was possible to generate hyperproductivity.

Sutherland was interested in changing more than just a single team in a single organization. His goal was to change the whole software industry.

In the early 1990s, Ken Schwaber had used an approach similar to what was done at the Easel Corporation at his company, Advanced Development Methods. In 1995, Sutherland and Schwaber jointly presented a paper entitled the "SCRUM Development Process" at a software conference in Austin, Texas, its first public appearance. They collaborated during the following years to merge their writings, their experiences, and industry practices into what is now known in software development as Scrum.[58]

Six years later, in 2001, Sutherland, Schwaber, and fifteen colleagues got together in Snowbird, Colorado, and drafted the Agile Manifesto, which became a clarion call to software developers around the globe to pursue this radically different type of management.[59] Since then, Sutherland, Schwaber, and their colleagues have gone on to generate thousands of high-performance teams in hundreds of companies all around the world under the labels of Scrum and Agile.

Teams using the practices that Sutherland and his colleagues had pioneered have been unexpectedly productive. These were not just improvements where the teams were just slightly better than the norm. The best teams routinely obtain productivity increases of 200 to 400 percent, changes that are potentially industry-disruptive improvements.[60]

WHERE IS IT HAPPENING?

What happened in software development was similar in some ways to what was occurring in lean manufacturing (particularly at Toyota and Honda) and in new product development. Self-organizing teams have also been used for decades as an exception to hierarchical bureaucracy in the form of task forces that have been set up to solve a crisis and then typically disbanded. What is now happening is that this way of managing is now being to used get almost any work done more productively.

A further incentive for management to move in this direction is that the best talent will seek out firms that can provide this kind of a workplace. As managers start to see the benefits in one area, the approach tends to expand to every other aspect of firm activity. As a result, a radical new way of managing work is emerging. It involves a different way of thinking about work, managing work, and participating in work. It isn't a quick fix or an incremental change or shift at the periphery. When fully implemented, it affects everything in the organization. It is radically new management.

In the end, the productivity numbers—two- to four-times gains in productivity—by themselves make the change persuasive. When combined with client delight and deep job satisfaction, the wider adoption of radical management becomes inevitable.

That said, however, radical management isn't a panacea. It isn't applicable, for instance, in these situations:

  • Where the work is best done alone. Most significant activities in the modern organization require collaboration. However, some individuals prefer to work alone, and some work is best done alone, such as writing novels or composing symphonies.

  • Where the work has a small knowledge component. Firms with mainly unskilled labor may decide to organize the work in a traditional fashion as a hierarchical bureaucracy. They may, however, be at risk from competitors who figure out a way to draw on the knowledge and ingenuity of their workers, get on a steadily improving team approach, and provide more value to customers. As some firms have shown, there is really no such thing as unskilled labor: "unskilled labor" simply means that no one has yet taken the time and applied the intelligence to figure out how to do the job at a higher level.[61]

  • Where a public sector organization must be neutral. The dispensation of justice, for instance, is required to be neutral for all parties. In the end, society as a whole may be delighted by the performance when this impartial implementation of justice is achieved. But that is a possible outcome rather than the goal sought after.

HOW WILL IT HAPPEN MORE WIDELY?

For most organizations, radical management is a fundamental change, even a wrenching shift in culture.

How will it happen?

The riskiest way is for top management to try to impose it. This will usually backfire, because that would be a continuation of traditional management practices.[62]

Among the mistakes of business process reengineering was to imagine that a bunch of experts in a back room could dream up a better process, design it in great detail, and then impose it on people doing the work. Not surprisingly, this exercise didn't take into account the realities of the work itself. It wasn't based on interactive communication with people so that they could participate in the cocreation of a new kind of workplace. It led to more of the same.

Radical management is about mobilizing the energies, spirit, and ingenuities of workers and focusing them on delighting clients and to go on doing it time after time in a sustainable way. To accomplish that, managers have to abandon their faith in backroom reengineering and enlist the workers in taking responsibility for cocreating a new, more productive, and more fulfilling future.

It means exploring the possibility that working together with other human beings responds to some permanent requirement of our nature—some ancient and deep-seated need to do things together with people to delight others.[63] It means breathing fresh life into timeless ideas like authenticity, truth, and team, even though these terms have been misused and abused and have fallen into contempt in some quarters. It speaks to both the economics and the ethics of respect. It means exploring what's involved in creating occasions for the kind of spiritedness that is called forth when people take things in hand for themselves.

It is ultimately about what it means to live a good life: working on something we love, together with people who share our enjoyment, to the delight of others, and getting steadily better at doing it.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.227.161.132