Conversations and commitments: an encounter with emergent design

Many years ago, I was tasked with setting up an Asia-based IT development hub for a large multinational.   I knew nothing about setting up a new organisation from scratch. It therefore seemed prudent to take the conventional route – i.e., engage experts to help.

I had conversations with several well-known consulting firms. They exuded an aura of confidence-inspiring competence and presented detailed plans about how they would go about it. Moreover, they quoted costs that sounded very reasonable.  

It was very tempting to outsource the problem.

–x–

Expert-centric approaches to building new technical capabilities are liable to fail because such initiatives often display characteristics of wicked problems,  problems that are so complex and multifaceted that they are difficult to formulate clearly, let alone solve. This is because different stakeholder groups have different perspectives on what needs to be done and how it should be done.

The most important feature of such initiatives is that they cannot be tackled using rational methods of planning, design and implementation that are taught in schools, propagated in books, and evangelized by standards authorities and snake oil salespeople big consulting firms.

This points to a broader truth that technical initiatives are never purely technical; they invariably have a social dimension. It is therefore more appropriate to refer to them as sociotechnical problems.

–x–

One day, not long after my conversations with the consulting firms, I came across an article on Oliver Williamson’s Nobel prize winning work on transaction costs. The arguments presented therein drew my attention to the hidden costs of outsourcing.

The consultants I’d spoken with had included only upfront costs, neglecting the costs of coordination, communication, and rework. The outsourcing option would be cost effective only if the scale was large enough. The catch was that setting up a large development centre from scratch would be risky, both politically and financially. There was too much that could go wrong.

–x–

Building a new sociotechnical capability is a process of organisational learning. But learning itself is a process of trial and error, which is why planned approaches to building such capabilities tend to fail. 

All such initiatives are riddled with internal tensions that must be resolved before any progress can be made. To resolve these tensions successfully one needs to use an approach that respects the existing state of the organisation and introduces changes in an evolutionary manner that enables learning while involving those who will be affected by the change.  Following David Cavallo, who used such an approach in creating innovative educational interventions in Thailand, I call this process emergent design.

–x–

The mistake in my thinking was related to the fallacy of misplaced concreteness. I had been thinking about the development hub as a well-defined entity rather than an idea that needed to fleshed out through a process of trial and error. This process would take time; it had to unfold in small steps, through many interactions and conversations.

It became clear to me that it would be safest to start quietly, without drawing much attention to what I was doing. That would enable me to test assumptions, gauge the organisation’s appetite for the change and, most importantly, learn by trial and error.

I felt an opportunity would present itself sooner than later.

–x–

In their book, Disclosing New Worlds, which I have discussed at length in this post, Spinosa et. al. note that:

“[organisational] work [is] a matter of coordinating human activity – opening up conversations about one thing or another to produce a binding promise to perform an act … Work never appears in isolation but always in a context created by conversation.”

John Shotter and Ann Cunliffe flesh out the importance of conversations via their notion of managers as authors [of organisational reality].  Literally, managers create (or author) realities through conversations that help people make sense of ambiguous situations and / or open up new possibilities.

Indeed, conversations are the lifeblood of organisations. It is through conversations that the myriad interactions in organisational life are transformed into commitments and thence into actions.

–x–

A few weeks later, a work colleague located in Europe called to catch up. We knew each other well from a project we had worked on a few years earlier. During the conversation, he complained about how hard it was to find database skills at a reasonable cost.

My antennae went up. I asked him what he considered to be a “reasonable cost.” The number he quoted was considerably more than one would pay for those skills at my location.  

“I think I can help you,” I said, “I can find you a developer for at most two thirds that cost here. Would you like to try that out for six months and see how it works?” 

“That’s very tempting,” he replied after a pause, “but it won’t work. What about equipment, workspace etc.? More important, what about approvals.” 

“I’ll sort out the workspace and equipment,” I replied, “and I’ll charge it back to your cost centre. As for the approval, let’s just keep this to ourselves for now. I’ll take the rap if there’s trouble later.” 

He laughed over the line. “I don’t think anyone will complain if this works. Let’s do it!” 

–x–

As Shotter and Cunliffe put it, management is about acting in relationally responsive ways. Seen in that light, conversations are more than just talk; they are about creating shared realities that lead to action.

How can one behave in a relationally responsive way? As in all situations involving human beings, there are no formulas, but there are some guiding principles that I have found useful in my own work as a manager and consultant:

Be a midwife rather than an expert:  The first guideline is to realize that no one is an expert – not you nor your Big $$$ consultant. True expertise comes from collaborative action.  The role of the midwife is to create and foster the conditions for collaborative action to occur.  

Act first, seek permission later (but exercise common sense): Many organisations have a long list of dos and don’ts. A useful guideline to keep in mind is that it is usually OK to launch exploratory actions as long as they are done in good faith, the benefits are demonstrable and, most importantly, the actions do not violate ethical principles. The dictum that it is easier to beg forgiveness than seek permission has a good deal of truth to it. However, you will need to think about the downsides of acting without permission in the context of your organisation, its tolerance for risk and the relationships you have with management.

Do not penalize people for learning:  when setting up new capabilities, it is inevitable that things will go wrong.  If you’re at the coalface, you will need to think about how you will deal with the fallout. A useful approach is to offer to take the rap if things go wrong. On the other hand, if you’re a senior manager overseeing an initiative that has failed, look for learnings, not scapegoats.

Distinguish between wicked and tame elements of your initiative: some aspects of sociotechnical problems are wicked, others are straightforward (or tame). For example, in the case of the development centre, the wicked element was how to get started in a way that demonstrated value both to management and staff. The tame elements were the administrative issues: equipment, salary recharging etc (though, as it turned out, some of these had longer term wicked elements – a story to be told later perhaps).

Actively seek other points of view: Initially, I thought of the development centre in terms of a large monolithic affair. After talking to consultants and doing my own research, I realised there was another way.

Understand the need for different types of thinking: related to the above, it is helpful to surround yourself with people who think differently from you.

Consider long term consequences:  Although it is important to act (the second point made above), it is also important to think through the consequences of one’s actions, the possible scenarios that might result and how one will deal with them.

Act so as to increase your future choices: This principle is from my intellectual hero, Heinz von Foerster, who called it the ethical imperative (see the last line of this paper). Given that one is acting in a situation that is inherently uncertain (certainly the case when one is setting up a new sociotechnical capability), one should be careful to ensure that one’s actions do not inadvertently constrain future choices.

–x–

With some trepidation, we decided to go ahead with the first hire.

A few months later, my colleague was more than happy with how things were going and started telling others about it. Word got around the organisation; one developer became three, then five, then more. Soon I was receiving more enquiries and requests than our small makeshift arrangement could handle. We had to rent dedicated office space, fit it out etc, but that was no longer a problem because management saw that it made good business sense.

–x–

This was my first encounter with emergent design. There have been many others since – some successful, others less so.   However, the approach has never failed me outright because a) the cost of failure is small and b) learnings gained from failures inform future attempts.

Although there are no set formulas for emergent design, there are principles.  My aim in this piece was to describe a few that I have found useful across different domains and contexts. The key takeaway is that emergent design increases one’s chances of success because it eschews expert-driven approaches in favour of practices tailored to the culture of the organisation.

 As David Cavallo noted, “rather than having the one best way there can now be many possible ways. Rather than adapting one’s culture to the approach, one can adapt the approach to one’s culture.”

–x–x–