What is Emergent Design?

Last week I had the opportunity to talk to a data science team about the problems associated with building a modern data capability in a corporate environment. The organisation’s Head of Data was particularly keen to hear about how the Emergent Design approach proposed in my recent book might help with some of the challenges they are facing. To help me frame my talk, he sent me a bunch of questions, which included the following two:

1. Can you walk us through the basic steps of emergent design in data science?
2. How does emergent design work with other data science methodologies, such as CRISP-DM or Agile?

On reading these questions, I realized I had a challenge on my hands: Emergent Design is about cultivating a mindset or disposition with which to approach problematic situations, rather than implementing a canned strategic framework or design methodology. Comparing it to other methodologies would be a category error – like comparing pizza to philosophy. (Incidentally, I think this is the same error that some (many?) Agile practitioners make when they mistake the rituals of Agile for the mindset required to do it right…but that’s another story.)

The thing is this: the initial task of strategy or design work is about a) understanding what ought to be done, considering the context of the organisation and b) constructing an appropriate approach to doing it.  In other words, it is about framing the (strategic or any other) problem and then figuring out what to do about it, all the while keeping in mind the specific context of the organization. Emergent Design is a principled approach to doing this.

–x–

So, what is Emergent Design?

A good place to start is with the following passage from the PhD thesis of David Cavallo, the man who coined the term and developed the ideas behind it:

“The central thrust of this thesis is the presentation of a new strategy for educational intervention. The approach I describe here resembles that of architecture, not only in the diversity of the sources of knowledge it uses but in another aspect as well – the practice of letting the design emerge from an interaction with the client. The outcome is determined by the interplay between understanding the goals of the client; the expertise, experience, and aesthetics of the architect; and the environmental and situational constraints of the design space. Unlike architecture where the outcome is complete with the artifact, the design of [such initiatives] interventions is strengthened when it is applied iteratively. The basis for action and outcome is through the construction of understanding by the participants. I call this process Emergent Design.”

Applied to the context of building a data capability, Emergent Design involves:

1. Having conversations across the organization to understand the kinds of problems people are grappling with. The problems may or may not involve data. The ones that do not involve data give you valuable information about the things people worry about.  In general the conversations will cover a lot of territory and that is OK – the aim is to get a general feel for the issues that matter.
2. Following the above, framing a handful – two or three – concrete problems that you can solve using skills and resources available on hand. These proof-of-concept projects will help you gain allies and supporters for your broader strategic efforts.

While doing the above, you will notice that people across the organization have wildly different perspectives on what needs to be done and how. Moreover, they will have varying perspectives on what technologies should be used. As a technology strategist, your key challenge is around how to reconcile and synthesise these varied viewpoints. This is what makes the problem of strategy a wicked problem. For more on the wicked elements of building data capabilities, check out the first chapter of my book which is available for free here.

Put simply then, Emergent Design is about:

1. Determining a direction rather than constructing a roadmap
2. Letting the immediate next steps be determined by what adds the greatest value (for your stakeholders)

With that said for the “what,” I will now say a few words about the “how.”

–x–

In the book we set out eight guidelines or principles for practicing Emergent Design. I describe them briefly below:

Be a midwife rather than an expert: In practical terms, this involves having conversations with key people in business units across the organisation, with the aim of understanding their pressing problems and how data might help in solving them (we elaborate on this at length in Chapter 4 of the book). The objective at this early stage is to find out what kind of data science function your organisation needs. Rather than deep expertise in data science, this requires an ability to listen to experts in other fields, and translate what they say into meaningful problems that can potentially be solved by data science. In other words, this requires the strategist to be a midwife rather than an expert.

Use conversations to gain commitment: In their ground- breaking book on computers and cognition, Winograd and Flores observed that “organisations are networks of commitments.” between people who comprise the organisation. It is through conversations that commitments between different groups of stakeholders are established and subsequently acted on. In Chapter 3 of the book, we offer some tips on how to have such conversations. The basic idea in the above is to encourage people to say what they really think, rather than what they think you want them to say. It is crucial to keep in mind that people may be unwilling to engage with you because they do not understand the implications of the proposed changes and are fearful of what it might mean for them.

Understand and address concerns of stakeholders who are wary of the proposed change: In our book, The Heretic’s Guide to Management, Paul Culmsee and I offer advice on how to do this in specific contexts using what we call “management teddy bears”. These involve offering reassurance, advice, or opportunities that reduce anxiety, very much akin to how one might calm anxious children by offering them teddy bears or security blankets. Here are a few examples of such teddy bears:

