Collaboration and anticollaboration – a tangible metaphor

What is collaboration? Why do people collaborate? Perhaps more to the point, why don’t they collaborate? How do we end up so often with what we’d have to call anticollaboration – the exact antithesis of collaboration?

So I’m standing there in the toy-department, waiting for a friend, and idly playing with the wooden toy train-set. It’s the type with magnetic couplings, and I’m amusing myself with the way the couplings work, or don’t work, depending on which way round I place a wagon. If it’s one way round, the train all pulls along as one piece – with nothing that’s directly linking the wagons together. But if I turn just one wagon round, everything pushes apart: the wagons run away from each other, and the more I try to push the wagons together, the more they fly apart, as if by magic.

All of which takes me back rather too many decades, to the joys of reading the original Thomas the Tank Engine stories, with their quarrelsome carriages and wily wagons that never seemed willing to cooperate or collaborate with those poor long-suffering railway-engines. The wagons always wanted to go their own way, and do whatever they wanted to do, regardless of what chaos that might cause to everyone else.

Which is kinda like collaboration – or lack of it – in the real world. So let’s play with that metaphor for a while, and see where it takes us…

— What is a freight-train? It’s a collection of wagons that usually do all want to go to different places, but for now it’s more efficient and effective to travel together.

— What brings all the wagons together? They meet at a marshalling-yard, are sorted into trains that each go in some perhaps-different yet shared direction, and split apart again at another freight-yard.

— What holds the wagons together? In the real world, railway-trains are linked via mechanical couplings that will connect either way round and allow only limited freedom of movement – and should not come apart until we tell them to! In the toy-train, though, the wagons are linked only by amorphous invisible forces – magnets – and it does matter which way round things are.

— What makes the train go? In some cases the wagons might be self-powered, but it’s more usual for there to be some kind of ‘motor unit’ pulling the whole train along.

— What makes the train stop? In the toy there may be no brakes at all, but in the real world, each wagon has its own brakes. For safety, those brakes default to ‘on’: they’re held open only by a shared signal (usually a vacuum-line) that passes along the whole length of the train. If there’s any problem, any wagon can signal the whole train to stop; if anything goes wrong, a wagon may slam its own brakes on, independently of the rest, slowing the whole train down, and possibly causing damage as it does so.

And what does all of this look like if we reframe it as collaboration?

— What is collaboration? It’s a collection of entities – people, machines, IT-systems, whatever – that may well all want to go to different places or achieve different aims, but for now it’s more efficient and effective if we work together.

— What brings all the collaborators together? We come together for a project or putative purchase or suchlike, work together for a while, then go our separate ways again once the together-work is complete. (There’s a definite life-cycle to this – though more about that in a moment.)

— What holds all the collaborators together? Many managers and salesfolk would no doubt like to believe that they have the equivalent of the rigid couplings of the real-world railway – the much-vaunted myths of ‘command and control’. In reality, though, the crucial linkage for collaboration is much more like the magnetic-couplings of the toy-train: the magnet-like nature of shared-vision and shared-values, pulling everyone along for the ride. And, exactly as with magnets, if we get it the wrong way round for any party in the would-be collaboration, what we get is anticollaboration – an active pushing-away rather than a bringing-together.

— What makes the collaboration go? Shared-vision and shared-values provide the literal motivation for collaboration; shared-alignment in action is what makes it actually move along towards the shared-aim. All of the human entities in the intended collaboration – and some of the machine-entities too – will have their own motive power: the challenge is to get them all to line up in the same direction for long enough to get some shared-task done.

— What makes the collaboration stop? Every entity has its own metaphoric brakes: for safety reasons, these will often default to ‘on’ – exactly as on the real train. To allow the collaboration to move, there needs to be a shared signal along the whole length of the ‘train’ – which means we need some metaphoric equivalent of the real train’s brake-vacuum coupling. We also need to enable every entity to signal the need to stop (much as happens in collaboration in the Toyota Production System) – otherwise it will likely attempt to stop anyway, locking up its wheels and maybe causing damage to itself in trying to stop the whole train.

What does all of this look like in practice?

Perhaps the first point, as above, is that there’s a definite sequence and structure to this, as classically described in Bruce Tuckman’s ‘Group Dynamics‘ cycle:

