Why Collaboration is Broken: Becoming Anti-Fragile Through Design

This is an except from the new report: Why Collaboration is Broken.

In Nicolas Nasim Taleb’s book, Anti-Fragile, the noted decision-making author describes how some things in nature and engineering benefit from chaos and stress. A glass does not benefit from stress. Place enough stress on it, and it shatters. When people exercise, that places stress on muscles, and the muscles grow in strength. “Anti-Fragile” is an important concept in collaboration because there are many places that organizations introduce fragility into their collaboration environments, and therefore, into the organization itself.

It might seem that it would be difficult for the author of a book about designing work experiences to reconcile design with chaos. When describing the components of balance in a work experience, it is critical to include all forms of tension, which is how I describe the way to identify the components. Look for the tension, and those ideas and concepts will be the items that require balance. A typical tension is the one that exists between time and cost. Increase the time and the cost goes up. Force a decrease in cost, and you may not invest enough time to create a quality product. You then add a new component, quality, which also must balance with cost. As artist Alexander Calder demonstrates admirably in his sculptures, balance need not be binary. It is possible to balance many things around a single point.

So the anti-fragile nature of collaboration, in a project, comes from the people and the network associated with the project, not from the software. That being said, the anti-fragile nature of project management, let’s call it innovation or just the emergence of better ideas, can’t arise if the collaboration environment introduces fragility. That is where design comes in.

So in exploring balance for a work experience, fragile and anti-fragile are balancing components. Take a project management system as an example. Just using a scheduling tool would be fragile. A project is about a lot more than dates and times, PERT networks and Gantt charts. Projects also require communication. An anti-fragile system would include ways to communicate all of the key information about the project. Management by Design defines two primary types of communication: rhythm and motion and perceptibility. Rhythm and motion seek to align work in a bi-directional way, in this case, project work, with the strategy of the organization. Strategy defines the rhythm and the motion of the organization. This is can also be thought of as up-and-down communication.

Perceptibility covers horizontal communication. It is called perceptibility because it deals with how others perceive the work being done. Perceptibility asks that all work maintain a status in terms of who, what, where, when, why and how, and make this available to other teams. Perceptibility not only covers the design of communication, but also auxiliary information flows, such as knowledge management, which typically focuses on the “how” of a project. Knowledge management as a feature of work, however, would be a different, but intersecting work experience.

So what does all of this have to do with being anti-fragile? A project management system, by itself, is fragile because it doesn’t include enough communication features. Now, as pointed out in other findings in this report, the project management vendor may well start including blogs, social media, wikis or any other types of relatively easy to adhere communication tools to its core project management features because they have become easy to do include. The vendor may even embed those communication tools into the product at the project task level so that people can collaborate and communicate about a particular task. That is all well and good on the surface, but let’s also say this company managing a project uses an enterprise social networking system—and it doesn’t matter which one. What does matter is that the social networking system exists independently of the project management system and does not integrate with it. A system where a vendor has attempted to make their system less fragile, more robust, has inadvertently introduced fragility because they didn’t consider that people would need to make choices about where they communicate. As soon as multiple features appear in a collaboration experience, the system becomes more fragile and less productive because people must choose which system to use to communicate what to whom, and they may decide, given the critical nature of some communication, to duplicate it across communication channels, which also decreases productivity. They also may choose not to integrate their communications, leading to fragmented communications which quickly devolve into missing information and under-informed decisions.

Taleb stresses in Anti-Fragile that robustness isn’t the same as anti-fragile. Robustness and resilience aren’t enough. Those words mean survival or repair to a previous state. Anti-fragile things grow and thrive on stress—they become better, stronger.

So the anti-fragile nature of collaboration, in a project, comes from the people and the network associated with the project, not from the software. That being said, the anti-fragile nature of project management, let’s call it innovation or just the emergence of better ideas, can’t arise if the collaboration environment introduces fragility. That is where design comes in. Rather than over design for a function to the point that there are no degrees of freedom, collaboration work experience designers must design for fluidity, so that as much as possible, the collaboration environment stays out of the way of those using it. As soon as choice is introduced, be it choice of social networking software or more than one way to make a telephone call, fragility re-emerges. That leads to another set of design components: fragility versus redundancy. Some would argue that redundancy supports resilience or robustness, because if a social networking system goes down for instance, people can shift to another system, or fall back on e-mail, and still communicate. At one level that may be true. But work experience design attempts to reconcile the micro of work execution, with the macro of integrated business outcomes. If each time a person wants to communicate, they have to make a choice about which system to use, then the system isn’t robust at the micro-level. The micro-level should specify, that for project communications, this is the system of choice, allowing people then to concentrate on what they say instead of starting each communication act with a choice about which tool to use. This then places the stress on the person, who is already anti-fragile, a person who can, in light of that stress, suggest alternatives and innovations. The fluidity of the collaboration experience increases access to the intellectual assets of the people in an organization, whereas the complexity of multiple collaboration tools that do the same thing decrease intellectual cycles.

Those really applying Management by Design principles will find that the macro versus micro issue isn’t just a single layer. If you look at all work experiences as a single layer, it would hold that you could, for instance, apply a different file sharing and synchronization technology to different work experiences without conflict. That would be true, if those work experiences existed in complete isolation. But they do not. That is part of the rhythm and motion feature of the methodology—the feature that forces reconciliation with business outcomes. IT, for instance, includes a work experience around managing the IT portfolio. In that work experience, deploying a multitude of file sharing and synchronization tools doesn’t make sense, for a number of reasons, chief among them, access control to critical company information, which may also end up on the list of components for project management, especially if a project includes partners and customers. The IT design is part of the organization’s strategy, and therefore, influences all work experiences that employ information technology. Access control to information will also likely show up on the balancing tensions list for the project management experience, which further reinforces the relationships. Applying design asks that people think holistically while also paying attention to the details of tasks, including communications.

Management by Design therefore helps organizations facilitate anti-fragile behaviors, critical to inventive collaborations by ensuring that policies and practices, technology and space, don’t act as inhibitors to natural anti-fragile elements in the system, like people. Note in collaboration, design should be applied in most cases, not to add new overlays to work that must be accomplished, but rather to invoke simplification of practice by employing technology, which is as much a design choice as creating something entirely new.

To download a complete copy of Why Collaboration is Broken click here: