While cycling …

Cycling the Fakenham 50k on Sunday gave me thinking time to work on the rough outline of a blog piece on programme management. Why that topic? Because last week I found myself re-immersed in the world of Terms of Reference, Project Initiation Documents, version control, project dashboards with RAG ratings, Programme Boards requiring regular presentations in a specified format and so on.

I raised the possibility that as my work-stream is on change we could tackle all this with less formality, and in doing so demonstrate change in action. In response, I got ‘Good luck with that one’.

Ho hum. I’ve dusted down my Managing Successful Programmes course notes, started re-learning the vocabulary and acronyms and turned my sights from the different world of sense-making, story-telling and emergence.

What’s interesting about this time’s immersion into the project world is that, since I was last in it big time, it’s absorbed another approach – Agile. So not only is there the original language and requirements, there is the new language and requirements of sprints, daily stand-ups, scrum masters, backlogs, and the rest of it, including the use of boxes of post-notes. Fortunately, I have been close to the Agile world in the last couple of years, so have a good working knowledge of how it goes – for good and for learning from failure.

However, I’m wondering whether I should formally update my skills by taking the Agile Programme Management course that promises that by the end of it I will be ‘Responding to change with speed and grace’. I like the ‘speed and grace’ bit. It sounds just what I need for cycling in hot weather around Norfolk.

Alternatively, I could just buy the book ‘Project Management the Agile Way‘ and mug up on ‘the Agile Grand Bargain, the shift in dominance from plans to product and input to output, the latest public-sector practices, and new concepts such as return on benefit, and Kanban’. But probably reading it wouldn’t be in scope – thus being an exclusion – but if it was in scope, would it be critical or priority, or just a regular inclusion?

In terms of my personal learning project/ToR on the topic I think I’ll just put reading the book down in the Constraints section (not enough time to read it).

I realised I wasn’t quite there with the team and the method yet when I missed Friday’s stand-up by noticing my pop-up 15 minute reminder to attend, and then getting lost in time as I constructed the Configuration Management Requirements (five activities and three forms) section of the ToR I’m writing. To mitigate the risk of this happening again I have now set a 10 minute and a 5 minute alarm on my phone.

Writing that sentence has reminded me that I must put my phone to silent when I attend the stand-up as I got a knuckle rap last week when it rang. So, I just have to remember to put the phone on silent and go to the stand-up when the alarm rings. Oh, but I must then set another alarm to remind me to put the phone ringer back on after the stand-up. I can’t make the assumption that I will remember to do it. It is thus a risk and not an assumption. So maybe two alarms – one before and one after stand-up? (I checked that the alarm does go off even when the phone is in ringer-silent mode).

I see another risk that as I start churning out project documentation and attending various Boards and Authorities. I might start speaking only in the language of programmes and projects. I just read a warning on this. It begins ‘Every trade is also a tribe … One way that tribes, from teens to programmers, signal membership of the group is through language.’ So, I have to mitigate that risk. I can do that in one of two ways – making sure everyone not of the Project Tribe has the glossary of 800 commonly used project terms to hand – maybe on wall posters?

Oh, I just noticed that it doesn’t include all commonly used Agile words e.g. scrum! But don’t worry, we can hand out the Agile Glossary too. It’s worth a skim because you’ll see that some of its specialist vocabulary (or as they call it ‘unique terminology’) has slipped into Plain English e.g. Sign Up for Tasks

My second mitigation is that I could demonstrate being tri-lingual – fluently speak AMP (Association of Project Managers) and Agile with my project colleagues as the occasion merits – remember we are doing Agile Programme Management – and switching seamlessly to Plain English with the rest of the workforce. Additionally, I could suggest to Duolingo that they offer bite-size lessons in APM/Agile

So here I am reaching for my templates telling myself it’ll be fun. What are your hints and tips on doing organization design/development the Agile Programme Way? Let me know.

Leading design work

