"The Rules of Collaboration: A Guide to Collaborating When You Hadn't Planned It From the Start".

(Area: Collaboration)

(Reading Material "Introductory Course: Introduction to Collaboration" & "Advanced Course: Collaboration: Collaborative Business Models and Strategy in the New Era", Hugo Céspedes A.)

Not only do pandemics generate changes in the operating rules, but the context in general, added to the needs and problems, over time they also generate changes in the way of carrying out value creation processes and/or procedures in its full spectrum. I have already said in previous posts that the Status Quo does not help adaptation, even "the rules help to change the rules".

Also in previous posts, I have touched on the topic of "Collaboration", "Collective Intelligence", "Communities, Collaboration and Purpose", "Collaboration Management", "Measurement of Collaboration for Its Management", "Leadership for Collaboration", "How We Stablish Collaborative Networks", among others. However, on this occasion I want to start giving tips (as I will do with the "resources" that I will make available to you this year on my new website that I am preparing) on how the hand is coming in relation to Collaboration, and how we should get used to flexibility for adaptation as the basis of the Collaboration Strategy.

Already in 2005 Philips Evans & Bob Wolf envisioned that "corporate leaders looking for growth, learning and innovation could find the answer in surprising places" (cases like Linux, the Toyota Production System, among others).

Validation Cases.

For example, "Linux" is the creation of a necessary, self-organizing community of thousands of volunteer programmers and companies. Most leaders would sell their grandmothers for workforces that would collaborate as efficiently, seamlessly, and creatively as the self-styled Linux "hackers". Linux is a free/open source software community that developed and continues to refine the operating system and other open source programs.

For its part, "Toyota" is a company like any other, ranked among the best performing organizations in the world. The automaker has long been a leader in quality and lean production, and the success of the hybrid Prius has established its reputation as an innovator. "Toyota's management methods resemble, in several fundamental respects, the workings of the Linux community; the Toyota Production System (TPS) owes some of its renowned capability to a hybrid between an open hierarchy". In fact, Toyota itself is evolving into a hybrid between a conventional hierarchy and a Linux-like self-organizing network.

Linux Case: In December 2003, around midnight, Andrea Barisani, system administrator of the physics department of the University of Trieste, discovered that an attacker had attacked the Gentoo Linux server of his institution. He traced the breach to a vulnerability in the Linux kernel and another in rsync, a file transfer mechanism that automatically replicates data between computers. "This was a serious attack: any penetration of rsync could compromise files on thousands of servers around the world".

Barisani woke up some colleagues, who put him in touch with Mike Warfield, a principal investigator at Internet Security Systems in Atlanta, and Andrew “Tridge” Tridgell, a well-known Linux programmer in Australia whose doctoral thesis was based on rsync. They directed Barisani's message (anonymous for security reasons) to another Australian, Martin Pool, who worked for Hewlett-Packard in Canberra and had been a leader in the development of rsync. Although Pool was no longer responsible for rsync (no one was), he immediately phoned and emailed, first questioning Warfield and Dave Dykstra (another early contributor to rsync's development, who was based in California) about the vulnerabilities and then helped Barisani trace the flaw line by line.

