Teams Blog

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.”

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