ISBN-10:
0201725835
ISBN-13:
9780201725834
Pub. Date:
08/28/2002
Publisher:
Pearson Education
The Manager Pool: Patterns for Radical Leadership / Edition 1

The Manager Pool: Patterns for Radical Leadership / Edition 1

by Don Sherwood Olson, Carol L. Stimmel

Paperback

Current price is , Original price is $34.99. You

Temporarily Out of Stock Online

Please check back later for updated availability.

Item is available through our marketplace sellers.

Product Details

ISBN-13: 9780201725834
Publisher: Pearson Education
Publication date: 08/28/2002
Series: Software Patterns Series
Pages: 320
Product dimensions: 7.44(w) x 9.20(h) x 0.78(d)

About the Author

Don Sherwood Olson has been a software engineer for over twenty years in such diverse domains as rocket propulsion, air transport systems, satellite operations, and telecommunications. As a consultant, developer, author, and trainer, he has pioneered the practical application of both technical and organizational patterns. A long-time member of the patterns community he has contributed as an author and shepherd to authors for the PLoP and ChiliPLoP conferences.

Carol L. Stimmel, a frequent contributor to PLoP and OOPSLA conferences, has more than twelve years of experience in telecommunications, Internet, and aviation-related R&D.

Table of Contents

Acknowledgmentsxi
Introduction: The Manager Poolxiii
Patterns for Radical Leadershipxiii
The Patterns Formxvi
The Visionxviii
I.Psychological and Retentive Patterns1
1.Guiding Hand3
2.Total Commitment5
3.Leviathan11
4.Drama15
5.Metaphor19
6.Switzerland23
7.Good Service27
8.Whole People31
9.Cultural Competence35
10.Hover Shoes39
11.Blowhole43
12.Geek Channeling47
II.Behavioral and Expulsive Patterns51
13.Exhibitionism53
14.Shameless Ignoramus57
15.Too Clever by Half61
16.Forty Whacks65
17.Tribal Language69
18.Social Jester73
III.Strategic Patterns77
19.Direct Action79
20.Outcome Based85
21.Get a Guru89
22.Home Field Advantage93
23.Overtime Detox97
24.Defense de Pisser103
25.The Gauntlet109
26.Push the Customer113
27.Finish Line117
28.Inoculation121
29.Just Say No125
30.Grease the Wheel129
31.One by One133
32.Train Hard, Fight Easy137
33.Trial Project141
34.Secret Stash145
35.Defeat149
36.Casual Duty153
IV.Tactical Patterns157
37.Spanish Ounce of Gold159
38.Significant Events163
39.Herding Cats167
40.Divide and Conquer171
41.Peer Pressure175
42.Passengers Push179
43.Decipher Discontent183
44.Backfires187
45.Enough Rope191
46.Rotten Fruit193
47.Featurectomy197
48.Containment Building201
49.Cargo Cult203
50.Cop a Plea207
51.Fall on the Grenade211
52.Abandon Ship215
V.Environmental Patterns219
53.Living Space221
54.Unique Place229
55.Ball Court233
56.Private Space237
57.Public Space241
58.Geek Space245
59.Formal Space249
60.Fuel251
61.Vacation255
Don and Carol's List of Culturally Relevant or Iconic Artifacts259
Bibliography269
Index277

Preface

Have you ever noticed that software geeks love new stuff -- new hardware, new operating systems, new languages, and new techniques? Mostly, though, geeks thrive on innovation -- big ideas! Many geeks not only consider new ways of thinking, but they often become true believers, exhibiting a fervor that is not so distinguishable from rabid evangelism. Although this may say nothing about the ultimate truthfulness or usefulness of a particular notion, some notions do result in phenomenal breakthroughs of thought, whereas others are pathetic failures. Patterns is one of these new ideas. Although not as recent as some other phenomena, it remains to be seen whether this is really transcendent thinking or just another silly distraction.

With the widespread use of object-oriented technologies, the discovery and use of patterns to help build reusable software is one of the trendiest and most promising movements in software design and development. In fact, if you're reading this book, chances are you already have, or will, sign an expense voucher for Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, Helm, Johnson, and Vlissides, Reading, MA, Addison-Wesley, 1995). Although concerned primarily with software design, in the wake of this popular book an entire patterns culture has evolved that seeks to redefine the relationships between software development, software developers, and the broader society to whom we are all ultimately obliged.

Historically, this particular concept of patterns goes back quite a bit further than 1995 and the publication of Design Patterns, to the effusive efforts of architect Christopher Alexander. Although his legacy inspires from mild interest to fanaticism in the patterns community, his contributions are accepted universally for providing the common vocabulary that we use in defining patterns.

Christopher Alexander believed that he could help people to build homes and communities that would reflect and support their lives to the utmost degree. By extracting patterns he observed in the buildings and towns of many cultures, he hoped to document those structures that ministered to our basic human and social needs and which made people feel alive. He believed that those things that fulfilled these needs were motivated by principles that could lead to tangible, objective, actionable strategies. It was his form of documenting these observations that have come to be called patterns.1

