Teams Blog

People in my line of work don’t want to admit there is little objective evidence team building works. Reports that it does come from people like me, and the people who pay people like me, all of whom have a vested interest in it working. Few team builders bother to create metrics proving a measurable change occurred, as I like to, and fewer customers are willing to pay for tracking those metrics. It has bothered me that I could not point to a study done by scientists with nothing to gain showing for sure that team development impacts team performance. Then I cam across a promising study title from last year: “Does Team Building Work?”

An army of scientists from the Univ. of Central Florida and the U.S. Army Research Institute said in their article in Small Group Research that recent study results were mixed at best, with many studies showing no impact. So they searched for every study of team building interventions that measured performance from a 47-year period. Using data from the 103 studies they found, the researchers state that teams which had performed team-building activities also had better processes, and their members felt better about their teams.  Performance was stronger, too, but the correlation was not as high. You can have better satisfaction and processes without having better measurable performance, obviously. Team building had a weak impact on the team’s thinking processes (cognition). The overall impact of team building was much stronger for teams with ten or more members, probably because they had more problems and thus more room for improvement. For the specific numbers and source information, see my study summary.

Team building aimed at setting team goals and clarifying roles was better than activities that tried to improve interpersonal relations or problem-solving. This is consistent with my observations, though I am biased. My services focus on the first two; teach problem-solving only in context of solving the team’s task issues; and only target interpersonal problems directly as a last resort. Fixing group dynamics eliminates most person-to-person issues while providing more bang for the team’s bucks.

All of that is good news for anyone tying to convince someone to do team building. But don’t get too excited. There are many limitations to this encouraging study. As best I can tell after rereading the same paragraphs five times, it does not differentiate between the games- and ropes-courses method of team building and approaches like mine that help team members agree on formal structures and processes. This disappointed me, since it won’t help prospects choose between these approaches.

The study does not prove that the team building activities caused the positive outcomes. In theory, it could be that teams with high performance are more likely to do team building, perhaps because their efficiency gives them more time for it. Or other factors might encourage both better team performance and more team building, and thus be the root causes. Based on my experience, I think that is part of the story, but those factors are not enough to create high-performance teamwork.

Then there’s the problem of the “intervention effect,” the teamwork equivalent of the placebo effect in medicine. Drug studies can’t just compare people who took a drug with those who didn’t. They have to compare those who took the drug with, for example, people who took a pill that looked like the drug but was made of plain sugar (a “placebo”). Usually the people given placebos do better than those who took nothing. If the drug takers did no better than the placebo takers, it’s back to the lab for the drug maker. By the same token, there is some evidence that doing anything for a team makes the team perform better for a while, perhaps because the employees are happy just to be noticed. Have everybody stand on their heads for a minute and they might report higher morale (until they get back to work).

Nonetheless, all of you with managers or employees (or clients) who refuse to do team building now have some solid ammunition from nearly 50 years of research. In my experience, resistors have experienced something like a team rafting trip that brought no lasting results back at work. Or they were forced to take personality tests that were helpful but only addressed a tiny part of the overall problems, problems that remained unaddressed. Team building works, the UCF research team says. You simply have to choose the kinds that directly target the problems you are facing.

Action Item: If you have been thinking about doing some team building, contact TeamTrainers for a diagnosis of the issues prompting the thoughts. If we can’t help you directly, we’ll know someone who can.

I once shocked a manager by telling her I thought she had rated me too highly in an annual performance review. I don’t recall the details anymore, just the stunned look on her face. Some mistake I had made during the year, though I had identified and corrected it at the time, made me feel that my colleagues had done a better job on one measure. Almost everybody got a 3 on almost everything, so a 3 seemed unfair. When I self-rated, I gave myself a 2. I ended up with a 3 anyway.

My apologies if this comes across as self-aggrandizing, but it illustrates a point: The most common complaints I have heard over the years about appraisals boil down to, “It’s not fair!” Many teamwork scientists and management gurus agree. John Hunter of Curious Cat Management Improvement Blog reports J. Edwards Deming “emphasized that forced rankings and other merit ratings that breed internal competition are bad management because they undermine motivation and breed contempt for management among people who, at least at first, were doing good work.” I’ve said for years that performance appraisals are legal protection for bad managers, a waste of time for the majority. If you set measurable standards for your employees, communicate monthly on the results, and praise and correct at every opportunity, an annual review tells the employee nothing new. If you don’t do those things, the review refocuses their effort way too late—perhaps 12 months too late. Though I offer recommendations in The SuddenTeams™ Program for harnessing appraisals to support team performance, that’s because appraisals are so prevalent, not because I like them.