• A common fear that people have is that the new capability might reduce the importance of their current roles. A good way to handle this is to offer these people a clear and workable path to be a part of the change. For example, one could demonstrate how the new capability (a) enriches their current role or (b) offers opportunities to learn new skills or (c) enhances their effectiveness. We could call this the “co- opt teddy bear”. In Chapter 7 of our data science strategy book, we offer concrete ways to involve the business in data science projects in ways that makes the projects theirs.
• It may also happen that some stakeholder groups are opposed to the change for political reasons. In this case, one can buy time by playing down the significance of the new capability. For example, one could frame the initiative as a “pilot” project run by the current data and reporting function. We could call this the “pilot teddy bear.” See the case study towards the end of Chapter 3 of the data science strategy book for an example of a situation in which I used this teddy bear.

Frame the current situation as an enabling constraint: In strategy development, it is usual to think of the current situation in negative terms, a situation that is undesirable and one that must be changed as soon as practicable. However, one can flip this around and look at the situation from the perspective of finding specific things that you can change with minimal political or financial cost. In other words, you reframe the current situation as an enabling constraint (see this paper by Kauffman and Garre for more on this). The current situation is well defined, but there are an infinite number of possible next steps. Although the actual next step cannot be predicted, one can make a good enough next step by thinking about the current situation creatively in order to explore what Kauffman calls the adjacent possible – the possible future states that are within reach, given the current state of the organisation (see this paper by Kauffman). You may have to test a few of the adjacent possible states before you figure out which one is the best. This is best done via small, safe- to- fail proof of con­cept projects (discussed at length in Chapter 4 of our data science strategy book).

Consider long- term and hidden consequences: It is a fact of life that when choosing between different approaches, people will tend to focus on short- term gains rather than long- term consequences. Indeed, one does not have to look far to see examples that have global implications (e.g., the financial crisis of 2008 and climate change). Valuing long- term results is difficult because the distant future is less salient than the present or the immediate future. A good way to look beyond immediate concerns (such as cost) is to use the “solution after next principle” proposed by Gerald Nadler and Shozo Hibino in their book entitled Breakthrough Thinking. The basic idea behind the principle is to get people to focus on the goals that lie beyond the immediate goal. The process of thinking about and articulating longer term goals can often provide insights into potential problems with the current goals and/ or how they are being achieved. We discuss this principle and another approach to surfacing hidden issues in Chapters 3 and 4 of the data science strategy book.

Create an environment that encourages learning: Emergent Design is a process of experimentation and learning. However, all learning other than that of the most trivial kind involves the possibility of error. So, for it to work, one needs to create an environment of psychological safety – i.e., an environment in which employees feel safe to take risks by trialling new ideas and processes, with the possibility of failure. A key feature of learning organisations is that when things go wrong, the focus is not on fixing blame but on fixing the underlying issue and, more importantly, learning from it so that one reduces the chances of recurrence. It is interesting to note that this focus on the system rather than the individual is also a feature of high reliability organisations such as emergency response agencies.

Beware of platitudinous goals: Strategies are often littered with buzzwords and platitudes – cliched phrases that sound impressive but are devoid of meaning. For example, two in- vogue platitudes at the time our book was being written are “digital transformation” and “artificial intelligence.” They are platitudes because they tell you little about what exactly they mean in the specific context of the organisation.

The best way to deconstruct a platitude is via an oblique approach that is best illustrated through an example. Say someone tells you that they want to implement “artificial intelligence” (or achieve a “digital transformation” or any other platitude!) in their organisation. How would you go about finding out what exactly they want? Asking them what they mean by “artificial intelligence” is not likely to be helpful because the answer you will get is likely to be couched in generalities such as data- driven decision making or automation, phrases that are world- class platitudes in their own right! Instead, it is better to ask them how artificial intelligence would make a difference to the organisation. This can help you steer the discussion towards a concrete business problem, thereby bringing the conversation down from platitude- land to concrete, measurable outcomes.

Act so as to increase your choices: This is perhaps the most important point in this list because it encapsulates all the other points. We have adapted it from Heinz von Foerster’s ethical imperative which states that one should always act so as to increase the number of choices in the future (see this lecture by von Foerster). Keeping this in mind as you design your data science strategy will help you avoid technology or intellectual lock in. As an example of the former, when you choose a product from a particular vendor, they will want you to use their offerings for the other components of your data stack. Designing each layer of the stack in a way that can work with other technologies ensures interoperability, an important feature of a robust data technology stack (discussed in detail in Chapter 6 of the strategy book). As an example of the latter, when hiring data scientists, hire not just for what they know now but also for evidence of their curiosity and proclivity to learn new things – a point we elaborate on in Chapter 5 of the data strategy book.

You might be wondering why von Foerster called this the “ethical imperative.”  An important aspect of this principle is that your actions should not constrain the choices of others. Since the predictions of your analytical models could well affect the choice of others (e.g. whether or not they are approved for a loan or screened out for a job), you should also cast an ethical eye on your work. We discuss ethics and privacy at length in Chapter 8 of the data strategy book.

–x–

These principles do not tell you what to do in specific situations. Rather, they are about cultivating a disposition that looks at technology through the mul­tiple, and often conflicting, perspectives of those whose work is affected by it. A technical capability is never purely technical; within the context of an  organisation it becomes a sociotechnical capability.

In closing: Emergent Design encourages practitioners to recognise that building and embedding a data capability (or any other technical capability such as program evaluation) is a process of organisational change that is best achieved in an evolutionary manner. This entails starting from where people are – in terms of capability, culture, technology, and governance – and enabling them to undertake a collective journey in an agreed direction.

…and, yes, all the while keeping in mind that it is the journey that matters, not the destination.

Two ways of knowing

I usually don’t pick up calls from unknown numbers but that day, for some reason, I did.

“It’s Raj,” he said, “from your decision-making class.”

As we exchanged pleasantries, I wondered what he was calling about.

“I’m sorry to call out of the blue, but I wanted to tell you about something that happened at work. It relates to what you talked about in last week’s class – using sensemaking techniques to help surface and resolve diverse perspectives on wicked problems.”

[Note: wicked problems are problems that are difficult to solve because stakeholders disagree on what the problem is. A good example of contemporary importance is climate change]

Naturally, I asked Raj to tell me more.

It turned out that he worked for a large IT consulting firm where his main role was to design customised solutions for businesses.  The incident he related had occurred at a pre-sales meeting with a potential customer. During the meeting it had become clear that the different stakeholders from the customer side had differing views on what they wanted from the consulting firm. 

On the spur of the moment, Raj decided to jump in and help them find common ground.

To do so, he adapted a technique I had discussed at length in class – and I’ll say more about the technique later. It worked a treat – he helped stakeholders resolve their differences and thereby reframe their problem in a more productive way. Ironically, this led to the customer realising that they did not need the solution Raj’s company was selling. However, a senior manager on the customer’s side was so impressed with Raj’s problem framing and facilitation skills that he was keen to continue the dialogue with Raj’s company.

“We think we know our customers through the data we have about them,” said Raj, “but understanding them is something else altogether.”

–x–

In his book, Ways of Attending, Iain McGilchrist draws attention to the asymmetry in the human brain and its consequences for the ways in which we understand the world. His main claim is that the two hemispheres of the brain perceive reality very differently: the left hemisphere sees objects and events through the lens of theories, models and abstractions whereas the right sees them as embedded in and thus related to a larger world.  As he puts it:

“The left hemisphere tends to see things more in the abstract, the right hemisphere sees them more embedded in the real-world context in which they occur. As a corollary, the right hemisphere seems better able to appreciate actually existing things in all their uniqueness, while the left hemisphere schematises and generalises things into categories.”

McGilchrist emphasises that both hemispheres are involved in reasoning and emotion, but in very different ways. 

“In the left hemisphere, we “experience” our experience in a special way: a “re-presented” version of it, containing now static, separable, bounded, but essentially fragmented entities, grouped into classes on which predictions can be based. This kind of attention isolates, fixes and makes each thing explicit by bringing it under the spotlight of attention. In doing so it renders things inert, mechanical, lifeless. In the other, that of the right hemisphere, we experience the live, complex, embodied world of individual, always unique, beings, forever in flux, a net of interdependencies, forming and reforming wholes, a world with which we are deeply connected.”

It struck me that Raj’s epiphany was deeply connected with McGilchrist’s distinction between the ways in which the two hemispheres of our brains attend to the world.

–x–

The data we collect on our customers (or anything else for that matter) focuses on facts, attributes that are easy to classify or measure.  However, such data has its limitations. As McGilchrist notes in his magnum opus, The Master and His Emissary:

“…there is [a] kind of knowledge that comes from putting things together from bits. It is a knowledge of what we call facts. This is not usually well-applied to knowing people. We could have a go – for example, ‘born on 16 September 1964’, ‘lives in New York’, ‘5ft 4inches tall’, ‘red hair’ …, and so on. Immediately you get a sense of somebody who you don’t actually know….What’s more, it sounds as though you’re describing an inanimate object…”

Facts by themselves do not lead to understanding.

–x–

Understanding something requires one to connect the dots between facts, to build a mental model of what is going on. This is a creative act that requires a blend of imaginative and logical thinking.

