The Wisdom of Teams by Douglas K. Smith

The following review is from a book we were assigned to read at work.

Before reading this book I read some of the editor’s and readers’ reviews online and they immediately confirmed my suspicions that this book is geared toward managers and students pursuing an MBA. What could I, as a software developer with little interest in pointy haired boss literature, learn from the type of book that I previously avoided like the plague? Cynical skepticism abound, I first had to dig deep and find the motivation to tackle such an epic ordeal. Modern research by neuroscientists on the plasticity of the human brain suggests the best way to slow brain aging is to learn new tasks and take up new hobbies. So with my personal goal of expanding my neurons and exercising my brain cells, I began reading The Wisdom of Teams.

The book takes an in-depth look at team formation and performance, providing industry case studies throughout the chapters. The authors start with their formal definition of what exactly a team is, which differs from the layman’s interpation. Teams are small in number, are made up of individuals with complementory skills, have a purpose and goals that align with the company’s, have a clear working approach and have mutual accountability amongst the members.

High performance teams have several attributes that set them apart from normal teams. Among them include strong interpersonal commitments, purposes become “nobler”, goals are more urgent and leadership is shared. The authors claim that high performance teams have a better sense of humor and are more fun. The authors then admit that high performance teams are rare, and that the strong bonds among members of high performance teams do not originate from team building exercises, rules or secret formulas, but are rather inate within the team. Unfortunately for managers, this appears to be a repeating thematic idea throughout the book: sub-par pseudo-teams cannot be coerced into real teams.

The authors go on to explain multiple categories of groups/teams in terms of performance and efficacy. Working Groups are not teams but are perfectly acceptable when no significant incremental performance is needed. Pseudo-teams happen when there is a need for higher performance but the group lacks the focus required for collective performance. They are the least effective of the categories. Potential teams are more focused on collective performance. The remaining two buckets are real teams and high performance teams. The largest potential performance impact is between potential and real teams.

These definitions left me a bit perplexed about the author’s main motif. The distinction among the categories is basically team performance and overall success which is only measured at the end. The authors give several real world examples of companies trying to increase their performance. If the group of the people the company assembles to meet their objectives fail, the authors call them a pseudo-team. If, on the contrary, the group of people turns out to be a high performing unit, the authors label them as a real team. By this logic no real team could ever be unsuccessful, because if they were the author would call them a pseudo-team. Is it really the case that if a group of people meets the criteria of the author’s team definitions then they will automatically be successful? Are there no counter-examples, or is this a case of survival-bias when the author’s surveyed the industries for examples?

Despite the authors’ admission that there is no secret formula that teams could follow to achieve high performance, they do detail some common approaches that can help potential teams break through, with the disclaimer that the approaches may or may not work. The list includes, with my comments in parentheses: establishing urgency (threats?), select members based on skills and skill potential (choose the best people), pay particular attention to the first meetings and actions, set clear rules of behavior (do your job and be on time), set performance oriented goals (why create a team without a purpose?), challenge the group regularly with fresh facts and information (track your progress), spend lots of time together (work after hours), and exploit the power of positive feedback, recognition, and reward (undergird their egos; some studies shown that potential reward is not a motivator [1]).

In my opinion the book’s chapter on team leadership was spot on. I have been a part of a few teams in my career, and the best team leaders facilitate the experience. My favorite team leaders appeared humble at times, admitting when they did not know the answers but always following up afterwords. The authors identify some keys to being a good leader, such as keeping the goals meaningful, build commitment and confidence, manage the relationships with outsiders, create opportunities and do real work, no matter how trivial. This is a stark contrast from the normal responsibilities of managers. I like the quote “With no management, is there hope for the software developer?” It is interesting how people react differently to the quote depending on their job title.

It is common for teams to get stuck and encounter obstacles on its way to achieving its goals. To ameliorate stuck teams the authors advocate rethinking the basics, achieving small wins, trying new approaches, training, and introducing new members and leadership. Most seem like common sense tactics. The authors then warn about the difficulties in rotating members into and out of teams. They even went as far as saying when a team gets a new leader from the outside, the team should form a new set of basics and purposes. In other words, the arrival of a new team leader means the team should start over rather than continuing it’s existing agenda.