By morning Trieste time, Pool and Barisani had found the precise location of the breach. Pool contacted the current rsync development group, while Barisani connected with the loose affiliation of hobbyists and professionals who package Gentoo Linux, and posted an early warning on the Gentoo site. Pool and Paul “Rusty” Russell (a fellow from Canberran who works for IBM) then worked through the Australian night to write a patch, and within five hours Gentoo user-developers began testing the first version. Meanwhile, Tridge crafted a description of the vulnerability and its fix, making sure (at Pool's urging) to credit Barisani and Warfield for their behind-the-scenes efforts. On Thursday afternoon Canberra time, the announcement and the patch were posted on the rsync website and thus distributed to Linux users worldwide.

A few days after the emergency, having regained his sleep, Barisani volunteered to collaborate with Warfield in creating a system of deliberately vulnerable servers to lure the system cracker into revealing himself.

"No one authorized or directed this effort". No one, amateur or professional, was paid to participate or would have been penalized for not doing so. Nobody's job depended on stopping the attack. No one was silent for fear of legal responsibility. In fact, the user community at large was kept informed of all developments. Yet despite the need for maximum security, a group of about 20 people, almost none of whom knew each other, employed by a dozen different companies, living in so many time zones and straying far from the descriptions of their positions, they achieved it in about 29 hours. which could have taken colleagues in adjacent cubicles weeks or months.

It's tempting to dismiss this as an example of hacking weirdness: admirable, yes, but nothing to do with real business. Consider, however, another story.

Toyota Case: At 4:18 am a fire broke out at the Kariya No. 1 plant of Aisin Seiki, a major Japanese auto parts supplier. Within minutes, the building and virtually all of the specialized machinery within it were destroyed. Kariya Number 1 produces 99% of the brake fluid proportioning valves, or "P valves," for Toyota's Japanese operations, parts required for every vehicle Toyota makes. Toyota, true to its "Just in Time" principles, had less than a day's worth of inventory. Toyota's Japanese production system faced the prospect of a total shutdown for months.

Within hours, Aisin engineers met with their counterparts from Toyota and other top-tier Toyota suppliers. The group agreed to improvise as much of the production as possible. As word spread through the provider network, some Tier Twos volunteered for leadership roles. Aisin sent valve drawings to any supplier who requested them and distributed intact salvageable tooling, raw materials and work-in-process. Aisin and Toyota engineers helped set up production lines at 62 locations: unused machine shops, Toyota's own prototyping shop, even a Brother-owned sewing machine facility. Denso, Toyota's largest supplier, volunteered to handle the complicated logistics of shipping valves to Aisin for inspection and then to Toyota's stalled assembly lines.

Everyone was shocked when a small second-tier supplier of welding electrodes, Kyoritsu Sangyo, was the first to deliver production-quality valves to Toyota – 1,000 of them, just 85 hours after the fire. Others quickly followed, and Toyota began reopening assembly lines on Wednesday. Approximately two weeks after the outage, the entire supply chain returned to full production. Six months later, Aisin "distributed an emergency response guide containing lessons learned from the experience and recommended procedures for responding to such situations in the future".

No individual or organization planned this effort: rather, people and companies stepped in where they could. The competitors collaborated. No one at the time was paid to contribute. Months later, Aisin "compensated the other companies for the direct costs of the valves they had delivered. Toyota gave each tier-one supplier a fee based on actual sales to the automaker, encouraging, but not requiring, them to make Same with your own tier two providers.

Learning Gained to Collaborate.

In Collaboration events such as the one presented, individuals meet and assume roles without a plan or an established command and control structure (when they have not directly proposed it, since these are fortuitous events of Collaborative learning). Extended human networks can be organized in a matter of hours and avert a catastrophe or threat. People, teams and companies can work together without legal contracts or negotiated bias. And despite the lack of any authoritarian stick or financial carrot, those people can work like crazy to solve the problem. In this way, people unknowingly become virtuous practitioners of new working principles that produce lower-cost, energized equipment. They are not alone either.

Toyota and Linux are quite similar in the way that it combines key features of both markets and hierarchies. Like marketplaces, the Toyota and Linux communities can self-organize, but unlike marketplaces, "they don't use cash or contracts at critical times". Like hierarchies, Toyota and Linux enjoy "low transaction costs," but unlike hierarchies, "members can belong to many different organizations—or none at all—and are not constrained by specific, predefined roles and responsibilities". Furthermore, like hierarchies, "members share a Common Purpose, but that Purpose emanates from self-motivation rather than from the incentives or sanctions that hierarchies generally impose". In these respects, both organizations represent the best of both worlds. An analysis of their common characteristics suggests how high-performing organizations remain productive and inventive, even under strenuous conditions.

Few communities seem more different than the world of Hackers and the disciplined world of Japanese automotive engineering. But the parallels between these stories are striking. In both cases, individuals met and assumed roles without a plan or established command and control structure.

An extended human network is organized in hours and can counter a threat. People, teams and companies work together without legal contracts or negotiated payments. And despite the lack of any authoritarian stick or financial carrot, those people worked like crazy to solve the problem.

Obviously, these were emergency responses. But a look at the day-to-day operations of the Linux community and the Toyota Production System reveals that those responses were simply intensifications of the way people were already working.

Tips to Collaborate in these Cases.

While market rules refer to "Cash" and "Contracts", and hierarchy rules refer to "Authority" and "Responsibility"; at the core of the Linux and Toyota Communities are rules on three completely different topics: "Individuals and Small Groups Working Together"; "How and to what extent do they communicate"; and "How Leaders Lead Toward a Common Goal".

• Common Work Discipline: The Communities presented above are made up of engineers, so members have the same skills as their colleagues and speak the same language. But these groups are much more disciplined and rigorous in their approach to work than other engineering communities. Both emphasize "granularity" (paying attention to small details), weeding out problems at the source, and trimming anything that seems like excess, be it work, code, or material. Linux folks, for example, share an obsession with writing minimal code, compiling each day's output before moving on to the next, and rooting out programming flaws as they go. For their part, TPS engineers are relentless in applying short cycles of trial and error, focusing on one thing at a time, and looking at actual processes. Both groups take those principles to apparent extremes. Linux programmers reduce code for elegance rather than computational efficiency. Toyota engineers reject Lexus hood embossing, though flawless and completely off-spec, because the sparkle to their eyes lacks lustre.
• Granular and Generalized Communication: In both Communities of their respective organizations, information about problems and solutions is shared widely, frequently, and in small increments. In the case of Linux "hackers", it is not between individuals, but through postings on search and open list servers. Anyone can review Listery's code version history and discussions, not executive summaries or summaries, but the raw activity itself, where every code contribution is tested by dozens of people, where every hacker reconciles their efforts almost continuously . If someone were to work in isolation for six months on even the most brilliant contribution, it would probably be rejected for lack of compatibility with the efforts of others. At Toyota, continuous improvement also encompasses a thousand small collaborations. Toyota engineers are famous for "asking why five times" to follow a chain of causes and effects to the root of a problem. This is not some bland cliché about deep thinking. Quite the contrary. In fact, the merit of the precept is precisely in its superficiality. Saying that C causes B and D causes C quickly leads you into a new domain, probably someone else's. So instead of inventing complex solutions within their own domains, engineers must search for simple solutions beyond them. "Doing your whys," as the practice is known, isn't about depth at all, it's about breadth. In this context, as with Linux, Toyota's communication protocols enforce this discipline. Each meeting addresses only one topic and leads to a specific outcome, even if that means the same people meet more than once a day. The lessons are written in a standard format on a single sheet of A3 paper. Everyone learns how to write these reports, right down to the fold of the document that shows the main points and hides the details.
• Leaders as Connectors: At all levels, leaders from both organizations perform three critical roles: a) Educate community members (often by example) in the disciplines just described; b) Articulate clear and simple goals for each project based on its strategic vision; c) Connect people, for the merit of being very well connected themselves. That said, it is necessary to clarify that "no community treats leadership as a discipline distinct from doing." Rather "the credibility and authority of leaders is derived from their competence as practitioners." In communities, leading is not treated as a separate discipline from "doing." Rather, the authority of the leaders derives from their competence as "practitioners". Occasionally, leaders have to perform traditional acts of leadership, such as arbitrating conflicts. This, however, is the exception and looks like a minor system glitch. The default assumption is that, as far as possible, managers do not manage in a traditional sense: the human network manages itself. In Linux, development priorities are not decided by a CEO, but by thousands of hackers who vote with their feet to choose what to work on. This kind of radical self-management doesn't happen at Toyota, except in emergency situations. But even in day-to-day operations, a single production worker seeing a quality issue can stop the line, and project teams have wide latitude to leverage resources, make purchasing decisions, and pursue priorities they set for themselves.