I'm writing the final chapter of my forthcoming book Organization Design: a practitioner's guide. I've got to the bit on business leaders and their role in design work, which I think calls on some specific skills which although useful in the 'day job' are not as essential as they are in taking a lead in design work. Here's a slightly shortened version of the section:

Leaders play a critical role in three ways in relation to organization design work: stating and explaining the 'why' of design or redesign, supporting people in making sense of the context that the re-design work is responding to, and telling the stories of how it is going.

There is no value in doing organization design work if the 'why' of doing it is not clear to people. Too frequently the 'why' is not obvious – if things are ticking along nicely then why change it, is a common attitude to proposed organization design work. 'Whys couched in terms like 'to be more adaptable', 'be fit for the future' or 'be more competitive' are not sufficient to convince people that the upheaval of redesigning is worth the effort. Nevertheless, it is that rather vague 'fit for the future' requirement that impels many organization redesigns.

It falls to the leaders to state the 'why' in terms that are meaningful to stakeholders so that they can understand how the new design will affect them. A leadership team that spends time really thinking through the 'Why redesign'?'question – its contribution to and impact on the work and the workforce – makes a big difference to the speed with which work can progress.

Explaining the 'why' of an organization redesign helps people make sense of what is going on. Leaders often see more of the context, and have more of the puzzle pieces than people who are focused on doing a particular task or role. Having access to the bigger picture puts the onus on leaders both to make sense of complex environments for themselves and then to support and work with others in their sense making so that a reasonably consistent and common view emerges.

Sense making is a collective and collaborative activity 'triggered by cues – such as issues, events or situations – for which the meaning is ambiguous and/or outcomes uncertain.' People typically become anxious in situations like this that violate their expectations. They expect leaders to interpret and make sense of the situation for or with them. Failure to do this on the leaders' parts leads to heightened anxiety and multiple individual interpretations of the situation.

Deborah Ancona, director of the MIT Leadership Center at the MIT Sloan School of Management explains how leaders go about sense making:

'This sense making ability is a particularly important predictor of leadership effectiveness right now. … It requires executives to let go of their old mental models and some of their core assumptions; to take in data from a wide variety of sources; to use the information they have to construct, with others, a "map" of what they think is going on; and to verify and update the map -— in part by conducting small experiments that provide the organization with more information.'

Researcher Sally Maitlis found that leaders approach their role of supporting collective sense making in one of four ways:

  • Guided where they are 'energetic in constructing and promoting understanding and explanations of events'
  • Fragmented where leaders are not trying to control or organize discussions but allowing stakeholders to generate alternative pictures
  • Restricted where leaders promote their own sense of what is going on with little stakeholder involvement
  • Minimal when both leaders and stakeholders await some other interpretation of the issues.

If leaders of organization design work take a combination of guided and fragmented sense-making approaches then stakeholders are more likely to feel involved in the design process. This is a tricky tension to work with. The guiding sets the framework and the outlines, the fragmenting allows for local or individual interpretation within the framework.

Explaining the 'why' and guiding stakeholder sense-making can be supported by storytelling. Be aware, though, that stories can be an effective and inspirational tool to both make sense of what happens in organizations, or to inspire, provoke or stimulate change. And stories can be used to mask the truth or to manipulate.

The skill of a leader in telling stories is to recognize that there are many stories possible from the same situation. (See the TED talk The Danger of the Single Story). Effective leaders, as story tellers, neither abuse their power, nor tell a single story. They tell many stories and they tell the stories from a position of equality and respect, illustrating organizational complexity, a diversity of views, and their own responses to uncertainty.

Stories told this way – that explain the why, and acknowledge uncertainty and anxiety – help build confidence in and emotional connections to the new design. They contribute to demonstrating authentic, transformational leadership.

What do you think the role of leaders is in organization design work? Let me know.

Observing and sense making

We were set a writing task last week to go out and observe, not participate, and then develop a short story from the observation. (I was on a creative writing course). That's a fairly open-ended task and we had to complete it within a couple of hours.

It reminded me of the start of most design projects I get involved in. One of the early steps is to find out what's going on in the client organisation, using various methods, and observation is often one of them.

Most design and change methodologies are rooted some form of 'current state assessment' involving observation – the language depends on the method or model. Think about the 'discovery', phase in appreciative inquiry, or the empathise stage in design thinking or the project conception of the project cycle or the awareness of the need for change in Prosci's change management model or the consulting cycle with an information gathering phase.

Observation sounds easy, but isn't. I watched two men eating lunch together, but couldn't decide if I was watching them because I was going to construct a detective story, a story on cultural habits of eating, a story of how to interpret hand gestures, or a story of something else yet to emerge as I watched. As I riffled through the various possible stories lines I focused on different aspects of the interchange that I could see but not hear. (By the way, I was inside watching through the glass window and they were outside and didn't appear to notice I was watching them).

Was the colour of the watch strap each had significant? Was the fact that they both had their phones face down on the table some kind of social agreement? What did it mean that one had his wallet on the table and the other didn't? Why did they spend some time looking at each other's rings? As I thought of different purposes for the watching I seemed to focus on different aspects of the exchange, and my interpretation of it varied depending on the storyline I was playing with.

I spend a lot of time observing in my organizational work, usually not as specifically and with such focus as that task made me. But I now wonder whether I should cultivate more conscious and reflective observational skills. The short session I spent watching the men eating lunch reminded me how easy it is to infer, assume, deduce, and jump to conclusions on very little evidence. (Take the Watson Glaser test to see how skilled you are at critical thinking). It also reminded me that observation is part of sense-making and various storylines that seem to make sense are possible but that my sense-making may not square with another person's observing the same scene. Getting to being an objective observer recording what you see without any filtering is hard. (See this blog post for 6 different recording frameworks).

Towards the end of the week – just after the observation task – I noticed several out of date flyers for events in the hall of residence I was staying in. I'd passed them multiple times and not noticed them before. This led to me to ask myself several questions in trying to make sense of this observation. Why I hadn't I noticed the flyers before – a thing about figure and ground, useful in design work? Was there anyone in the organization whose role it was to take down out-of-date notices? Does it matter that they stay up? And so on. A tiny detail but one that might be significant if I were doing organization design work there. (Think butterfly effect).

In the event I took the dated flyers down, leading to more questions: Was I being accountable or high handed? Was I showing initiative or interfering in something that wasn't 'in my job description'? …

These types of questions all seem material in organizational observation as we take observation into sense making (see this excellent academic article if you want some theory on the topic of sense-making) but what I then came to was a view that observation and sense-making are inevitably interpreted through social and cultural lenses. I needed, if not a multi-disciplinary team, at least some others to discuss and present more possibilities than those I was thinking of as I observed and tried to sense-make. In organizational life pooling the various the observations and the questions they raise could enable participative/collective sense-making and a perhaps a compelling story to emerge.

Do you think should organization designers hone their observation and sense-making skills? Let me know.

Designing with stories

Story telling seemed to be the natural topic for this week's blog. Why?

First, because today (6 August) I've started a one-week residential creative writing course focused on short stories. It's got a daunting amount of homework and is described as 'intentionally rigorous'. I'll let you know how I got on with it.

Second, last week I was reviewing the book Design a Better Business which has a whole section about storytelling as integral to organization design work and offers a downloadable template + instructions on how to construct stories.

Third, also last week I started a new assignment and am listening to stories people tell about the organization and the piece of work that I am doing with them about why we need to change. Some people specifically said 'we need to be better at telling the story of why we have to change'.

I am a bit sceptical that stories consciously designed to be 'tools' can change organizations. Possibly they can help change organizations or contribute to changing organizations – depending on how you constructed them, but how would you know any changes were due to the stories being told, and can you design or contrive stories that work well alongside the naturally occurring sort that get told in organizations?

Steve Denning, well known in organizational story telling circles, suggests in his 2004 HBR article they can be constructed and offers a neat summary table of what he calls 'The Storytelling Catalog', a kind of 'at a glance', list of different types of stories to meet different types of 'need'. The article tells Steve's story of how he came to his views on organizational stories and their relationship to knowledge management and leadership.

Yiannis Gabriel, irritated 'by the really awful state of the entry on 'Organizational storytelling' in Wikipedia, which is enough to discourage anyone from ever taking this topic seriously' offers a more academic, grounded in theory, discussion of organizational storytelling.

He wrote the piece at the end of 2011 and lists 6 reasons why 'in the past fifteen years, interest in organizational stories has increased considerably', moving on to explain the relationships between narrative and story, saying that confusing the two 'unfortunately obliterates some of the unique qualities of stories and narratives that make them vivid and powerful but also fragile sense-making devices'.

Over the years since then, organizational storytelling has gained ground, but its value as a 'change tool' appears to be moot. In June 2017, the University of Portsmouth hosted the 22nd Organisational Storytelling Seminar – making the point that: 'While the literature is clear about the centrality and functionality of stories in leadership processes, it is also acknowledged that stories are uncertain and complex, and hence difficult to use as tools (see e.g. Boje, 2006; Parry & Hansen, 2007; Sintonen & Auvinen, 2009).' It's well worth looking at the call for papers that the organizers put out as it headlines the current questions around the topic.

NOTE: If you're not familiar with the work of David Boje, a storytelling philosopher, take a look at his fascinating website. You can also join him at the December 13-15, 2017, in Las Cruces, NM for the 7th Annual Quantum Storytelling Conference.

A field related to organizational storytelling is Dialogic OD, and Gary Wong commenting on my last week's blog says that 'the new Dialogic OD perspective that folks like Peggy Holman are exploring explains why stories are preferred over surveys and interviews [for gaining organizational information]'. See Gary's full comment here.

Gary also sent me a useful article by Gervase Bushe who says: 'change occurs when the day to day thinking of community members has altered their day to day decisions and actions, which leads to a change in the culture of the community that entrenches those new ways of thinking. Their thinking is changed when the language, stories, and narratives the community uses is altered in a profound way (Barrett, Thomas, & Hocevar, 1995; Grant & Marshak, 2011). An interview with Bushe on the topic of stories used to challenge the status quo is here.

The general principle is (simplified version) that if, through storytelling, people start to change both their language and their stories then the organization is changing, the implication being that change stories can be consciously 'seeded'.

I'm now wondering if I should examine my scepticism about organizational storytelling – can stories be carefully constructed and told and have the outcome of changing the design of organizations? Should they be? What's your view? Let me know.

Note: This piece also appears on LinkedIn

Designing for emergence

I got a request last week 'to explore developing and delivering a Business Change function: how it might be structured, and its milestones and deliverables'. It came at the same point as the question, from Peter Murchland, 'can we or how can we design for emergence'?

At first glance, they seemed to be opposing notions. In the Donald Rumsfeld spectrum of 'There are known knowns, there are known unknowns, and there are unknown unknowns', business change typology seems to be more comfortable at the known knowns end, a kind of reductionist view of the work, and emergence typology at the unknown unknowns end a kind of holistic view of the world.

As I was musing on the two I remembered a picture I once had on my wall. It was a drawing by French illustrator Jean Olivier Heron, called 'Comment naissent les bateaux' (How boats are born). It showed a yawl gradually emerging through a sequence of drawings that started with a butterfly-winged mermaid hatching. (See it here).

This sparked the thought that maybe you could develop a business change function that designs, if not emergence, then the conditions for emergence. The originating business change function would incubate the principles and conditions that enable emergence. Peggy Holman describes two types of emergence.

  • Weak emergence describes new properties arising in a system. … In weak emergence, rules or principles act as the authority, providing context for the system to function. In effect, they eliminate the need for someone in charge. Road systems are a simple example.
  • Strong emergence occurs when a novel form arises that was completely unpredictable. We could not have guessed its properties by understanding what came before…. Nor can we trace its roots from its components or their interactions.

The emergence of the yawl from the butterfly-mermaid would be completely unpredictable if we were just looking at the start point and trying to predict an outcome from what we know of butterflies and mermaids. It would be a strong emergence. Except that in the picture you can trace the emergence of the yawl back to the butterfly/mermaid. So maybe its a weak emergence?

I'm interested in designing the conditions for emergence, because I'd like to see a business change function that is focused on helping organizational members manage uncertainty, be curious about what could happen, be willing to participate in experimentation, be happy to continuously adapt and learn new things, be skilled in meeting things that come in from unexpected directions, and be capable of continuously renewing the organization in a variety of ways. That roughly equates to being able to handle emergence rather than comply with processes.

This does not mean abandoning all programme management protocols but it may mean expressing them in a different form e.g. the concepts of 'deliverables' and 'milestones' could change. There might not be a detailed plan. There might, instead, be a trust that 'business change' will emerge and continue to emerge from an agreed direction and some principles.

The story of Miles Davis's, 'Kind of blue' illustrates. No doubt there was a contract and a 'programme' intent on getting an album of a certain quality produced by a specific point in time, with various risks managed by processs like insurance. But Davis approached the task within the programme from an emergent perspective:

'As was Davis's penchant, he called for almost no rehearsal and the musicians had little idea what they were to record. As described in the original liner notes by pianist Bill Evans, Davis had only given the band sketches of scales and melody lines on which to improvise. Once the musicians were assembled, Davis gave brief instructions for each piece and then set to taping the sextet in studio.'

The album is among the top most successful jazz albums ever recorded.

A similar interplay of programme protocols and emergent thinking is hinted at in Peter Corning's article (referenced in Holman's work) where he closes with the point that that both reductionism and holism are essential to a full understanding of living systems. So, it may be in attempting business change – it has to be done with both reductionist and systems thinking.

