Six Simple Rules

by Yves Morieux

  When you observe strong emotions in the workplace, remember that they are the consequences and symptoms of behaviors. They may not mean what you think they do at first glance. For example:

  Tension between two work groups might be a symptom of a conflict so intense that it impedes cooperation. Alternatively, it might be a sign that people are doing the hard work of cooperation, with the tension arising from the adjustment costs they must bear.

  Good interpersonal relationships might be a sign that people feel that the adjustment costs of cooperation are worth it, given the individual benefit they are receiving. Alternatively, good relationships may be a sign that people are carefully avoiding cooperation in order not to accept or impose any costs of adjustment.

  Don’t assume you understand the meaning of strong emotions in the workplace context until you understand how those emotions are the result of behaviors shaped by a specific work context of goals, resources, and constraints.

  Respondents expressed a great deal of resentment, however, toward the transceiver unit. According to managers, this resentment dated from when the company began to face tougher competition and the pressure to get out new releases had grown (before then, the three engineering units had all gotten along reasonably well). When we asked the transceiver engineers what they thought about the resentment, they replied, “Pure jealousy! It’s because of our performance! We’re the only group that gets its work done on time!”

  In addition to these pseudo-psychological explanations (“jealousy!”) coming from the members of the transceiver unit, some senior managers also offered cultural explanations to explain performance differences among the work units. The reason the transceiver unit was always on time and on budget? “They are best-in-class, always on time, very disciplined; of course, they’re Swiss German!” (Indeed the transceiver unit was mainly located in Switzerland.)

  Analyzing the Work Context at MobiliTele

  We were not satisfied with these psychological and cultural explanations of what was happening at MobiliTele. So we began to analyze the work context, using the simple rule that we described in chapter 1.

  The program managers were responsible for developing the overall product specifications. They did this by having conversations with their colleagues, including platform architects, members of the sales force, and marketing staff. They also spoke with their counterparts at the big mobile telephony operators that were MobiliTele’s customers to develop an understanding of their needs.

  The program managers then finalized the specs and communicated them to the engineering units. But even at this early stage, there were problems. Because the product releases were so far behind schedule, the specs for the next-generation release always arrived late as well. Indeed, the program managers had created a parallel schedule to the formal schedule that reflected these delays. The engineers in the three development groups had to report on both schedules, the formal one with its official milestones and deadlines, and the informal one that contained adjustments for the delays. Having become accustomed to the delay in the specs, however, the engineers had adjusted their behavior accordingly. Since they had a rough idea of what the next-generation product would be, they would start work on the development of their component before the final specs arrived. They patted themselves on the back for this exercise of initiative: “If we didn’t get started early, the final product would be finished even later than it is.”

  Not all the engineering units were equally affected by the lateness of the product specs. The specs for the transceiver, it turned out, were largely determined by international communication standards and less so—in comparison to the other units—by clients, suppliers, or MobiliTele managers. As a result, the transceiver team could interpret what it thought the evolution of communication standards was going to be, start its work even earlier, and finish sooner than the other units.

  This head start by the transceiver unit had a dramatic impact on the other development groups. The fact that the transceiver unit was always much further ahead than the other two units meant that, when the final specs arrived, the collector unit engineers and the software engineers had to develop the vast majority of workarounds and interfaces to ensure that their components were compatible with both the transceivers and the specs. That took additional time that was not in the schedule and additional money that was not in the budget. The later the final specs arrived, the more sense it made for the transceiver unit not to modify any of the work it had already done, and the greater the pressure on everyone else to modify theirs.

  The negative effects of this dynamic went beyond the issue of delayed delivery. Constantly starting and then stopping to make fixes and workarounds to fit with what the transceiver unit had already done resulted in products that did not fully meet customers’ needs and occasionally even led to product defects. When a customer complained, the platform architects and salespeople had to spend time explaining and justifying the changes, as well as negotiating rebates or other price adjustments. As a result, they had less time to work on preparing the product specs with program managers for the next generation of the product, which meant further delays. Because of all the workarounds and rework, we calculated that only 20 percent of the time the engineering teams spent on the development of any product actually added value.

  Why People Do What They Do: Delays as a (Perverse) Resource

  What was the real goal of the engineers? Was it to minimize delays? No. The engineering units were not penalized when the product was delivered late or even when it was defective. Still, delays meant having to anticipate what the next generation of specs would be, and anticipating invariably meant that they would have to do rework. So what was so great then about starting work before the specs arrived? Well, for one thing, the units could exercise maximum autonomy and organize around their own procedures and strengths. The more they leveraged their own resources, the more efficient they were, at least, as they were evaluated according to the criteria within their own unit.

  What was their constraint then? Remember, constraints are what people avoid, sidestep, or try to minimize. By starting work early, engineers avoided the specs; these were their constraint. After all, the specs materialized and documented the interdependencies among the three development units. The real problem the engineers were trying to solve was how to cope with these complex interdependencies.

  Starting early before the specs arrived (in order to save time) allowed the engineers to ignore some of these interdependencies. The longer the delay, the more justified each unit felt in taking unilateral action on what they anticipated the specs would be.

  Was a delay a constraint, as you might assume? No, it was actually a resource, because it gave engineers a way out of the complex interdependencies. Even after the specs had arrived, the urgency and time pressure that the units experienced justified taking shortcuts and coming up with workarounds that also simplified critical dependencies. Of course, the delays functioned as a perverse resource, the kind that organizations often create unintentionally and that lead to poor performance.

  The transceiver unit was best able to take advantage of this resource (the delays in the specs). Although its performance may have been best-in-class, the transceiver unit earned that distinction at the expense of the other units and of the overall organization (and it had nothing to do with the fact that the transceiver engineers happened to be Swiss). Rather, because the unit could get the biggest head start (due to the role of the international standards in transceiver design), it was in a position to force the other units to adjust in ways that degraded their performance in the form of workarounds that had not been budgeted up front. The greater the delays in the specs, the better the performance of the transceiver unit, compared with (and at the expense of) the rest of the organization.

  Creating a New Constraint to Reinforce Integrators

  How to reshape this dysfunctional work context? There was no doubt that the transceiver unit at MobiliTele held the power. It had the g