Words like “fair” always cover a litany of traits, so I was intrigued when I came across a journal article defining the term, in effect. Two business professors, Richard Posthuma of the Univ. of Texas at El Paso and Michael Campion of Purdue Univ. started with a list of 1,000 possible sources and whittled it down to find 18 articles in peer-reviewed journals. From those they compiled a list of 20 best practices for performance reviews (PRs) that employees will consider fair. See the study summary for the complete list, but let’s discuss the ones most directly related to teams.

To ensure the team is focusing its efforts on the priorities of your company (or “nonprofit” or “agency”), I recommend having measurable standards that follow directly from measurable company goals. Some should be individual goals, and each team member should also have the team goals on his or her appraisal. Three of the best practices Posthuma and Campion found relate:

• “The PR should be based on observable job behaviors to the extent possible.”
• “Objective performance data should be considered to the extent possible.”
• “The PR should be aligned with organizational goals and objectives.”

They note in relation to another practice that at the start of the period covered by a review, “employees should have a good idea of what will be expected of them.” As an example of all of these, say a nonprofit helping ex-criminals break the crime cycle has a goal for the year to “Increase case closings by 20%.” The job placement team thus might create a goal of “Increase client placements by 20%,” and it follows that a placement counselor could have, “Place 20% more of my clients.”

You can make your whole HR process more efficient by having every employee draft their own job descriptions and negotiate them into final form with their supervisors. The method also lets you identify gaps between what managers expect and what people think the managers expect. Then use those descriptions as the basis for job ads, interviews, hiring decisions, reviews, and performance improvement plans if needed (to try to correct poor performance before firing someone). This alignment also reduces your odds of legal liability, according to employment law and HR experts. Posthuma and Campion list:

• “The content of the PR should be based on a job analysis or shown to be job related.”
• “Subject matter experts should have input on the factors to be evaluated in the PR.” They add that the best SMEs are people who are doing or have done the jobs.

I am, as regular readers know, a big advocate of employee empowerment. It is the most powerful method of improving a host of measures related to cost-effectiveness, worker and client satisfaction, etc. The professors say a best practice consistently shown to raise employee satisfaction is, “Employee participation should be allowed… in the PR process (e.g., setting goals, providing input on performance).”

Regular readers have also heard me say over and over that you cannot promote people into management without training them on how to lead people and yet expect them to succeed. Several of the appraisal best practices relate to training managers and employees on the process, and the former on how to provide feedback in a legal and respectful way. Most of us hate to give negative feedback, which is why I include that in my effective communication skills class.

If you want performance appraisals to matter to employees, then their appraisal of your appraisals has to matter. This study suggests there is a right way to review, and the professors say following it “should increase the acceptability of the information employees receive during their reviews, reduce the likelihood of complaints, and increase motivation…” If you’re a manager, that should increase your motivation to take the action below and use these “fair” practices.

Action Item: Print off the employee review process best practices and go through the list with your team. Ask members whether they think your process follows the practices, voting “yes” or “no” on each. On any in which many say “no,” work with the team to raise concerns with the “powers that be” in your organization. If you are the power that be, call me to talk about how to make things right: 919-414-8939.

Researchers have been looking into manufacturing, supply chain, and project management for years, often making recommendations to managers. Maybe you have followed their advice on the job. But there’s a problem, according to professors Francesca Gino and Gary Pisano: “Most formal analytical models in operations management (OM) assume that the agents who participate in operating systems or processes—as decision makers, problem solvers, implementers, workers, or customers—are either fully rational or can be induced to behave rationally.” In other words, scientific theories about how to run a plant or project assume that people:

• identify and react only to relevant information;
• have the same preferences in every situation;
• consider all options before making a decision; and
• make those decisions without emotion.

Oh, yeah, sounds like every workplace I’ve been in.

Gino, of the Univ. of North Carolina-Chapel Hill but headed to Harvard Univ., and Pisano of Harvard, point out in a 2008 paper that people effects on a  system’s performance have permeated other fields of research, from economics and accounting to the law. But “a ‘behavioral perspective’ has largely been absent in the field of operations,” they write. Because of this, current OM models can’t really explain the difference between one firm’s performance and another’s. In turn, managers don’t find OM theories very useful. Especially relevant to Teams Blog is the authors’ point that “behavioral operations” researchers needs to look into how individual cognition and “social norms and systems affect operations.” Gino and Pisano say based on previous research (cited below) that this will lead to very different predictions about what will fix specific issues.