Leandro Herrero offers 12 simple rules of social change that I think are useful discussion starters for those developing a business change function that would enable continuously changing the business (the weak emergence) and working with the emergence of the unexpected (the strong emergence). One that I'm thinking would cause debate is 'Readiness is a red herring', and another 'Recalibrate all the time. Stay in beta.'

Coincidentally as I was writing this, I read an example about finding a treatment for multiple sclerosis that opens: 'Experiments that go according to plan can be useful. But the biggest scientific advances often emerge from those that do not.' It's a good story of designing the conditions that enable emergence.

Do you think you can develop a business change function that either designs for emergence, or designs the conditions for emergence? Let me know.

NOTE: This blog also appears on LinkedIn

Digital ecosystems – any thoughts?

Jim sent me an email last week saying: 'I am doing a webinar on ecosystems and with all the hoopla on digital ecosystems in HBR recently I think there is a possible org design perspective on this.'

He went on to mention alliance management functions, ecosystems of the future, and centralized/decentralized models. Finishing with the challenge 'Any thoughts?' So, here goes:

Beginning with the 'eco'. Ecosystems has recently entered the common language of business – to such an extent that it's in the top three management buzzwords of 2016.

Before it was a business word it was an ecologist's word and in that literature, there are many definitions on what ecosystems 'are'. A simple definition, from National Geographic is: An ecosystem is a geographic area where plants, animals, and other organisms, as well as weather and landscape, work together to form a bubble of life. Ecosystems contain biotic or living, parts, as well as abiotic factors, or non-living parts. Every factor in an ecosystem depends on every other factor, either directly or indirectly.