reatest influence on the issues that mattered to others. It could affect the amount of extra work the other units had to do and the technical difficulty involved. The development process’s actual managers, the program managers, had no power. They represented an unnecessary overlay that had to be removed, along with its double-scheduling and reporting.

  Since the transceiver unit had the power to force others to cooperate with it, we wondered, could the transceiver engineers perhaps be turned into genuine integrators? Could we create a situation in which they would have an interest to cooperate with and foster cooperation among the other product development units so that together they would make the optimal choices for the entire system? To do that, the transceiver unit would have to be made to bear the cost of its lack of cooperation with the other product development units.

  So, we helped MobiliTele’s management team create a new constraint for the transceiver unit: in the future, it was announced, the transceiver engineers would be accountable for any delay in the design and production of the entire system, not just the transceiver itself. They would accompany salespeople to review meetings at the telephony operators to hear their complaints about the functionality of MobiliTele’s system, and it would be their responsibility to respond to any quality issues or concerns about missed deadlines. After spending a few marathon meetings listening to customers who were fed up with MobiliTele’s constant delays and having to respond to difficult questions and come up with answers that satisfied the customers, the transceiver engineers definitely began to feel personally the costs of the insufficient cooperation among units.

  The prospect of repeated exposure to interactions with unhappy customers had the effect of making cooperation individually beneficial for the transceiver engineers. Instead of just maximizing their own room for maneuver, they began to listen more to customers and to their marketing and sales colleagues and to discover ways of optimizing the interaction with their colleagues in the other product development units. This new context provided a way to make the transceiver engineers personally bear the cost of their uncooperative behaviors. So far they had been able to externalize that cost to other functions and third parties like customers and shareholders. Insufficient cooperation was now a constraint for the transceiver engineers, which not only led them to cooperate more with others but also to serve as effective integrators, expanding cooperation among the two other product development units, and allowing them to simplify the matrix structure by removing the program dimension. Internalizing the cost of insufficient cooperation onto those who generate them is a very effective way to promote cooperation.

  Until recently, MobiliTele was a monopoly in some market segments. To realize the depth of the change it had to go through, we must go beyond the economic definition of a monopoly (one producer with many customers) and take an organizational sociology view. To be a monopoly means that an organization can make customers bear the cost of the comfortable avoidance of cooperation among its employees—in the form of delays, defects, and high prices. Because they have no choice, customers end up subsidizing the internal peace within the monopoly. With more intense competition as a result of deregulation, customers were now in a position to refuse to bear that cost. Real cooperation had to start at MobiliTele.

  But the more work has relied on positive interpersonal feelings, the more a change at work will be experienced as a betrayal by those whose good feelings are strained by the change. This is what had happened at MobiliTele when its quasi-monopoly ended. The very social fabric of the company endured the friction inherent to cooperation, even if this cooperation had been insufficient (limited as it was to just making fixes within two units after the final specs arrived). This is why applying the first simple rule was so important: to show both managers and engineers that the real problem was not ill-will or jealousy, but the very functioning of the system. The systemic appraisal inherent to rule one helps depersonalize issues—showing that problems are not caused by the personal traits or hostility of people—and thus helps make change less personally difficult and dramatic.

  At MobiliTele, the issue wasn’t that the engineers didn’t care or were cynically cheating their employer or were at fault for the problems in the company’s product development process. They were trying hard to cope with the complexity of their interdependency. Remember, goals, resources, and constraints are not psychological concepts; they don’t describe what people think. Rather, they describe the logic of people’s behavior as actors in an organizational system. These concepts are meant to help you assess your organization from the perspective of the behaviors it indirectly shapes, instead of the perspective of the theoretical pros and cons supposed to be directly attached to certain kinds of structure, processes, systems, or personality traits.

  After fifteen months, with the transceiver unit acting as integrator, the company was doing a much better job of satisfying its performance requirements. It was beating industry benchmarks for speed to market by 20 percent, while matching its competitors on cost and quality. There were no delays passed from one release to the next. The vicious circle had been broken.

  Transforming Managers into Integrators

  In an environment of complexity, being an integrator is—or, at least, ought to be—at the very heart of the managerial role. But in order to function effectively as integrators, managers must give up the assumptions of the hard and soft approach. People cannot be commanded to cooperate by forcing a new structure on them or coerced to do so with communications efforts or team-building exercises. People only cooperate when the context of work makes it individually useful for them to cooperate.

  There are three things you can do to help your managers function as effective integrators—that is, instigators of productive cooperation for the good of the organization as a whole.

  Remove managerial positions. Some managerial roles will never have sufficient power to influence the work context so that people have an interest in cooperating. It’s best to eliminate these positions.

  Minimize rules. Too many rules hem in managers and keep them from effectively exercising their judgment. It’s best to minimize them.

  Rely on judgment over metrics. One of the paradoxes of cooperation is that it is extremely difficult to measure who contributes what. For managers to serve effectively as integrators, rely on their judgment instead of pseudo-precise metrics.

  Limit Managerial Roles

  Despite decades of delayering, most organizations continue to have more hierarchical layers than they need. These layers take many forms: project managers (like the ones at MobiliTele), dotted-line positions in matrix organizations, regional headquarters, and functional coordinators. Many of these layers are the inevitable result of the hard response to business complexity. But often another factor is also at play: because the company is not very good at inspiring people to perform, it creates new layers in order to offer promotions into managerial positions as a “carrot.” These positions are just poor substitutes for genuine motivation; they don’t add much value, and the roles have little or no power.

  In companies that have hierarchies heavy with these coordinating functions and pseudo-managerial roles, there is such an excess of managers that they tend to lead very small teams, sometimes composed of only a few people. If a manager has only two direct reports, he or she depends 50 percent on each of them for the work that needs to be done. The reports, however, hardly depend on the manager at all. That’s because, with so many layers and units, there are many ways to bypass the manager. The result is an inverted hierarchy: the manager depends more on the team than the team depends on the manager; managers have insufficient power to add value. It is better to have no hierarchy at all than an inverted hierarchy.

  Therefore, the first step in reinforcing your managers to play the integrator role is to cut the number of hierarchical layers, which simultaneously increases the span of control and shortens hierarchical lines. When managers are too far from where the action takes place they need metrics, KPIs,
and scorecards. All these are poor summaries and imprecise proxies for what people really do. These proxies fail to capture reality while also adding to complicatedness. Whereas most organizations think of delayering mainly in terms of cost savings, far more important is the way it can free up managers to really manage. When you remove a management layer that does not have sufficient power to actively shape people’s work contexts, you not only eliminate an organizational element that is useless and adds to complicatedness (thus altering information and slowing down decisions). You also make it easier to reinforce as integrators the management layers that remain.

  Keep and reinforce only those management positions for which you can give clear answers to these questions:

  What value is this managerial position supposed to add? What is this manager supposed to make teams do that the teams would not do spontaneously on their own? To be clear, we are not talking about writing a new job description. Answering such questions requires getting to the specifics about why you need this management layer and what would not happen without it. All too often, senior executives do not really know what value they expect their managers to add.

  Even when you are convinced that there is some value that managers can add to a particular task or work group, are you sure there is no other manager, located either below or above the work unit in the organization, who may be better placed to play the integrator role?

  Minimize Rules

  To be effective integrators, managers need room to maneuver so that they can make a difference for their teams. This freedom is often eaten away by procedural rules. Just as many organizations have too many layers of management, they also have far too many rules. As performance requirements multiply, they respond by multiplying procedures to address each requirement. When a new urgent need arises—to improve safety, reduce cost, or better manage risk, for example—the response is legislative, creating new formal rules. It’s the same phenomenon that we see in government, where legislators respond to every call for action with a new law.