Building Vibrant Human Networks.

Organizations that are laying the groundwork for high-performance Collaboration should follow these principles:

1. Implement Pervasive Collaborative Technology: Keep it simple and open: "little pieces loosely put together," is Cluetrain Manifesto co-author David Weinberger's happy phrase. The tools must work together through standards and be as compatible as possible with those of the rest of the world. Think options, not integration, adaptability, not static efficiency.
2. Keep Work Visible: Unless there's a very good reason not to, let everyone see everyone's real work. Let people learn to filter and classify for themselves. Do not abstract, summarize or channel. Forage is good. Make it available to everyone.
3. Build Trusted Communities: When people trust each other, they are more likely to collaborate freely and productively. When people trust their organizations, they are more likely to give up now in anticipation of a future reward. And when organizations trust each other, they are more likely to share intellectual property without drowning in legal issues.
4. Think Modular: Reengineering was about thinking linearly (managing the process end-to-end instead of discrete functions). "Modularity" is the opposite, that is, "sacrificing static efficiency for the recombinant value of options." Think modular equipment as well as processes. The finer the better.
5. Encourage Teamwork: Celebrate the sacrifices teams make for the company as a whole, including customers and vendors. Dismantle individualized performance metrics and rewards that pit people against each other. Cheap transactions among the many fuel innovation more than expensive incentives directed at the few. Reward the group, and the group will reward you.