More detailed ecosystem definitions include concepts of pattern formation, self-organization, coevolution and co-existence between organisms and their environments, interaction across multiple scales of space, time, and complexity, and feedback loops.

Similarly, there are various definitions of digital ecosystem. Gartner's is: 'A digital ecosystem is an interdependent group of enterprises, people and/or things that share standardized digital platforms for a mutually beneficial purpose (such as commercial gain, innovation or common interest). Digital ecosystems enable you to interact with customers, partners, adjacent industries -— even your competition.' This definition is closest to the business ecosystem discussed in an article on three types of economic ecosystems (business, innovation, and knowledge).

Having got this far I paused. Earlier in the week I'd watched an Adam Grant TED talk in which he asserts that procrastination is an aid to thinking. That helped me feel ok watching a programme on Scottish and Icelandic seabirds around the Shiant Isles. It turned out to be about ecosystems. And all is not well. 'Overfishing, global warming disturbing the ocean food webs, pollution and the introduction of rodents and other animals to breeding places are ushering in an apocalypse. Some scientists estimate that by the end of this century most of the world's seabirds will have disappeared'. The Shiant Isles seabirds are part of this story.

The players (in the jargon – 'agents') and stakeholders in this seabird ecosystem are many, and interconnected. They have differing power positions and differing interests it. Most of the players are voiceless and many are powerless to protect themselves. It's an unsettling narrative that we should bear in mind when designing our digital ecosystems.