In an interview I asked Gino, an assistant professor of organizational behavior, why OM scientists resist research on the effect of human behavior. She said there is “skepticism from some people that maybe it is not dramatic or very significant…” She noted that her co-author’s interest was sparked by going into organizations and seeing what worked, which suggests that other academics have not done that. However, she said, “The researchers, the more they hear, the more they understand that it is important to study the psychology of people.”

People effects have explained results that defied scientific theories in other fields. In the OM world, this could explain “the tendency of projects to run late and over budget or the tendency of organizations to over commit their R&D resources,” the article says. Researchers have identified many biases and questionable rules-of-thumb that affect our decision-making. Gino and Pisano provide a somewhat depressing list of 19 shortcuts humans take in their decision-making that can mess up the results. Some include:

• “Information avoidance—People’s tendency to avoid information that might cause mental discomfort…”
• “Confirmation bias—People’s tendency to seek information consistent with their own views or hypotheses”
• “Law of small numbers—People’s tendency to consider small samples as representative of the (entire) populations from which they are drawn”
• “Sunk costs fallacy—People’s tendency to pay attention to information about costs that have already been incurred and that cannot be recovered… when making current decisions”
• “Conservatism—People’s failure to update their opinions or beliefs when they receive new information…”
• “Hindsight bias—People’s tendency to think of events that have occurred as more predictable than they in fact were before they took place”

Take another example the professors explore, the “anchoring and adjustment” bias. People often start their thinking from a particular point, sometimes without a good reason for it, and then stay too close to that point. In one study, software developers given a higher anchor to start with ended up with higher final estimates than when they were given lower or no “anchors,” the article says. Sales forecasts are often off because they start with the previous year’s sales instead of an unbiased analysis of this year’s market.

Of course, behavioral operations researchers and managers can’t erase human bias. However, Gino and Pisano write, “operating systems can be designed in such a way that systematic errors are eliminated, or at least their negative consequences reduced.”

I asked Gino what advice she would give, for instance, a chief operations officer whose IT planner tends to anchor too closely to industry averages. “First, you need to be aware of the bias, which is a very simple lesson, but it is hard to recognize,” she said. Have someone act as a devil’s advocate, she suggested, asking the planner to bring alternatives to the table and questions like, “How did you come up with this number?” I would add, based on something else she said, that you cannot push the person for a certain number and be surprised when it turns out wrong. In the IT scenario, don’t anchor yourself to industry averages if the planner offers good reasons not to.

While other scientists are catching up to Gino, Pisano and other… okay, I can’t resist calling them “BO researchers*” at least once… take a look at the biases table in the article and maybe you’ll find your own answers. Or call me and I’ll show you how to account for people effects in your operation.

Sources:

• Bendoly, E. (06), K. Donohue, and K. Schultz (06), “Behavior in Operations Management: Assessing Recent Findings and Revisiting Old Assumptions,” Journal of Operations Management 24(6):737.
• Boudreau, J., W. Hopp, J. McClain, and L.J. Thomas (03), “On the Interface Between Operations and Human Resources Management,” Manufacturing & Service Operations Management 5(3):179.
• Gino, F., and G. Pisano (08), “Toward a Theory of Behavioral Operations,” Manufacturing & Service Operations Management 10(4):676.

*BO is American slang for a person’s smell or “body odor.”

How team members “think, make decisions, plan, design, perceive, and remember”—in other words, how information is processed as a group—will clearly impact how the team performs.  But many managers focus on the outputs of the process instead of the process itself. For example, if they don’t like a plan, they will send it back with some changes and questions. When they have to go through this several times on every plan, they understandably become frustrated. Often, though, they will either yell at the team for whatever they perceive the problem to be or start doing the plans themselves. Instead, perhaps they should stop to look at the understanding the team has about what they are planning or the planning process itself.

