The Manager Pool: Patterns for Radical Leadership / Edition 1 available in Paperback
- Pub. Date:
- Pearson Education
As savvy high-tech managers know, the traditional, industrial models of management do not apply to the fluid and dynamic software development environment. Instead, technical management must formulate a more flexible model of management that can grow and change with the technology. The patterns paradigm that has transformed much of object-oriented software development can be applied to the management side of development. The patterns approach enables managers to identify, understand, and handle recurring management challenges that are common to many software development projects.
The sixty-one management patterns featured in The Manager Pool offer insight into the relationships between developers and their leaders, showing how teams can better work together to develop software. Based on years of experience in the software development trenches, these patterns address many different aspects of technical management, from the dynamic nature of software development, to communicating with the unique programmer personality, to organizing the workspace.
The patterns are organized into several overarching themes: psychological and retentive patterns, behavioral and expulsive patterns, strategic patterns, tactical patterns, and environmental patterns. Each pattern lays out the problem; discusses the context, related issues, and examples from industry; and finally offers a solution. You will read about suchpatterns as:
- LeviathanSoftware development projects are mysterious beasts, too deep and swift for a manager to fully understand or document. How do you know what to control directly, and what to leave to your developers?
- Geek ChannelingYou are responsible for keeping your team in the corporate loop and from spinning in random directions.
- Tribal LanguageUnderstand the cryptic and sometimes evasive language of developers so that you can have some insight into the substance of what is being said.
- Overtime DetoxOppose the temptation of overtime. Resist pressure to compress schedules without corresponding feature reduction, staff increase, or both.
- The GauntletApply a legal-like standard of probable cause to investigate slackers and other problematic team members.
- Train Hard Fight EasyDespite the expense and time, train the team as a unit in relevant technologies to give everyone the same tools and language and so that the team is not using the project itself as the primary learning experience.
- Fall on the GrenadeNo matter who is at fault, take the responsibility for solving a serious problem in the project. Stand up and take the heat when the problem is unrecoverable. Then, move on.
- Unique PlaceMake your work environment unique, inspirational, and fun, so that you can retain your most talented employees. Think about perks, physical space, and entertainment.
Entertaining to read, insightful, and practical, The Manager Pool will provide you with the understanding and knowledge to communicate more effectively with your development team, lead them through to a successful project, and hence propel your own career.
About the Author
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
|Introduction: The Manager Pool||xiii|
|Patterns for Radical Leadership||xiii|
|The Patterns Form||xvi|
|I.||Psychological and Retentive Patterns||1|
|II.||Behavioral and Expulsive Patterns||51|
|15.||Too Clever by Half||61|
|21.||Get a Guru||89|
|22.||Home Field Advantage||93|
|24.||Defense de Pisser||103|
|26.||Push the Customer||113|
|29.||Just Say No||125|
|30.||Grease the Wheel||129|
|31.||One by One||133|
|32.||Train Hard, Fight Easy||137|
|37.||Spanish Ounce of Gold||159|
|40.||Divide and Conquer||171|
|50.||Cop a Plea||207|
|51.||Fall on the Grenade||211|
|Don and Carol's List of Culturally Relevant or Iconic Artifacts||259|
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.
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.
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.