Reinventing Management: Part 4: Coordination: From bureaucracy to dynamic linking

In an earlier post entitled The Reinvention of Management: Part 1, I noted that current management practices represent a set of economic, social and political problems of the first order, which cannot be resolved by a single fix.

Instead, a whole host of business leaders and writers, including Umair Haque, John Hagel, John Seely Brown, Lang Davison, Rod Collins and Ranjay Gulati, are exploring a fundamental rethinking of the basic tenets of management. Among the most important changes being proposed are five basic shifts in management practice:

1.     The firm’s goal (a shift from inside-out to outside-in).

2.     Role of managers (a shift from controller to enabler).

3.     Mode of coordination (from hierarchical bureaucracy to dynamic linking). 

4.     Values practiced (a shift from value to values).

5.     Communications (a shift from command to conversation).

In this continuing series of posts, I explore in more detail the specific practices needed to accomplish these five shifts.

In previous posts, I have described the practices needed to achieve the shift in the firm’s goal to delighting the client and the shift in the manager’s role from controller to enabler.

In this post, I describe the practices involved in the shift in coordinating work: from hierarchical bureaucracy to dynamic linking.

Shift #3: Coordination: from bureaucracy to dynamic linking

Even the best intentions to delight clients or empower staff will be systematically subverted if the work is coordinated through hierarchical bureaucracy. Meshing the efforts of autonomous teams and a client focus while also achieving disciplined execution requires a set of measures that might be called “dynamic linking,” The method began in automotive design in Japan[1] and has been developed most fully in software development with methods known as “Agile” or “Scrum,”[2]

“Dynamic linking” means that (a) the work is done in short cycles; (b) the management sets priorities in terms of the goals of work in the cycle, based on what is known about what might delight the client; (c) decisions about how the work is to be carried out to achieve those goals are largely the responsibility of those doing the work; (d) progress is measured (to the extent possible) by direct client feedback at the end of each cycle.[3]

1.      Organize work in short cycles: As the authors of The Power of Pull point out, one proceeds “by setting things up in short, consecutive waves of effort, iterations that foster deep, trust-based relationships among the participants… Knowledge begins to flow and team begins to learn, innovate and perform better and faster.… Rather than trying to specify the activities in the processes in great detail…specify what they want to come out of the process, providing more space for individual participants to experiment, improvise and innovate.”[4]

2.      The team reports to the client, not the manager: The shift in the organization’s goal from producing goods and services to delighting clients means that the team effectively reports to the client, rather than the manager. The manager’s role is to give the team a clear line of sight to the client. Work is presented to the client or customer proxy at the end of the process of iterations, so that the team doing the work can experience the reaction. Progress is measured not by whether the boss is satisfied but rather whether value is delivered to clients. Instead of reliance on progress reports, progress is measured by only in terms of finished work—work that actually delivers value to clients at the end of a work cycle.

3.      The team estimates how much time work will take: Unlike traditional management, where managers decide how much work will be done, the team is given responsibility for estimating how much time any individual piece of work or story will take. As described in Mike Cohn’s book, Succeeding with Agile, methods involving the use of story points and planning poker can be used to measure even complex knowledge work that is inherently dynamic and unpredictable.[5]

4.      The team decides how much work it can do in an iteration: In knowledge work, the people doing the work are best placed to know what the work entails and what is involved in delivering value to clients at the end of the iteration. In order for work to get done efficiently, people must have the time to do the work that they have committed to complete. To avoid phantom work jams, new work being undertaken must be limited to match capacity. The team itself is given responsibility for determining how much work can be accomplished in an iteration.

5.      The team decides how to do the work in the iteration: Unlike traditional management,where managers decide how the work is to be done, management steps aside and draws on the talents, ingenuity, and insights of the cross-functional team to find the best way to attack the task. Managers refrain from interrupting the work during the course of an iteration.

6.      The  team measures its own performance: The team measures its own velocity and tracks the progress of its own performance. Iterations help establish the cadence of work. Every week, or fortnight, or month, something gets done. After a time, people begin to count on it. They can make plans based on a track record of delivery. The amount of work that can be accomplished in an iteration becomes apparent.

7.      Define work goals before each cycle starts: Unlike traditional management, where work begins without clarity as to what completion will entail, radical management entails getting crystal clear on what work is to be attempted in each iteration and then getting out of the way to let the team get on with it.