We are concerned with improving the human facets of the computing experience. We believe that the use of patterns is about going beyond technique in a movement toward the essential core of successful software development -- toward us, your developers. Tools don't develop software. Methodologies don't develop software. People develop software. And the people that develop software are not motivated in the same way as those in other aspects of the development process. The whole notion of career for many software developers is something completely different from what one would find among executives, marketing specialists, sales people, or mid-level managers. A satisfied engineer may spend his or her entire career in the same nominal position, learning and creating new "stuff" for more than 25 years without a feeling of failure or regret when retirement finally comes. Would an entry-level marketing hotshot or a finance wizard with a freshly minted MBA be satisfied with a similar career trajectory? Probably not. Despite the many management gurus who believe that motivation is motivation is motivation, regardless, we know that things are different down on the cube farm. We've lived there for a long, long time.

The authors have many years of experience in the trenches of software development and have seen a lot of trends and techniques come and go, mostly with little cumulative impact with how we ultimately do our jobs. Despite the dearth of actual improvements in how we produce software, software developers continue to see development cycles become shorter while the days get longer. The time has come to retire the old industrial models of management. The environment has become too fluid, the forms too dynamic, for us to cling tightly to old concepts, or to any concepts, for that matter, that cannot flex to accommodate all the changes yet to come. These patterns are about people working together to develop software. This book is about the relationships among these people, and, more specifically, their relationships with their leaders.

It is in the spirit of Christopher Alexander that the authors of this book use this literary form to help technical staff better communicate with their managers. More importantly, however, we hope this book will provide managers with insight into the tribe that is the development community, offering the tools they need to communicate more effectively with their development staffs.

The Patterns Form

To assist your understanding of the material, it helps to understand the form itself. With each pattern described in this book, you will often find a picture that helps set the tone or that serves as an example of what we are relating. You will find an assertion of the problem in bold type, followed by a discussion of the forces, context, and related issues. This is followed by a solution in bold type, and sometimes by our basis for making such statements. Each pattern has a name that we have carefully chosen so that it may become a handle for the pattern. You will discover that these handles are referenced throughout the book, creating a web by which the patterns are interrelated and rely upon each other to be perfectly fulfilled. Any time a pattern is referenced it is referenced in capital letters in special typeface, as in FALL ON THE GRENADE, or DECIPHER DISCONTENT. Flip through the book, as necessary, to fully enjoy the patterns form. In fact, it is possible to experience the book by only reading the bolded section of the patterns as they create problem-solution pairs. When you find something particularly interesting, then go back and read the entire pattern. We hope that in time you will find yourself using a kind of shorthand in your daily adventures: "He didn't survive the GAUNTLET. We might have to drop the ROTTEN FRUIT and surround the project with a CONTAINMENT BUILDING."

Our hope is that by using this form, you will be able to grasp the entire collection of these patterns as a whole, within which there are a variety of combinations in which they can be applied. Our further hope is that you will come to understand a bit more about the special nature of your software developers. Christopher Alexander wrote:

Its result is to allow things to be alive -- and this is a higher good than the victory of any one artificial system of values. The attempt to have a victory for a one-sided view of the world cannot work anyway, even for people who seem to win their point of view. The forces which are ignored do not go away just because they are ignored. They lurk, frustrated, underground. Sooner or later they erupt in violence: and the system which seems to win is then exposed to far more catastrophic dangers.5

As ubiquitous as software has become in our lives, while at the same time it is increasingly invisible, the software development community has a lot to answer for and a lot to be proud of as well. It is early in our history, but that history is an accelerated one, one that will propel us beyond our ability to shape it if we do not become conscious of what we do and, more importantly, why we do what we do.

We are entering a new era, one in which work-life balance is replacing pure ambition and where the measure of personal success is not in power or money but rather in the way in which one's work supports a life. We think that this is a good thing, and we cast this modest tome into the sea in hopes that it will inspire those unknown to us to further humanize the workplace and help others to feel more alive. The generative, though perhaps seemingly indirect, effect of feeling more alive will be to produce more creatively and proficiently.

A Note on Our Particular Use of the Form

We primarily use the form as a literary device. Although it is fundamental that patterns be observed, we have taken the modest liberty here and there to document our collective dreams or ideas rather than hard examples in the real world. This may violate some notions in the patterns community that something should be observed in three separate instances, but we have not been so rigorous in all instances. If the reader prefers such rigor, then those patterns not meeting this criterion should be ignored (but read them anyway). Perhaps the dreams will be infectious.

The Vision

Think of the traditional rural county fair, where one can watch the farm kids display the animals they have raised to be viewed, judged for excellence based on a variety of elements, such as weight, luster of coat, and overall health, and ultimately to be bought at auction.

The Manager Pool is our hoped-for paradigm for high-tech management of the future. Today, teams do not select their managers. Projects are started under a particular manager's aegis, and then team members are either assigned to the task or the manager is granted members from the organizational pool. In some critical instances where the project is high profile or strategic, teams even may self-select the most fit members for the task. But teams never select their managers.

