Successful communication depends on some level of shared context. Speaking the same language is a start. This leads to the next level, where you have to find that shared frame of reference that enables a conversation about sport, politics, or engineering. But imagine a telephone call to Mars, answered by a Martian. Evidently, in some environments, you may have to go way back to first principles to build up the set of shared concepts and assumptions you need to make even simple communication work.

It was during a briefing by some senior European Commission officials that I was reminded of this. The Commission are launching "Framework Programme 6". This devotes serious money (about 16 billion dollars) to R&D. When it came to the parts of the briefing on information technology (which will get a little under 4 billion dollars), the collaboration word kept coming up. For the success of their communication to me, I needed to share the context - "collaboration is a good thing", and, self-evidently, "collaboration is the right way to push back the frontiers of technology".

But do I believe this?

On the one hand, neither Napoleon nor Gengis Khan felt the need to collaborate with anyone. They preferred to offer (well, enforce, actually) a clear (some would say harsh) frame of reference. Their armies operated within this well defined structure. The result certainly pushed back frontiers. Is it self-evidently wrong to consider this approach to pushing back the frontiers of technology?

For example, there have been advocates of the 'competitive' approach to research and development. The idea is that if you have deep enough pockets, then you should set up two or more competing teams. You must tell them the criteria against which their designs will be judged. You must make sure they understand the fact that only the winning team's proposals will move forward, the rest will be discarded. The whole process is an in-house simulation of the ruthless selections the external market will make.

In such a 'survival of the fittest' environment (so advocates say), you are tapping into the very essence of human motivation, honed over millions of years as the only successful basis for evolution. Not only that, but, compared to asking your design teams to collaborate, you are also avoiding the risks of design by committee, and maximizing the chance of a coherent, integrated design.

On the other hand, there is the case for collaboration. As products get more complex, it is impossible for an individual, or small team, to be able to offer the specialist, up-to-date skills and knowledge needed to make every product element world class. Instead, it is necessary to assemble a group of collaborating specialists, or specialist teams. Make each specialist, or specialist team, responsible for a well-defined task or product element. Help them work together with the right blend of 'good fences make good neighbours' strategies running in parallel with collaboration strategies to encourage and require communication, co-operation and co-ordination.

This type of collaborative environment brings an associated business issue into play. If you become capable of getting things done through external collaborations, you are better placed to develop an in-house focus on the set of core competencies that are key to your business. This is not only good for your own performance, but the related outsourcing and partnering tends to reduce fixed costs. Since reduction of fixed costs is a classic financial strategy for dealing with uncertainty, a collaborative approach will probably receive perhaps unexpected support from the CFO.

In a collaborative design project, space layout, design review, clear allocation of design authority, and so on, all have their part to play. Online tools, such as shared workspaces, and support for version and change management, may facilitate management of the project, but these tools do not, in themselves, guarantee success. They are exactly the tools that the committee assigned to design the horse would use to create the carefully documented blueprint for a camel.

By removing the Gengis Khan approach from a project, you are increasing the project's dependency on the existence of a shared context for communication. The ex-aerospace engineering team based in California may indeed be the world experts on the structural use of resins and glues. But do they understand what it means to manufacture in volume using production facilities in low cost countries, in an environment that requires local installation by entry level technicians? And will your globalized production engineers appreciate the leap forward that some new structural glue capability offers? Enough to stay up nights to solve the production problems? Who on the team will identify and bridge any gap in the context each team is using as the basis for their communication?

Which brings me back to the European Commission briefing. No room for doubt there - collaboration is a good thing, from the goals for projects to the ways in which project teams are constructed. And how was Framework 6 designed? You guessed it - a huge, collaborative effort over a number of years, involving workshops, committees, conferences, publications and more, with the aim of communicating a vision, then filling in the detail with objectives that researchers and industry recognize as priorities. It sounds wonderful, doesn't it. And, yes, if the evidence of earlier Frameworks is anything to go by, it will catalyze collaborative research teams to produce real results.

But I must make two observations.

Firstly context. The language of the Framework programmes, while syntactically and grammatically English, is such that even if English is your first language, you will benefit greatly from a 'translator'. The authors of this English have learned something from the art of the bulletin, issued after political summit meetings, that allows a certain freedom of interpretation, within the boundaries that the summit meeting defined.

Secondly style. The collaborative teams that participate in Framework programmes are made up of people, and people have personal styles. Some collaborate through democratic debate styled on Ancient Greece. Others appoint their own Napoleon to lead them.

So, of course collaborative environments need to have embedded command-and-control capabilities. But who will be appointed to use these? For large scale, enduring success, this is a role for the Benevolent Dictator. 'Benevolent' because they understand that sometimes there is value in using language that leaves room for others to add their know-how and thus feel ownership of their area. 'Dictator' to provide and enforce the structure which will be the fall-back if the shared context for communication is missing.

Peter Thorne

peter thorne@cambashi.com

A version of this article was first published in the December 2002 issue of EAR

Other Cambashi articles that may be of interest:
Is industry doing enough to deliver on collaboration?
Design collaboration - the business issues

back to top