It may have been Edwards Deming who first said the majority of what appear to be individual performance problems are actually process problems (I confess I didn’t record the source). The AntiClue blog has made the same point, and it’s one of performance consultant Don Clark’s main causes of performance problems (3/4 of which are mostly out of the individual’s control). Almost all process problems boil down to someone not having the information they needed when they needed it, if you include as “information” knowledge, skills, procedures, external decisions, etc. A study from last year confirms that managers need to pay much more attention to how their teams get, use, and store knowledge. Psychology professor Leslie DeChurch and management professor Jessica Mesmer-Magnus teamed up to draw relevant data from 65 studies into team cognition. The American Heritage Science Dictionary defines cognition as, “The mental process of knowing, including awareness, perception, reasoning, and judgment.” The professors describe it as including both “the nature of team member interaction” and “conditions that dynamically enable and underlie effective teamwork,” so it’s both a process and a group mental state. Psychologists Nancy Cooke and Jamie Gorman, the sources of the first quote in this post, put it succinctly: “team mind.”

Cognition is measured two ways. One compares the understanding of some topic across each pair of members on the team. For example, the similarity and accuracy between members A and B, B and C, and A and C are averaged to get a team cognition figure. The other way looks at the team’s overall view of some topic, measuring members A, B, and C together. The DeChurch/Mesmer-Magnus study looked at the ways these two approaches; the type of team (decision-making, action, and project teams); and other possible factors might affect the relationship between cognition and team performance. I won’t go into all the details, but it was clear that the more a team had a shared perception of its work, the better it performed. Though more true on subjective tests like ratings by managers, it also seemed to impact measurable performance. This appears to operate in part by improving work processes and member motivation, but a higher level of team mind by itself raised performance.

The authors suggest that managers pay attention to whether perceptions are shared among team members and in what ways. Cooke and Gorman use the example of a team that works with boilers, pumps, electronics, and motors. Everyone on the team could see a strong connection between all four of these in their work. In a more complementary kind of shared cognition, a couple of members might see connections between the first three items, while another set of members might only see a connection between pumps and motors. Between all the members, however, the team mind sees a connection of all four. In the latter scenario, you can surely see the potential for misunderstanding if those different views were not understood and respected. That is, complementary cognition is okay so long as the people who don’t see the pump/motor connection defer to those who do on matters affecting the motors.

Accuracy of cognition is also important. For example, say you work in a pharmaceutical plant where following a standard operating procedure (SOP) is required by government regulation. It’s not enough for one or two members to understand the SOP thoroughly. If the whole team doesn’t understand it, you increase the risk of a regulatory breach.

DeChurch and Mesmer-Magnus make the interesting suggestion of performing job task analyses on the work the team does and then “structure important support systems (e.g., measurement, performance appraisal, and reward structures) to develop and shape the collective cognition needed for successful teamwork.” I was trained on job task analysis while working at Los Alamos. An outsider observes people while on the job to determine the steps they go through and thus the knowledge, skills, and information necessary to succeed at the job. That done, the researchers say, leadership and training would be likely methods to ensure the team develops the proper cognition.

Or “team mind,” as I think I’ll start calling it. That term makes for all kinds of punny opportunities:

Q. What kind of cognition does a group of soil scientists need?
A. A dirty mind.

Sources:

1. Cooke, N. J., & Gorman, J. C. (in press), “Assessment of Team Cognition.” In P. Karwowski (Ed.), International Encyclopedia of Ergonomics and Human Factors, 2nd Ed. Taylor & Francis Ltd.
2. DeChurch, L., and J. Mesmer-Magnus (2010), “The Cognitive Underpinnings of Effective Teamwork: A Meta-Analysis,” Journal of Applied Psychology 95(1):32.

The benefits of empowered teamwork are one subset of the benefits of Agile software development. Having served as a project manager in an Agile company, I have seen this firsthand, but a talk by an “Agilista” last night confirmed my belief.

If you know about Agile, you might want to skip down three paragraphs as I explain it to newcomers. Traditional “waterfall” methods start a software project with an attempt to capture everything the end user needs to do and estimate the time and money needed. Once that information is approved, next comes design of the software. Then the software is created (“coded”). Next comes the testing phase, during which mistakes (“bugs”) are fixed until the client accepts the software. Finally comes rollout of the product. Each step flows downward into the next, hence the “waterfall” allusion.