Which begs an interesting question: In a world in which teams select their managers from a pool, would you be selected? Just how secure are you in your ability to lead your team into a bold new age where information technology touches all? How do the people you lead really feel about you? Do you even care? What if you stood among your peers while self-selected teams shopped for a manager? Would you be a prime pick? Or as Christopher Alexander predicts, is your system of management selection leading to catastrophic failure?

I know software developers, you may be thinking. A bunch of whiny geeks with fat 401K plans, now dishing out advice and implying that I'm as useful as a cow. Besides, left to their own devices, the nerds you know would only choose people to manage their teams who are weak or easy to manipulate, or who are just good-natured saps that they can push around and leave all the superfluous work to.

We admit it, this sounds amusing for a moment, but there is a more realistic point of view: Software developers do not want weak managers.

While the whole concept of "management" may annoy them and while they may look down upon it compared to the "purity" of software development, the geeks around you absolutely value what you do and what you do for them. First of all, you do it, not them. That's worth something. You keep the other managers off their backs and you filter all the noise that buzzes around the project into a concise and intelligent stream. You work the interfaces and get the developers what they need so that they can focus on what it is that they do best -- creating solid software. You give moral support, and remind them of the value of what they do when they hit those inevitable dips and hollows. You know that if in mid-project you left, or were transferred, or promoted, that it would bring grief to your team members...don't you?

Corporations claim to be meritocracies, but anyone who has worked for a time in the real world knows that pure merit does not fuel a rise to the top. Ability and achievement are important, to be sure, but in a world in which the hierarchy narrows as you rise, other factors must play very large in the selection of those who are to be moved to the next rung. For many managers, unfortunately, a narrow focus upward is the nucleus of their existence. Their pains exist in pushing for success, nothing more than another appeal to those in power, and as they scratch higher, those upon whose shoulders they stand are too easily forgotten.

A manager who has the devotion of her people, we believe, will ultimately triumph over someone who only plays the game for herself. Developers don't become devoted to people who view them as interchangeable parts. If your aim is solely to ascend the corporate ladder and you are looking for a method to climb higher and faster, even if it means figuring out how to squeeze the most out of your pesky developers, then we salute your indefatigability. But we really have nothing to say that can help you. For those who are looking for a better way to be effective leaders, we vigorously salute each of you because we hope that you will become the sort of person that we would someday happily choose out of any manager pool as our leader.

The real competition is not for the attention of the executive board but for the love -- yes, that's right, love -- of your development staff, and for those in other teams who learn of your goodness by word of mouth. Think that this is some hallucinatory fantasy of ours? Well, maybe. The authors indeed have worked diligently for leaders whom they adored, and for whom they have even changed jobs and watched others change jobs for the same reason. The truly Great Ones thrive to this day, surrounded as ever by developers who have only a single condition on their employers -- that they work for one of these Great Ones. Ask a few developers outright: Would they prefer to work for the slick, silver-tongued, aggressive, upwardly mobile managers down the hall, if it meant an instant 10 percent salary increase? If they would, then you have just discovered the metric for greatness (or the lack of) in your company, although it is admittedly rather crude. If not 10%, then how about 15 percent? 20 percent? More? Wow! We're impressed. The more it would cost to lure your people from you, the higher you are held in their esteem.

We've been told that this idea of teams selecting managers from a pool, The Manager Pool, is a ridiculous fantasy. It smacks of social engineering, and the "powers that be" don't want to test the theory and risk complete corporate chaos. There are other well+ documented and slickly presented professional programs out there that teach pleasant, risk-free approaches for accelerating production in the organization. That is, risk-free for those who think it's risky to put their own hide on the line. As for those mysterious "powers that be," we are frankly suspicious of past embraces of Total Quality Management, lifestyle policies that look good on paper, corporate reengineering, automatic code generation, and hope that the "powers" shudder at the idea of inverting a few bricks in their hierarchical pyramid.

Our approach is rather more civilized. We are not proposing "a dialectic in the capitalist boondoggle" of software development as a secret way to topple them from their peak. We just want the opportunity to find and work for leaders that help us to excel. And we want to excel by building software, and building it in a manner that makes the world a better place.

This book offers you the tools to help you to become the kind of manager who would be selected even in the ugliest of managerial pools by software work teams who are autonomous in the selection of their own members. We encourage you and your company to embrace the challenge and adopt The Manager Pool (or at least the attitude implicit in the concept), where leadership staff can be traded, fired from the team, or kept in perpetuity. Consider the idea of The Manager Pool as the sincerest test. You might get the Blue Ribbon.

Footnotes

1. For a more complete discussion of Software Patterns, see James O. Coplien's Software Patterns, SIGS Books and Multimedia, AT&T, 1996.

Alexander described patterns in The Timeless Way of Building:

Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution....It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing.2

2. Alexander, C. (1979). The Timeless Way of Building. New York: Oxford University Press, 247.

And from patterns, we build pattern languages:

The structure of a pattern language is created by the fact that individual patterns are not isolated.3

3. Ibid., 311.

In time such languages become alive themselves:

Yet, changing as it is, each language is a living picture of a culture, and a way of life.4

4. Ibid., 347.

5. Ibid., 304.

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews