Dysfunctional Dynamics
What happens when organizations don’t do a good job of cycling between factory and studio modes of work? We have observed two related failure modes, ineffective iterationand wasted attention. When they are combined, they create a truly unproductive work design — one we have dubbed the axis of frustration. (See “The Axis of Frustration.”)
Ineffective Iteration. Consider first what happens when elements of the work in question are highly ambiguous but are nonetheless organized serially (captured in the box in the lower right-hand corner). Relative to a more collaborative design, this approach tends to create slow and costly iteration. The lack of speed comes because the ambiguity must travel among participants to be resolved, thus requiring multiple rounds, each of which takes time. Worse, when knowledge work is designed serially, many of these interactions take place through email or text messaging. Research suggests both that such communication modes are less effective for reducing ambiguity than face-to-face communication
and that those sending such messages are unaware of those limits.
i Trying to resolve ambiguity via email or text messaging tends to create more misunderstandings and often necessitates multiple iterations.
Wasted Attention. On the flip side, organizing well-defined work in a collaborative fashion also creates inefficiency. If the work is clearly defined, then it doesn’t benefit from a collaborative approach, and collaboration just multiplies the cost. Worse, too much collaboration may prevent the efficiencies that come with the learning curve that emerges when people repeat the same task.
ii
The Axis of Frustration. Whereas functional work processes move between the factory and studio modes, our research suggests that absent careful design attention, processes can devolve to the point where they move between the failure modes described above, oscillating between wasted attention and ineffective iteration — the dynamic we call the axis of frustration.
Getting stuck on the axis of frustration typically starts with time pressure — a project is behind schedule or a more repetitive process is not delivering on its targets. When people feel they are behind, they don’t want to take the time to shift into collaborative studio mode for problem-solving, preferring to stay in the factory box on the lower left and “just get the work done.” The consequence of this decision is to leave one or more problems unresolved, whether it is an element of a product design that doesn’t work or a defect in a manufactured product. Eventually, these problems will be discovered, usually by an activity downstream from the one that generated it. And, if this problem is not then solved in collaborative studio mode (again due to time pressure) but instead sent back for rework, then the system has effectively moved from the box on the lower left to the box on the lower right and is now in “ineffective iteration” mode.
The consequence of ineffective iteration is that the process becomes increasingly inefficient and incapable of meeting its targets. Senior leaders are, of course, unlikely to stand idly by and will eventually intervene. Unfortunately, the typical intervention is often to scrutinize the offending process in more detail, usually in the form of more frequent and more detailed review meetings. (As a manager we once interviewed said, “I knew my project was in trouble when I was required to give hourly updates.”) But the form of those reviews makes all the difference. If they are well designed and focus on resolving the key problems that are causing the iteration, then they can move the system back to a more productive cycling between factory and studio modes. Such interventions, however, are the exception rather than the rule.
The Axis of Frustration
When organizations make the mistake of both structuring well-defined work collaboratively and ambiguous work serially, the result is a highly inefficient process we call the axis of frustration. This process oscillates between wasted attention and ineffective iteration.
Most work processes have not been designed with escalation mechanisms in mind. So, when senior managers want to intervene and scrutinize a project, they don’t know where to look and want to review everything. The result of such scrutiny is long review meetings, the majority of which focus on elements of the process that are just fine, thereby trapping the process in the upper left-hand box, “wasted attention.” Worse, long review meetings and the preparation that they require steal time and resources from actual work, thus intensifying the time pressure that prevented a proper shift between work modes in the first place. Without careful attention to the mechanisms that move a process between the individual and collaborative modes, processes can increasingly cycle between ineffective iteration and wasted attention, basically moving between frantically trying to solve (or at least hide) the latest problem before the next review, and endless, soul-destroying review meetings that never get to solving the problems that would really make a difference.
The agile approach to software development also improves the quality of the time that developers spend working alone. The focus on developing pieces of functionality means that both the team and the customer are never more than a few weeks away from a piece of software that can be used, making it far easier to assess whether it meets the customer’s need. In contrast, in waterfall, the early phases are characterized by long lists of requirements and features, but there is nothing to try or test. It’s not surprising that waterfall methods often lead to projects in which major defects and other shortfalls are discovered very late in the development cycle and require costly rework.
16
Applying Dynamic Work Design
Both the Toyota production system and agile-based software methods are thus examples of what we call good dynamic work design. In contrast to traditional static approaches, dynamic work design recognizes the inevitability of change and builds in mechanisms to respond to that. Once managers recognize the necessity of moving between more individual and more collaborative modes of work, they can build on four principles to create shifting mechanisms that are well matched to the work of their organization.
1. Separate well-defined and ambiguous work. Begin by clearly separating well-defined and ambiguous tasks. Trying to handle both types of work in the same process often leads to trouble. (See “Dysfunctional Dynamics.”) Often, the two types can be separated by inspection, but if not, then look for the signature element of ambiguous work, iteration. When work is well defined, it can be moved to the next stage like the baton a relay runner hands off. When done correctly, it doesn’t need to come back. In contrast, when work is ambiguous, even the best effort often needs to be revisited. If you find that a particular task often requires multiple iterations through the same set of steps, that’s a good sign that you are confronting ambiguity inefficiently.
2. Break processes into smaller units of work that are more frequently checked. If you strip away all the hype, the agility of any work process — meaning its ability to both adjust the work due to changing external conditions and resolve defects — boils down to the frequency and effectiveness with which the output is assessed. In both traditional, pre-Toyota manufacturing and waterfall software development, the assessments are infrequent and not particularly effective. Consequently, both approaches tend to be slow to adjust to changes in the external environment, and quality will be achieved only through slow and costly rework cycles. In contrast, when assessments are frequent and effective, the process will be highly adaptable and quality will improve rapidly. The fundamental recipe for improved process agility is this:smaller units of work, more frequently checked.
3. Identify the chain of individuals who support those doing the work. It is also important to identify the help chain — the sequence of people who support those doing the work. In manufacturing, the help chain starts with a machine operator and extends from foremen to supervisors all the way up to the plant manager. In software, the help chain often begins with an engineer and moves through the team leader to more senior managers, ultimately ending with the customer. It is critical, in our experience, that you identify the chains of individuals who do and support the work, not their roles, departments, or functions. Increasing agility requires knowing whom to call when there is a problem or feedback is needed.
4. Introduce triggers and checks that move work into a collaborative mode.Once you understand the help chain, you have two basic mechanisms for activating it:triggers and checks. A trigger is a test that reveals defects or misalignment and then moves the work from a factory mode to a more collaborative mode. In our opening example, the Toyota operator’s inability to complete the assembly task on time triggered her pushing a button and then receiving help from a supervisor. A checkinvolves a prescheduled point when the work is moved to a more collaborative environment for assessment. In agile software development, this shift happens daily in stand-up meetings where the team quickly assesses the current state of the project. Completing a sprint creates a second opportunity, this time to check in with the customer.
Improving Procurement Performance
Using this dynamic work design framework within a company can lead to significant improvements in both efficiency and adaptability. Consider the case of a company we’ll call “RefineCo,” which owns several oil refineries and distribution terminals in the United States. The company had a procurement organization that was uncompetitive by almost any benchmark. RefineCo paid more for similar parts and services than its competitors, and the procurement group’s overhead costs were higher than the industry average. Even more troubling, when critical parts were not delivered to a refinery, it often turned out that the location was on “credit hold” due to an inability to pay the supplier in a timely fashion. Every participant in the system, from senior management down to the shipping and receiving clerks, was frustrated.
The procurement system at each of RefineCo’s sites worked roughly as follows. To purchase an item or service from an outside vendor, an employee would enter the requirements into the electronic procurement system, which would then appear as a request to the central procurement function. The staff in the procurement office would then review the request and issue a purchase order. That order would go to the supplier. When the product arrived at the refinery or the service was completed, a packing slip or service order verification slip would be generated, which would also be entered into the procurement system. Later, the supplier would generate an invoice that was also entered into the system. The electronic system would then perform a three-way match to verify that everything was done correctly: The purchase order should match the verification receipt, which, in turn, should match the invoice. If there was not a three-way match, the invoice would be “kicked out” of the system and the supplier would not get paid until the discrepancy was resolved.
The job of resolving those discrepancies fell to the staff in the refinery’s purchasing office. Unfortunately, the products and services procured frequently failed the three-way match, leading to both an overburdened purchasing department and frustrated suppliers. Though the refinery was part of a large and successful company, it was frequently on credit hold with its suppliers for failure to pay invoices on time, making it difficult for the staff to do their jobs and run the plant safely. The dedicated procurement staff worked 10-plus hours per day and had hired temporary workers to help manage the backlog, but they were still falling behind.
Most of the members of the procurement team complained bitterly about being “overworked” and how “screwed up the system was.” Nobody saw any opportunity for improvement beyond adding what appeared to be much-needed staff. For us, the critical moment in our work with the procurement staff came when one of the longtime team members explained that a good purchase request contained “all the information I need” and could be turned into an official purchase order in “five to 10 minutes.” A difficult one, however, lacked key pieces of information and might require one to two hours to process as the purchasing staff traded emails with both the requesting unit and the supplier. Despite this effort, difficult purchase orders were usually the ones that failed the three-way matching process and got kicked out of the system. Further investigation revealed that the purchase order system was completely gridlocked with the kicked-out orders, and the team spent much of its time trying to clear the backlog. The system had descended into the classic “expediting” or “firefighting” trap: There were so many purchase orders in process that the turnaround time for any given one was very long. But long turnaround times created unhappy customers and suppliers who constantly called to complain and ask about their particular order or payment. Consequently, the procurement team was constantly reprioritizing its work and reacting to whichever customer or supplier was most unhappy.
Our first insight came in recognizing that the procurement team was engaged in two different types of work that corresponded to what we call serial “factory” work and collaborative “studio” work. When the requested item was standard and all the needed information was provided, a single person could easily process the request without collaboration; then, once the purchase order was entered, it would easily flow through the system, just like an item on an assembly line. However, standard requests flowed easily through the system only if the request came with the correct information. If it did not, then it could require several rounds of iteration, usually via email, to issue the purchase order. So the purchasing function created a simple checklist that described a good purchase request. The idea was to ensure that standard orders would always arrive with the correct information. To give the various departments an incentive to use the checklist, the purchasing function promised that any request received by 7 a.m. with the proper information would result in a purchase order being issued by 2 p.m. that day. At that time, a one-day turnaround was unheard of because every order simply went into the “to do” pile. The purchasing department also created a simple trigger to improve productivity: Purchase orders that were missing items on the checklist would be immediately returned to the requesting unit.
The second part of the intervention came in recognizing that not every request could be supported in factory mode. In the existing system, neither the requesters nor the purchasing staff distinguished between a standard request and a novel one. Thus, when a request for a new product or service showed up, the agent would do his or her best to process it, typically requiring multiple emails with the requester, often over several days, to nail down all the relevant information. In many cases, when the agents couldn’t get the information they needed, they would make their best guess and then submit an incomplete or incorrect purchase order. This, too, created additional iteration, as the supplier, unsure of what was being requested, would call or email the agent. The purchasing process was thus living in the lower right-hand box of our matrix, attempting to accomplish ambiguous work in a serial fashion and thereby creating slow and expensive iteration.
Creating an effective collaborative studio mode to handle the complex purchase orders required two changes in work design. First, the team created a clear trigger: If a request was nonstandard, then it was moved into a separate pile and not dealt with immediately. Second, each day at 2 p.m., the team would work together to process the more complex cases. By working collaboratively (in studio mode), they were able to resolve many of the more complex cases without additional intervention — somebody on the team might have seen a similar order before. Also, having a face-to-face meeting was far more efficient than the endless chain of email that it replaced. And, if additional information was needed, the team could schedule a phone call in the time window after 2 p.m., rather than send an email, again reducing the number of expensive iterations.
The results of these two changes were significant. Creating a factory mode for the standard orders allowed the team to make good on its “in by 7, out by 2” promise almost immediately, generating an immense amount of goodwill with the requesters. Spending the afternoon in studio mode also sped the processing of the complex orders. The two changes created enough space that the team was able to use studio time to not only process the more complex requests but also work through the backlog of unresolved older orders. In the end, due to the efficiency improvements, the procurement team reduced its staff by the equivalent of two full-time staff members, while providing far faster and more reliable service. These process improvement insights were then applied to the company’s other U.S. sites and, as of this writing, RefineCo pays more than 90% of its invoices on time, resulting in a far happier collection of suppliers.
Look for Best Principles
Managers and consultants are often obsessed with the search for best practices — those activities that appear to separate leading organizations from the rest of the pack. The idea behind this search is that once identified, best practices can be adopted by other organizations, which will then experience similar gains in performance. While there is certainly some truth to this idea, the supporting evidence is decidedly mixed. Organizations frequently struggle to implement new tools and practices and rarely experience similar gains in performance. In many industries, the performance gap between the top and middle performers remains stubbornly difficult to close. A key reason for these failures is simply that organizations are complex configurations of people and technology, and a set of tools or practices that works well in one context might not be equally effective for a major competitor — even if that competitor is located just down the street.
Best practices are “best” when they manifest an underlying behavior principle in a way that is well matched to the organization that uses them. Toyota’s famed Andon cord and the localized problem-solving it catalyzes work by capitalizing on the efficiency that comes from individual repetition and the innovation that comes with collaborative problem-solving. Conversely, agile development methods work by channeling the creativity of software engineers through frequent team meetings and customer interactions. More generally, organizations become more adaptable when they find defects and misalignments sooner. A dynamic approach to contingency, supported by triggers and checks, can open the path to creating practices that support increased agility in the work of your organization.
ABOUT THE AUTHORS
Nelson P. Repenning is the School of Management Distinguished Professor of System Dynamics and Organization Studies at the MIT Sloan School of Management in Cambridge, Massachusetts, where he currently serves as the associate dean for leadership and special projects and the faculty director of MIT’s Leadership Center. Don Kieffer is a senior lecturer in operations management at the MIT Sloan School and a founder of ShiftGear Work Design, a consulting firm based in Cambridge. James Repenning is the managing partner at ShiftGear Work Design.
REFERENCES (18)
1. A quick trip to the web reveals multiple manifestations, including “agile principles,” “enterprise agile,” “agile organizations,” and a variety of suggestions, including the charge to “apply agile development to every aspect of business.” See, for example, S.D. Goldstein, “Apply Agile Development to Every Aspect of Business,” Mint, Dec. 4, 2016,
www.livemint.com.
2. D. Leonard and R. Clough, “How GE Exorcised the Ghost of Jack Welch to Become a 124-Year-Old Startup,” Bloomberg, March 17, 2016,
www.bloomberg.com.
4. For a summary, see F.S. Glaiel, A. Moulton, and S.E. Madnick, “Agile Project Dynamics: A System Dynamics Investigation of Agile Software Development Methods,” Massachusetts Institute of Technology, Engineering Systems Division working paper, October 2014, available at
http://dspace.mit.edu.
5. See C.J. Stettina and J. Hörz, “Agile Portfolio Management: An Empirical Perspective on the Practice in Use,” International Journal of Project Management 33, no. 1 (January 2015): 140-152; J. Sutherland and J.J. Sutherland, “Scrum: The Art of Doing Twice the Work in Half the Time” (New York: Crown Business, 2014); and D. West and T. Grant, “Agile Development: Mainstream Adoption Has Changed Agility,” Forrester, Jan. 20, 2010,
www.forrester.com.
6. See, for example, M.E. Moreira, “Being Agile: Your Roadmap to Successful Adoption of Agile” (New York: Apress, 2013).
7. D.K. Rigby, J. Sutherland, and H. Takeuchi, “Embracing Agile,” Harvard Business Review 94, no. 5 (May 2016): 40-50.
8. The classic descriptions of contingency theory can be found in T. Burns and G.M. Stalker, “The Management of Innovation,” rev. ed. (Oxford, U.K.: Oxford University Press, 1994) and in P.R. Lawrence and J.W. Lorsch, “Organization and Environment: Managing Differentiation and Integration,” rev. ed. (Boston: Harvard Business School Press, 1986). An updated summary can be found in several textbooks, including R.M. Burton, B. Eriksen, D.D. Håkonsson, and C.C. Snow “Organization Design: The Evolving State-of-the-Art” (New York: Springer Science+Business Media, 2006).
9. F.W. Taylor, “The Principles of Scientific Management” (New York and London: Harper & Brothers, 1911).
10. T. Brown, “Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation” (New York: HarperBusiness, 2009).
11. J. Liker, M. Hoseus, and the Center for Quality People and Organizations, “Toyota Culture: The Heart and Soul of the Toyota Way” (New York: McGraw-Hill Education, 2008).
12. See, for example, N.R. Repenning and J.D. Sterman, “Capability Traps and Self-Confirming Attribution Errors in the Dynamics of Process Improvement,” Administrative Science Quarterly 47, no. 2 (June 2002): 265-295; and N. Leveson, “A Systems Approach to Risk Management Through Leading Safety Indicators,” Reliability Engineering and System Safety 136 (April 2015): 17-34.
13. K.T. Ulrich and S.D. Eppinger, “Product Design and Development,” 6th ed. (New York: McGraw-Hill Education, 2016).
15. L.A. Perlow, “The Time Famine: Toward a Sociology of Work Time,” Administrative Science Quarterly 44, no. 1 (March 1999): 57-81.
16. See Sutherland and Sutherland, “Scrum”; and J. Kamensky, “Digging Out of the Digital Stone Age,” Government Executive, March 9, 2017,
www.govexec.com.
i. N. Epley and J. Kruger, “When What You Type Isn’t What They Read: The Perseverance of Stereotypes and Expectancies Over E-Mail,” Journal of Experimental Social Psychology 41, no. 4 (July 2005): 414-422.
ii. L. Argote and D. Epple, “Learning Curves in Manufacturing,” Science 247, no. 4945 (Feb. 23, 1990): 920-924.