In Agile, an initial set of requirements is collected and prioritized by a “product owner” working with the client. These are broken into small chunks, feature by feature, and captured in a “product backlog.” The product owner, a facilitator, and the other team members take a short period to do some initial design work. Then they decide how many of the features they can finish within a pre-selected time, usually two to four weeks. In perhaps the best known Agile method, the period is a “Scrum” and the facilitator is a “Scrum Master.” Once the team decides what to do, that set cannot be changed short of an emergency. The team then does a mini-waterfall of sorts, finishing the selected set of features to the degree they could be released to the customer (whether or not they are right then). After a demo and lessons-learned review, they repeat the whole process with the next set of features, starting the next business day. They’re done with the whole thing when the customer says they’re done.

At a meeting of the local chapter of the Association of IT Professionals, Robert Galen spoke on “Mature Agile Teams–Sixteen Essential Patterns.” Galen is director of research and development at iContact, an e-mail marketing company, and also has his own Agile consulting practice. Along with making me feel better about two points over which I parted ways with the aforementioned company–for those keeping score, I was right on one and half-right on the other–he provided a number of points about teamwork that work in any environment.

One of his 16 “patterns” was “Truly Collaborative Work.” Examples on his slide included, “Developers willingly engage in Testing.” This is not common in waterfall projects, and I have witnessed how it improves quality and cooperation. Another point was, “Members help each other out.” Science has shown that “organizational citizenship behaviors” improve team performance. “Listening to each other; mutual respect” appeared as well. In poorly performing teams, people listen at each other, listening but not really hearing (hence my Active Listening class).

“Behaving Like a Team” was another of Galen’s patterns. I especially liked his point about “Providing each other congruent feedback.” Agile promotes a practice I suggest for all teams in my teamwork book, daily “stand-up” meetings. These are conducted literally standing up, for a maximum of 15 minutes. Each member reports on only three things: what I did in the prior work day, what I plan on doing the next day, and any blocks I’ve run into. The last item becomes a top-priority action item for the facilitator. Galen said members of effective teams also participate in “Passionate debate.” He added “conflict,” but I later suggested the word “confrontation.” The scientific evidence shows that conflict of any type harms teams, but members must be willing to confront each other to make better decisions. Galen also said members will spend personal time together and succeed or fail “as a team.”

The research literature supports the use of self-managed or self-directed teams in most circumstances. Under his pattern, ”Quality on all fronts,” Galen said Agile teams are “Self-inspecting; self-policing; self-learning.”

He did an excellent job of defining the role of the supervisor of a self-managed team. My oft-repeated summary is, ”Tell the team what direction you need it to go, give it its boundaries, and get out of the way.” Then you fall in behind, making sure the team has the resources it needs and nudging it to stay on course. A previous speaker last night had a great analogy. Josh Anderson, Agile Coach at Teradata, likened this to raising the bumpers when you take kids bowling, so their balls stay out of the gutters. Galen’s related pattern was “Saying NO as a Leader.” He emphasized that managers can’t just walk away from the team, and added in bullet points:

• “Sometimes direction is required.”
• “Courage to tell it like it is.”
• “Behind the scenes, 1:1 Coaching…”

Finally, he emphasized, members’ first loyalty must be to the team. This made me uncomfortable, because plenty of teams have failed by focusing too much on themselves. But Agile’s emphasis on including at each step the customer’s representative (the product owner), and often the customer, is a perfect way to align team cohesion with business goals.

I was fired from my first true project manager job. Though I’ll note that the person who fired me was himself fired a few months later, there were some legitimate beefs. The biggest mistake I made was in not telling the sales staff what they were asking for in my first assignment was impossible. I wanted to make a good impression and seem cooperative, but of course the project failed miserably and I never really recovered my credibility. I also didn’t understand the PM role in a customer-facing position. Though the project process I applied in each of my projects was appropriate, and worked well in the rest of the projects, I did not adapt it enough to meet the ultimate outcome: a pleased customer. The boss said I was “too process-focused.” At the time I was flabbergasted by the statement, given that he was a PMP® (certified Project Management Professional) and yet had zero PM processes in place. Projects were inefficient and often missed their targets.

We both might have kept our jobs had we found a better balance between outcome and process. A TeamResearch News summary I just posted reports on a study that addresses this need. It found, first, that student teams who took time to do any planning at all did better at a game requiring teamwork than those who didn’t. Those whose planning focused on the goal rather than the process did better when some of their resources were taking away halfway through the game. The researcher believed the outcome teams were better at adapting their processes to the change. The type of planning made no difference when a team member was added late. I’d guess adding a member required no process change, whereas losing materials might.