8.      Define work goals through user stories: Unlike traditional management where the goal is defined in terms of the abstract requirements such as the production of goods or services, the goal of work aimed at delighting clients is a client experience. This is normally captured in the form of user stories.[6] As Mike Cohn explains in User Stories Explained, the user story has a standard form: “As a <type of user>, I want <some goal> so that <some reason>. Putting the story in the first person is important, because it draws the team into imagining the client’s situation. The user story is as the beginning, not the end, of a conversation: The written version of the user story is less important than the conversations surrounding the story. It enables the people doing the work to get inside the mind of clients and focus on what might delight them.

9.      Systematically remove impediments: In the daily stand-up meetings of a self-organizing team, each member systematically answers three questions: What did I do yesterday? What am I going to do today?  What impediments are getting in the way of what we need to accomplish? Often the impediments facing any team will exist not only in the team itself, but also in the context surrounding the team, particularly management actions or the organization’s policies and practices. The willingness of management to encourage the identification of such impediments and take action to remove them is one of the make-or-break aspects of dynamic linking.

10.   Conduct retrospective reviews: Digesting what has been learned in the iteration and how the next iteration can be improved is crucial to the continuous improvement needed to delight clients. At the end of each iteration, the team reviews what has been learned, including impediments that have been identified in the course of the iteration, and decides what improvements are to be explored in the coming iteration.

To learn more:

To learn more about reinventing management, read the whole series:

• Reinventing Management: Part 1: Overview
• Reinventing Management: Part 2: Delighting the client
• Reinventing Management: Part 3: From controller to enabler
• This post: Part 4: Coordination: From bureaucracy to dynamic linking
• Reinventing Management: Part 5: From value to values
• Part 6: From command to conversation
• Coming soon: Implementing the transition

And read books such as The Power of Pull by John Hagel, John Seely Brown and Lang Davison, or Reorganize for Resilience by Ranjay Gulati, or The New Capitalist Manifesto by Umair Haque, or Leadership in a Wiki World by Rod Collins, and my own book, The Leader's Guide to Radical Management: Reinventing the Workplace for the 21st Century.

---

[1] Takeuchi, H., and I. Nonaka. “The New New Product Development Game.” Harvard Business Review, 1986, 64(1), 137–146.

[2] Cohn, M. Succeeding with Agile: Software Development Using Scrum. Upper Saddle River, N.J.: Addison-Wesley, 2004.

[3] The method has been particularly successful in helping reconcile issues of quantity vs. quality, by letting those who understand the requirements of the work best make the decision as to how much work to tackle. In most cases, the people who know best are the knowledge workers themselves, not the managers. Even where the managers do know more or better, imposing a decision from above is usually counterproductive, and leads to “technical debt” i.e. the hidden buildup of unresolved technical issues that eventually have to be fixed, often at great cost.

[4] Hagel, J. et al: The Power of Pull, pp. 195-196.

[5] Cohn, M. Succeeding with Agile: Software Development Using Scrum. Upper Saddle River, N.J.: Addison-Wesley, 2004.

[6] Cohn, M. User Stories Applied: For Agile Software Development. Upper Saddle River, N.J.: Addison-Wesley, 2004.

Comments

[Dave Duggal]

Great post Steve. Coordination is the new means of execution. The dynamic interaction of loosely-coupled resources self-organizing to meet a goal guided by values. In addition to the recent works of the authors you cite, I'd add Malone's Theory of Coordination and Beer's Viable System Model. I'm sure these seminal works influenced the others.

[Francesco]

Can we start by setting up the appropriate environment?

http://thoughtoogle-en.blogspot.com/2011/08/how-to-create-free-project-environment.html

[B.McNeill]

Steve, I enjoyed one of your presentations given at a mgt. retreat for my organization. I said then and, I believe that it bears saying here that there's a war going on in most organizations between the "engineers" and the "artists." The engineers push ISO900x, ISO27001, ISO2000/ITIL practices, PMBOK best-practices, and live by cost-acctg. metrics.

These practices are designed to eliminate defects and errors of ommission, but they also engineer out all but the most determined project champion. My teams and I spend twice as much time on compliance activities as we do on product development.

Eventually the life is snuffed out of any software development or process redesign when these practices/practices dominate the product development lifecycle.

[Jimmy Choo Chaussures]

I follow you VIA GFC and I love your blog!