Infrastructure Components for this Type of Collaboration:

At the heart of Linux and the Toyota Production System is a set of work, communication and leadership practices that contributes to a new way of Collaboration is also based on "two infrastructure components", that is, a shared set of universally available knowledge and tools to move knowledge.

Common Intellectual Property: The License under which Linux is released requires all distributors to make their code freely available so others can freely modify it. This viral principle prevents code from being stored in proprietary products. That transparency, in turn, breaks down the distinction between producer and user. Sophisticated "Client" like Andrea Barsani is actually a User-Developer, fixing bugs and adding features for his own benefit, and then sharing those improvements with everyone else. Such a function is impossible when proprietary code is licensed from a commercial vendor. Similarly Troyota's Supply Chain is based on the principle that while product knowledge (such as a blueprint) is someone's intellectual property, process knowledge is shared. That breaks down some distinctions between companies. Suppliers are generally exclusive to a single OEM (Original Equipment Manufacturer), so the collective benefit of that shared information remains within the Toyota supply chain. Even in the United States, where the Toyota is just one of several customers for most blue-chip companies, the automaker does the same thing through its Bluegrass Automobile Manufacturers Association, which spreads best practices to all members.

Simple and Omnipresent Work: Although information is the lifeblood of the Linux and TPS communities, their circulation systems are surprisingly rudimentary. Linux developers produce state-of-the-art software using communication technology no more sophisticated than email and listservs, but everyone uses that mundane tool. In fact, the value placed on the university is so great that plain text, rather than formatted, emails are the norm, ensuring that messages will appear exactly the same to all recipients. Toyota, whose products are also state-of-the-art, also prefers simple and ubiquitous internal technology. An empty Kanban container indicates the need to replenish parts; a piece of tape on the assembly line floor assigns completion times to tasks on a moving vehicle. Quality control problems on the assembly line are announced through pagers and television monitors. Everyone gets the alert, even Ray Tanguay, head of Toyota Canada, is called every time a fault is found on the latest Lexus shipment at the dock in Long Beach, California, or at a service bay anywhere in North America.

Trust and Applause.

These extremely rich and flexible Collaborations have positive psychological consequences for the participants and powerful competitive consequences for their organizations. Those consequences are rich common knowledge, "the ability to organize teams modularly, an ability to organize teams modularly, extraordinary motivation, and high levels of trust.