• Purpose (‘Forming’): a common aim is established, with values to link people to that purpose. [The nature and aim of the train is defined, along with the nature of the couplings for the train.]
• People (‘Storming’): people are engaged into the aim, establishing roles and responsibilities, with policies to guide the subsequent plan for action. [The wagons are marshalled in the marshalling-yard.]
• Preparation (‘Norming’): the plan, logistics and resources are outlined, ready for the start-event. [The route-plan is set and filed, the train fuelled-up and checked, ready for the start-light on the line-signals.]
• Process (‘Performing’): the collaborative work proceeds, until it reaches a point of completion. [The train travels along its required route, responding to any signals and required actions along the way.]
• Performance (‘Adjourning’): the collaborative work ends; benefits-realisation and lessons-learned are established, to support mutual-learning and mutual trust; and the various elements of the collaboration come apart and move on to other tasks. [The train reaches its destination; the train itself is split apart, and the individual wagons re-sorted for the next stage of their respective journeys.]

Or, in visual form:

All of which looks straightforward enough. But what can go wrong? Well, that’s where we go back to that metaphor of the toy-train and its magnetic-couplings. If the ‘engine’ is the shared-aim, the ‘wagons’ are the various collaborating entities, and the ‘couplings’ are the shared-aim and shared-values, then problem-issues could include:

• the engine-driver assumes that the engine alone is all that matters: the manager or salesperson assumes that everyone else will align automatically to their own choice of aim – without bothering to check whether this is actually the case
• the engine-driver or marshalling-yard crew fail to check that they have the right wagons, in the right order: there’s no check to ensure that the nominal collaborators have the right roles, or the right skills and experience for those roles
• the engine-driver or marshalling-yard crew fail to check the couplings: there’s no check to ensure that everyone in the nominal collaboration is ‘facing the right way’ and agreed to be along for the ride in this collaboration
• the engine-driver or marshalling-yard crew fail to connect the brake-couplings and safety-systems: the collaboration tries to move off with some of the brakes stuck ‘on’, and with no means to signal their distress
• the engine-driver ignores warning-signals from the train during the journey: alignment to the aim (the ‘couplings’) can come loose on the journey; an entity’s metaphoric brakes could come on at any time; the whole metaphoric train could catch fire – all of which are emergencies that must be addressed if the collaboration is to succeed
• the engine-driver ignores trackside signals: ‘outside’ events may force changes on the overall collaboration – and ignoring those signals may cause a crash
• the engine-driver assumes that the job is over as soon as the train arrives at the destination yard: completion of the task should always be followed by benefits-realisation (metaphoric ‘checking the manifest’ and suchlike), lessons-learned (‘check the wagons’) and alignment to overall purpose (‘do the paperwork for shipping-client billing’ and so on)
• freight-company ignores the need to maintain the wagons themselves: forcing entities straight from one collaboration into another will eventually cause ‘unexpected’ failures

The classic example of that last problem-risk is what I’ve described as the ‘quick-profit failure-cycle’, where tactics-level assumptions – usually those of the ‘engine-driver’ – are imposed upon everyone else, as a substitute for any actual agreement on overall aim:

It’s a short-cut that can seem very profitable in the short-term, yet it all but guarantees catastrophic collapse in the longer-term, as all of the elements that hold collaboration together – trust, purpose, values, people-relations, and policies that can adapt to changing conditions – are all steadily eroded away. Not a good idea…

Continuing the metaphor, these are all architectural issues too:

• design and maintenance of rolling-stock: skills and capabilities for the organisation and its collaborations, and support for development, capability and engagement of each entity
• design and maintenance of couplings and other intra-train signals: vision and values for the whole organisation and shared-enterprise, and clarity on aims for projects and tasks
• design, maintenance and operation of tracks and trackside-signals: support-services for the enterprise, and coordination between collaborations and tasks
• design, maintenance and operation of marshalling-yards: project-management, scheduling and suchlike

And so on, and so on: it’s all there.

For enterprise-architects, perhaps the best thing of all about this toy-train metaphor is that unlike so much of what we do, this is tangible, and direct. People can see, and feel, the way that the couplings work, the way that collaboration becomes anticollaboration, or can fall apart if we pull too hard; they can experience for themselves how a marshalling-yard works, or what happens when a train ignores a trackside signal. And it’s fun ‘playing trains’, too! 🙂

So perhaps buy your EA team a train-set for Christmas or whatever: take it to work, play with it, build your own version of the metaphor. Extend it with some extra track (how long do different collaborations need to last?) and points or switches (where do business-process diverge and rejoin?) or tunnels and bridges (where do processes cross over each other? which parts are hidden from others?) or other trains and trucks (what is the make-up of our various collaborations?) or other vehicles (what else works alongside to support our collaborations?) or even a base-mat (what’s our overall business-environment?). Others might think you’re a bit crazy, but what’s new about that? 🙂 – the real point is that this kind of ‘trick’ does get people’s attention, and it does work as a way to get architectural ideas over to a wider audience.

Just don’t complain if your children want to collaborate with you with that train-set too? 🙂