Since mental models we build are necessarily influenced our beliefs and past experiences, it is unreasonable to expect any two individuals will understand a given situation in exactly the same way. Understanding is a mental process, not a thing, and knowledge (as in knowing something) is an ever-evolving byproduct of the process. Education is not about conveying knowledge, rather it is about helping students expand and refine their individual processes of understanding.

As Heinz von Foerster put it:

“No wonder that an educational system that confuses the process of creating new processes with the dispensing of goods called ‘knowledge’ may cause some disappointment in the hypothetical receivers, for the goods are just not forthcoming: there are no goods.

Historically, I believe, the confusion by which knowledge is taken as substance comes from a witty broadsheet printed in Nuremberg in the Sixteenth Century. It shows a seated student with a hole on top of his head into which a funnel is inserted. Next to him stands the teacher who pours into this funnel a bucket full of “knowledge,” that is, letters of the alphabet, numbers and simple equations.”

The entire business of education is predicated on the assumption that knowledge is transferable and is assimilated by different individuals in exactly the same way. But this cannot be so. As von Foerster so eloquently noted, “the processes [of assimilating knowledge] cannot be passed on… for your nervous activity is just your nervous activity and, alas, not mine”

Since assimilating knowledge (understanding, by another name) is a highly individual activity, it should not be surprising that individuals perceive and understand situations in very different ways. This is precisely the problem that Raj ran into: two stakeholders on the client’s side had different understandings of the problem.

Raj adapted a sensemaking technique called dialogue mapping to help the two stakeholders arrive at a shared understanding of the problem. The technique itself is not as important as the rationale behind it. And that is best conveyed through another story.

—x–

Many years ago, when I worked as a data architect at a large multinational, I was invited to participate in a regional project aimed at building a data warehouse for subsidiaries across Asia. The initiative was driven by the corporate IT office located in Europe. Corporate’s interest in sponsoring this was to harmonize a data landscape that was – to put it mildly – messy. On the other hand, the subsidiaries thought their local systems were just fine. They were suspicious of corporate motives which they saw as a power play that would result in loss of autonomy over data and reporting.

The two parties had diametrically opposite understandings of the problem.

Around that time, I stumbled on the notion of a wicked problem and was researching ways to manage such problems in work contexts. It was clear that the solution lay in getting the two parties on the same page. The question was how.

The trick is to find a way to surface and reconcile diverse viewpoints in a way that takes the heat out of the discussion.  One therefore needs a means to make multiple perspectives explicit in a manner that separates opinions from individuals and thus enables a group to develop a shared understanding of contentious issues. There is a visual notation called Issue Based Information System or IBIS that can help facilitators do this.  Among other things, IBIS enables one to capture the informal logic of a conversation using a visual notation that has just four node types (see Figure 1).

Figure 1: IBIS node types

In brief: questions (also called issues) capture the problem being discussed; ideas are responses offered to questions; pros and cons are arguments for and against ideas. The claim is that the informal logic of conversations can be captured using just these four node types.

After playing around a bit with the notation, I was convinced it would be of great value in the discussion about the corporate data warehouse.  A day prior to the meeting, I met the project lead to canvass the possibility of using IBIS to map the discussion. After seeing a brief demo, he was quite taken by the idea and was happy to have me use it, providing the other participants had no objections.

The discussion took place over the course of a day, with participants drawn from three groups of stakeholders: corporate IT, local IT and business reps from the subsidiaries.

Mapping the conversation using IBIS enabled the group to:

1. Agree on the root (key) question – what approach should we take?
2. Surface different ideas (options) in response to the question.
3. Capture arguments for and against ideas.

As the conversation progressed, I noticed that IBIS took the heat out of the discussion by objectifying discussion points. It did this by separating opinions from their holders.   This made it possible for participants to understand (if not quite accept) the rationale behind opposing perspectives. This led them to a more nuanced appreciation of the problem and the proposed solutions.

As the morning wore on, the group gradually converged to a shared understanding of the problem.

By the end of the discussion, it was clear to everyone in the meeting that a subsidiary-focused design that enabled a consistent roll up of data for corporate would be the best option. 

Those interested in the details of what I did and how I did it may want to have a look at this paper. However, I should emphasise that the technique is not the point. What happened is that the parties involved changed their minds even though the facts of the matter remained unchanged, and the point is to create the conditions for that to happen.

–x–

The event occurred over a decade ago but has gained significance for me over the years. As we drown in an ever increasing deluge of facts, we are fast losing the capacity to understand. The most pressing problems of today will not be solved by knowing facts, they will be solved by knowing of the other kind.

–x–x–

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–