Having said that, there's a lot about designing digital ecosystems that make it sound do-able and relatively easy because basically you're designing a digital platform that you own and others use. There are some commonly cited leaders in the field: Danske Bank, Amazon, Philips Healthcare, and Fiat are among them. They have reportedly 'designed' digital ecosystems each based on a common platform.

But let's not get too excited or jump in designing them without pause for thoughts – here are my five:

  1. Digital ecosystems are complex interacting and interlocking networks. In designing one how do we answer questions like: what are its boundaries? Whose perspective are we looking at designing it for and from? Where will the power lie in it? Is it controllable? If you apply these questions to the seabird analogy you start to see the complexity of the interactions.

  2. The notion that digital ecosystems are 'beneficial' or add 'value' – as the definition says – is an assumption worth challenging. (Think seabirds again). Is it possible to design a digital ecosystem that is beneficial to all participants? Amazon, Google, Uber, Airbnb, are examples of companies known for their digital ecosystems some of the participants/agents in them – governments, regulators, and in some cases their workforce – are suggesting they are not beneficial. In designing digital ecosystems what discussions are we having about the value and benefit they bring?

  3. Having 'designed' the digital platform it is not possible to control its ecosystem. Once functioning it is continually adapting at a cellular/local level. In the seabird example, small colonies of gannets adapted their behaviours. In organizational terms, call centre agents, for example, develop work-arounds and adapt their behaviour in response to something happening in their environment (IT outages, new policy, etc). In digital ecosystems people hack-in, developers tweak bits, or interfaces fail … (See The Digital Ecosystem Paradox – Learning to Move to Better Digital Design Outcomes for more on this).

  4. Designing beyond the digital platform towards an ecosystem involves maintaining the ecosystem's capability to thrive over time. It involves long-term pattern watching using AI, big data, and extremely good interpretive analytics. If we see failures or the equivalent of 'poor health' then, it means trying out thoughtful adjustments. (Remembering that any adjustment will have consequences elsewhere in the ecosystem.) Organizational leaders tend to be poor at watching patterns over time. They are more interested in 'snapshots', or events with causes, so pattern watching may need different leadership skills.

  5. The idea of 'pattern watching' supposes that we know the boundaries within which we are watching. In seabird terms are we looking just at the puffin ecosystem and its agents, or the seabird population of the Shiants, or the wider seabird population or …? Does the pattern within the boundary matter more, from a design perspective, than the interactions and overlaps of patterns across ecosystem boundaries? Perhaps there are numerous citizens who are simultaneously a participant/agent/customer in Danske Bank, Amazon, Philips healthcare, and Fiat – what useful patterns would be revealed looking across these individual ecosystems that aren't revealed by looking within them.

How would you respond to Jim's email? Let me know.

NOTE: this blog is also on LinkedIn

Algorithmic organization design: let’s not be greedy

This week I started reading Aurora, a sci-fi novel by Kim Stanley Robinson. I hadn't read anything he'd written before but I got intrigued when I read an interview with him in which he was talking about positive futures. His view is that 'the stories we tell have the power to shape our future'.

That struck me as relevant as we (more or less) confidently tell ourselves the story that if we (re)design the organization then we will get positive outcomes – otherwise why design or redesign?