This was reassuring to me because my teamwork training method, The SuddenTeams® Program, reflects these findings. The study author, Harvard-trained researcher Anita Woolley of Carnegie Mellon University, writes in her article that managers should “pay attention to how they structure early team meetings and the relative emphasis they place on processes versus outcomes.” Based on what the scientific literature had told me, I have teams address both goals and processes. But the order of events relative to this issue is:

1. Set a team mission.
2. Set goals toward meeting the mission.
3. Identify team stakeholders.
4. Document team and work processes.

Immediately after that, the team dives into process improvement. Written processes are a key step in every quality improvement system like TQM and Six Sigma, and invaluable for improving efficiency and reducing conflict. But The SuddenTeams Program puts the emphasis on what the team is accomplishing and for whom before defining how to get there. As the study shows, and my firing taught me, both the outcome and processes are critical to maximum team performance, but you have to keep your eye on the prize.

Comment

I am working as a volunteer stagehand for the City Ballet of Raleigh production of The Nutcracker Suite, and it reminded me how I got started as a team leader. My undergraduate degree was in that kind of work from North Carolina School of the Arts (as it was called then), which may seem to have little to do with team coaching. But it was there I first led a team, ten students working as the lighting crew. Someone else designed the lighting, but as “master electrician” it was my job on “load-in” day to get the 120 or so lights hung where they belonged, connected to the right circuits, and the circuits connected to the right dimmers.

I planned that thing half to death. I led the team in preparing the lights, developed a process, and trained the members on it. As a result, we got the load-in done very quickly—one “techie” not on the crew said our time had to be “some kind of record.” Without knowing it, I had just become a project manager. The parallels between a show and a business project are obvious: each has a budget, schedule, and scope and quality requirements. Unlike a lot of projects, though, a show has a “hard deadline.” Most business projects that supposedly have such don’t really. If enough things go wrong, the deadline moves. But with a show, when the curtain is scheduled to go up, it has to go up.

Oddly, most shows I’ve been involved with did so without massive last-minute pushes. (Not all, of course—I recall loading out one show’s costumes the night of the final dress rehearsal after nearly pulling two all-nighters in a row to get done.) And conflicts break out, but most of the time they get smoothed over at least to the degree that everyone does their job professionally. I can’t say either of those positives applied to most of the business projects I have observed, even in mature companies. Techies and onstage performers alike are rightly known for their “whatever it takes” attitude, but the same is true of most of the team members I’ve worked with. Is the difference in show “project” success the clarity of the goal in putting on the show? The fact that roles and responsibilities (on- and offstage) are extremely well defined? How well understood the process and tasks are by everyone on the team, across all functions? The fact that everybody including the techies has a backup with the training to step in on a moment’s notice?

I’m not sure. But I am sure if your team had all those best practices in place, it would be performing a lot better than any of your competitors’ teams.

Comment

Paul Maurice, coach of the Carolina Hurricanes professional hockey team, spoke on “Building a Winning Team” at an Association for Corporate Growth meeting recently. The title is somewhat ironic, given that the team was 2-11-3 on the season at the time, as he noted. Although I think sports metaphors are often misapplied in the business context, some of his comments mirrored what I have seen in business teams. A great way to tell that a team is in trouble, he said, is to observe members at a meal. If you have the stars at one table, the rookies at another, and the struggling players in a third, you have a problem. I have seen this in corporate lunch rooms, and it usually means your team has broken into subteams and is not working together. I asked what he did in that situation, and he said he would address individuals in each subteam to have them reach out across the borders. That’s a good first step.

He was surprisingly introspective given the stereotype of a professional coach. A few years ago, he said, the team was doing reasonably well, but after a loss to Florida he went into the locker room and lit into them as their heads hung down. The team lost a large number of games in a row afterward. He said many variables go into losing streaks, but he could not help but wonder how things might have differed if he had picked a better way and time to express his concerns.

But the most powerful thing he stated regarding teams is that you can tell within ten minutes of watching video of a good team what their system is. He listed all kinds of hockey terms I didn’t recognize, being a basketball fan, but the point was that the hockey equivalent of the team’s work processes were done in repeatable ways that an outsider could quickly recognize. On the other hand, he said, you could watch hours of videos of poorly performing teams and never figure out their systems.

In other words, if you want quality, you have to take the time to formalize your processes. Common to every quality control method from Total Quality Management to Six Sigma is writing down or diagramming of processes. That’s the only way you can ensure smooth coordination and handoffs of work—or the hockey puck.

Comment