One of the more interesting chapters was on the reinforcing cycle of teams and performance. The authors outlined three segments that make up a company: shareholders, employees and customers. These three segments all depend on one another. For example, focusing on shareholder value, which is the purpose of public corporations according to law, harms the company’s customers and employees, which in effect will ultimately harm the shareholders. The companies the author chose for case studies, Hewlett-Packard and Motorola, are still alive today despite an ultra competitive environment (although Motorola has since split into two companies, with one of the resulting companies being bought by Google). It seems, in this Wall Street central world, that beating the quarterly estimates trumps all other goals of the company. Perhaps if the US took the authors advice they could change the main aim of corporations to increase value for shareholders, employees and customers alike. Imagine the public’s change in perception of corporations! No longer would they be viewed as evil profit-seeking conglomerates! Honor, dignity and pride would arise in full force! But I digress.

The authors dedicate a chapter on teams and major changes in organizations. In it, they propose four questions that can determine the degree to which companies face major changes, summarized as follows:

1. Does the organization have to acquire new skills? 2. Do large numbers of people have to change specific behaviors? 3. Does the organization have a track record of success in changes of this type? 4. Do the people understand the implications of the change and believe the time to act is now?

In my opinion, for our company I answer “yes” to numbers 1,2 and 4. Coming from SOI I do not know the answer to number 3. There are many new skills we need to acquire as we merge with more companies and move forward with modern tools and technologies. Many of us have to change our behavior and step outside our comfort zone. And we need to do this sooner rather than later. The sooner we start building products for a complete robust PEO solution, the better equipped our company will be to support organic and inorganic growth.

The last two chapters of the book look at the roles and challenges executives face with implementing teams at the top level of management. I still consider myself as being rather early in my career, so I have no experiences to measure the authors’ advice against. They do seem to take a rational approach. They admit that working groups may be the better solution at the top of the food chain for the majority of companies. They do give some examples of large companies that have upper management teams and the outcomes do seem positive. The key seems to be that executives must forgo their roles in the company hierarchy when participating in a team. They also emphasize that executives must do some of the dirty work and refrain from devolving every tasks assigned to them. It shows a greater commitment and helps them get a better grasp of the goals at hand.

One of the topics that I wish the book addressed more was the actual implementation of working teams. Many of the examples gave one or two events that helped to change teams around, but glossed over the everyday itineraries. Did the teams have daily meetings? How much of the member days were dedicated to team goals? Were the projects the teams were working on their main job? How did they address conflicts and difficult decisions? Did they keep track of their hours or did everyone trust that everyone was performing their work? I wondered if any of the companies they researched inadvertently practiced scrum or other agile methodologies before they had a name.

A couple of items that I would have stressed more are team communication and the importance of the goals. Communication is an art form. A email regarding a technical proposal for infrastructure must be handled differently then an email containing a quick question. And for me, the importance of the goal as related to the company factors into my motivation and performance. If I am on a team responsible for choosing the species of office plants I could be detrimental to the team’s ultimate success. Put me on a team assigned to solve crucial company problems and my motivation and focus increases exponentially.

One piece of advice that I will take from this book, maybe to the chagrin of my managers, is that if I find myself on a pseudo-team and it is evident that metamorphosing into a real team is futile, escape as soon as possible. Success will be impossible so better to spend my time helping the company elsewhere.

As I mentioned above, this was the first time I have read this type of MBA type of book. It opened my eyes to some of the problems that plague upper level management. It was a nice learning experience. However I admit it didn’t pique my interest enough to continue learning down this curve. I chose to practice software development for a reason and will continue down that path. As such, I will probably only read other management style books when it is recommended. At least after reading this book I will be more aware of the intentions of upper level management and know the important qualities to stress when working on a team. I will strive to remember the lessons on a daily basis and take to heart the efforts of everyone around me as Trinet attempts to remodel it’s software development team for the future.

[1] http://web.cecs.pdx.edu/~trent/gnu/MOTIVATION