In between reading Aurora, I am writing a chapter on evaluating organisation designs for my forthcoming book. So, I'm asking myself how do we know what our design work is bringing, has brought, or will bring, in terms of positive futures such as efficiency gains, quality improvements, problems solved, or opportunities seized. Can we actually ascribe changes in any metrics we are tracking to something we've done in our design work?

It's the story told in Aurora. People design a spaceship to transport citizens from the now- unliveable-on Earth to likely-to-be-liveable-on Tau Ceti, aiming to get there 170 years after launch.

As the years progress, the metrics being tracked start to tell the astronauts that something is wrong – but the astronauts don't know how to find out what is the root cause of the problem – a flaw in the physical design of the space ship, something in the systems and processes, something in the way the astronauts are evolving themselves, normal wear and degradation? And thus, they don't know how to adapt the design. A reviewer remarked:

It [Aurora] is, for one thing, superbly insightful on the way entropy actually works in complex systems; how things break down or degrade, the stubbornness of the cosmos, the sod's-lawishness of machines. … The fixes are desperately costly of labour and resources. The ship is increasingly subjected to bodge jobs, and so liable to further breakdowns.

In Aurora, the ship's leading scientist is urging the AI system to tell give her the information needed to help her solve this problem. She asks for it as a narrative. But the AI system is stuck responding, questioning itself: 'How to decide how to sequence information in a narrative account? Many elements in a complex situation are simultaneously relevant. An unsolvable problem: sentences linear, reality synchronous. Both however are temporal.'

The scientist urges the AI to 'get to the point' and gets the response; 'There are many points. How to decide what's important? Need prioritising algorithm'. I almost burst out laughing, this is so akin to my world. If only I had the prioritising algorithm to hand.

Unfortunately, there are no prioritising algorithms and the AI muses that 'in the absence of a good or even adequate algorithm, one is forced to operate using a greedy algorithm, bad though it may be.' and in the Aurora case the AI has been programmed to have enough intelligence not to want to go down the greedy algorithm route. Organization designers take note. We, also, don't want to, and should not want to, select greedy algorithm approaches:

Greedy algorithms are simple and straightforward. They are short-sighted in their approach in the sense that they take decisions on the basis of information at hand without worrying about the effect these decisions may have in the future. They are easy to invent, easy to implement and most of the time quite efficient. Many problems cannot be solved correctly by the greedy approach.

The AI warns of the danger of using greedy algorithms as they are 'known to be capable of choosing, or even be especially prone to choosing, the unique worst possible plan when faced with certain kinds of problems.'

Exactly. If only we could inject more complexity recognition into in organization design work. It's too easy to focus on one simple and not necessarily relevant element e.g. the organization chart, or a customer satisfaction score, not acknowledging or understanding the complex and simultaneously relevant elements that the metric doesn't come even close to representing.

We look at various organizational metrics – see a list of The 75 KPIs Every Manager Needs To Know – and as these change over time, don't know whether our design interventions are causing change, whether our designs are solving current problems and/or if they are creating future problems because we can't identify what elements are 'simultaneously relevant' to look at/address, and the metrics can be interpreted in multiple ways.

Not only that, the metrics are not the whole story, John W Gardner explains:
What does the information processing system filter out? It filters out all sensory impressions not readily expressed in words and numbers. It filters out emotions, feeling, sentiment, mood and almost all of the irrational nuances of human situations. It filters out those intuitive judgements that are just below the level of consciousness. So the picture of reality that sifts to the top of our … organizations … is sometimes a dangerous mismatch with the real world. We suffer the consequences when we run head on into situations that cannot be understood except in terms of those elements that have been filtered out.'

This thinking didn't get me very far in writing the chapter on evaluating organization designs – but I am enjoying the sci-fi novel, so take comfort in the value of this displacement activity. (ED NOTE: What is this measured by ???)

How do you avoid the dangers of greedy algorithm thinking in your design work – doing it or evaluating it? Let me know.