• Semantic Recognition: Rigorous work discipline, intellectual property, and constant sharing combine to distribute knowledge widely and relatively evenly across human networks. That knowledge includes not only the formal and semantically rich information about content and process that is the currency of creative collaboration. What do we mean by the gloss of a patterned body that doesn't have enough gloss? This kind of unanswerable question is continually discussed and resolved in thousands of small team collaborations. The resulting nuanced thinking and richer common vocabulary on such matters are fed back into the body of knowledge, where they are available for refinement by the entire community.
• Modular Equipment: Modularity "is a design principle by which a complex process or product is divided into simple parts connected by standard rules." In modular team arrangements, each team focuses on small, simple tasks that together form a larger whole. Modularity allows an organization to run multiple parallel experiments, making many small bets instead of a few big ones. Toyota's suppliers organized in this way to make "P-valves," operating partly by management but mostly as volunteers to do what they each knew best. The Gentoo group, the security experts at Tridge, and the rsync alumni circle at Pool were all pre-existing, overlapping modules that mixed and matched roles as the emergency required. Thus, when Philips Evans & Bob Wolf mapped the daily "collaboration patterns" throughout the Linux kernel development effort, they found that such modular arrangements are pervasive and, to some extent, nest within each other. This creates a kind of dynamic org chart, an org chart that no one wrote but that allows the community to expand and embrace without collapsing into chaos.
• Intrinsic Motivation: The Linux and TPS communities decouple money from key transactions. However, despite weak financial incentives, they have a higher level of motivation than is found in conventional settings. Psychologists have consistently found that "monetary carrots and accountability sticks motivate people to perform limited and specific tasks, but generally discourage people from going further". "The developer's personal reputation is attached to every release" Linus Torvalds explained to technology columnist Robert Cringely in 1998. "If you are creating something to give to the world, something that represents your philosophy of computing to millions of users, you will always make it the best product you can". "Monetary carrots and accountability sticks motivate people to perform limited and specific tasks. Management and applause are much more effective stimulants of behavior above and beyond". On the other hand, psychologists also emphasize the motivational importance of autonomy. Linux developers decide for themselves how and where to contribute, and enjoy the satisfaction of producing something whose quality is not defined by a marketing department or accountants, but by their own exacting standards. MIT's Bob Wolf and Karin Lakhan surveyed more than 800 user-developers, and more than half said that their open source work is the most valuable and creative endeavor of their professional lives. For its part, the Toyota Production System does not offer such extreme autonomy, of course, and employees do not work for free. But compared to their counterparts in the rest of the auto industry, TPS workers enjoy fewer checks, more encouragement of individual initiative, fewer metrics tied to individual performance, and more applause from their peers. Professional and corporate pride, not Toyota fees, was the reward for the Kyoritsu Sangyo team when they delivered the first batch of "P-valves". That same pride is felt by a junior assembly line worker when peers trust him to experiment with process improvements and shut down the line if something goes wrong.
• High Levels of Trust: When information flows freely, reputation, rather than reciprocity, becomes the basis of trust. Operating under constant scrutiny, which is challenging but not hostile, workers know that their reputations are at risk and that serves as a guarantee of good behavior, the equivalent of contracts in a market or audits in a hierarchy. Hence the obsession in the Linux Community with acknowledging code contributions and including personal email addresses in Listerys comment fields. Hence the generous public credit given to Barisani and Warfield. Hence the collective celebration of the heroic efforts of Kyoritsu Sangyo. Now, with a reputation at stake, people are less likely to act opportunistically. With the same information available to everyone, there is less chance of one party taking advantage of another's ignorance. And with a common vocabulary and way of working, there are fewer misunderstandings. Those factors drive trust, the fundamental social capital of these communities. Trust would matter less if there was no cost to exit these networks or if the transactions were of radically different sizes (because that would tempt people or companies to break the rules when a big opportunity arose). But in both the Linux and Toyota communities, entry into the inner circle is a hard-earned privilege, and both operate on many small exchanges. So, of course, "where trust is the currency, reputation is a source of power". In a "dispersed network", like most markets and hierarchies, power derives from controlling or brokering the flow of information and thus often restricting it. However, in a "dense network", information simply flows around the potential bottleneck. In those circumstances, there is more power in being a source of information than a sink of information. Consequently, "people are motivated to maximize both the visibility of their work and their connections with those who are widely connected". That, in turn, feeds the information density of the network.

Labor Economies: Cheap Transactions and Lots of Them.

So far we have been discussing the content of the work. But the TPS and Linux models also change the Labor Economics, by reducing transaction costs. Low transaction costs make it profitable for organizations to conduct more and smaller transactions, both internal and external, thereby increasing the pace and flexibility typical of high-performing organizations.

Exploitation of the Neglected 80%: The famous Pareto Principle, dictates that "companies derive 80% of their value from only 20% of their products, customers, or ideas". Due to high transaction costs, the long tail of that curve, that 80% of generators of uncertain value, cannot be explored. So, in the name of company focus, the queue is cut off, segmented, or re-engineered out of existence. Potentially profitable Innovations die with it. On the other hand, "organizations that reduce transaction costs" can accommodate the 80% rejected. They can respond to weak market signals, tap into small segments, and experiment with unlikely technology combinations. They can make a hundred small bets instead of a few big ones. For example:

"Detroit viewed hybrid vehicles as an uninteresting intermediate product: U.S. auto executives preferred hitherto incomplete research into fuel cell technology. Meanwhile, Toyota was building the Prius. The hybrid is now in its second generation and Toyota expected to sell 300,000 worldwide that year (2005).Low transaction costs and Toyota's penchant for small-scale collaborations helped it keep 80 discrete options for the hybrid powertrain open until just six months before deliver a final design.Conventional automakers would have tended to freeze these design variables at hand two years earlier.

It is in the interstices of the human web, rather than in the minds of a few child prodigies, that most of the real innovations are made. Thus, with the transaction costs that restrict Innovation by restricting the opportunities to share different and conflicting ideas, skills and prejudices.

"The people of Detroit are much more talented than the people of Toyota," says Toyota president Fujio Cho, with excessive modesty. "But we take moderately talented people and make them work as spectacular teams". The network, in other words, is the Innovator.

The classic sources of transaction costs are "mutual vulnerability to uncertainty, conflicting interests, and unequal access to information". We spend cash on trading, monitoring, and restitution to reduce those imperfections. Both markets and hierarchies incur transaction costs (although hierarchies exist to economize on them, as Ronald Case and Oliver Williamson have argued). It is estimated that in the year 2000, cash transaction costs alone accounted for more than half of US non-government GDP. They spent more money negotiating and enforcing transactions than fulfilling them.

In the Toyota and Linux communities, agreements are enforced not by the sanction of a legal contract, nor by the authority of a hehe, but "by mutual trust, which drastically reduces transaction costs". This is not new, teams of people everywhere in the conventional workplace operate on the basis of trust.

What is new is "how widely trust can be extended, even to people who do not know each other, or even to those who have conflicting interests". Asin entrusted his rival suppliers with P-valve planes. The rsync hackers exchanged sensitive information with people they had never met. Toyota's component suppliers share knowledge of the process daily, trusting that Toyota will not use it to lower prices. Linux hackers rely on each other to make simultaneous, unguarded amendments to the code base.

In addition, having ownership in common - as certain types of Intellectual Property are held within these communities - reduces the monetary stakes between co-owners. Transaction costs fall because there are simply hands to deal with. In the Linux community, transaction costs are close to zero. Hewlett-Packard paid Martin Pool to be a Linux engineer, but it doesn't follow that HP had to pay on the margin for Pool's nightly rsync jobs. In the Toyota community, transaction costs, while not zero, have been dramatically reduced. When the Asin Selki plant was destroyed, Toyota and its suppliers did not sue each other, nor did they cobble together emergency supply contracts. They simply continued with each other, trusting that fair restitution would eventually be made. Jeffrey Dyer, a professor of strategy at Bringham Young University, estimates that "transaction costs between Toyota and its first-tier suppliers are only one-eighth those of General Motors", a disparity he attributes to differing levels of trust.

A Few Words in Closing.

Philips Evans & Bob Wolf argue that "if you put all these things together, you have a virtuous circle. A dense, self-organizing network creates the conditions for large-scale trust. Large-scale trust lowers transaction costs. Low transaction costs , in turn, allow for many small transactions that create a self-organizing network that is cumulatively deepening".

Once "the system reaches critical mass, it feeds back. The larger the system, the more widely knowledge, language and work style are shared. The greater the Reputational Capital of individuals, the stronger the applause and the stronger the motivation. The success of Linux is evidence of the power of that virtuous circle. The success of Toyota is evidence that it is also powerful in conventional companies that maximize profits".

The Linux Community and the Toyota Production System are surprisingly different. The fact that they accomplish so much in such similar ways points to some principles you can follow:

• The Discipline of science is surprisingly adaptable to the organization of work, and even interoperable.
• In some circumstances, trust is a viable substitute for market contracts and hierarchical authority, not only in small teams but also in very large communities.
• In supply chains, organizations that can substitute trust for contracts gain more from Collaboration than they lose in bargaining power.
• Low transaction costs buy more innovation than high monetary incentives.

These principles satisfy companies' need for growth and innovation in ways that traditional organizational models do not. Perhaps the efficiency of these Collaborations suggests the eventual rise of something entirely new: No Markets, No Hierarchy. But a powerful combination of both and a network society signature.

(Note: For those students of the course, go back to the course and follow the instructions to assimilate the knowledge delivered).

Fuente: "Collaboration Rules", Phillip Evans & Bob Wolf, Harvard Business Review.