Month: June 2017

Roughly a year ago, I facilitated a session on designing organisational culture. One of the slides I showed suggested that there are various methods and tools that aid culture change. I gave some examples of each. So, under 'methods' I listed: Developing supportive infrastructure, changing the context to change the habits, shaping group norms through incentives, relaxing or removing 'old' rules and controls, you and other leaders and managers demonstrating 'new/desired' cultural attributes.

And under 'tools', I listed: incentives, policies, symbols, feedback, communication, education and development.

A couple of weeks ago someone emailed me the slide back asking if I'd facilitate a 'deep dive' session exploring what I'd put on it. I called him and we agreed I should cover: What are tools? What tools work? How can we use them? (A tall order in 90 minutes. Note to self: be careful what I put on PowerPoints!).

To get myself thinking about this I google imaged 'what are tools?' to see what came up. The first screen showed a lovely range of things – a construction site helmet, a questionnaire, a hammer, some instructions, a reporting dashboard, some desktop icons, a mind-map, and so on. So, that got me heading towards answering the question with 'tools are shaping devices'.

I guess I was prompted in that definition as I'm doing a FutureLearn course on the Philosophy of Technology . It's packed with questions and discussion on the role of technology plays in mediating human interaction with the environment. It seems to me that technology – at least the form discussed in the course – is one type of tool. And, as we learned, tools/technology 'shape all kinds of relations between humans and the world, and in doing so, they influence practices and the ways in which we perceive the world.'

In trying to shape organisational culture or 'manage change' we are selecting tools that we think will do that.

So, I started the session testing the premise that tools are shaping devices. To stimulate thinking we looked what tools are in use that encourage drivers to stick to the speed limits, i.e. that shape driver behaviour. There are multiple tools to do this, including speed bumps, vehicle activated electronic speed signs, driving regulations, penalties for speeding, in-car speed limiters, and so on.

This led onto the discussion of which of the tools we came up with 'work' to shape driver behaviour. We initially felt that using several tools simultaneously would get drivers adhering to the speed limit more effectively that just one being used on its own. But then I got out the Creative Whack Pack a wonderful tool for stimulating creative thinking. The first one I picked up said 'Do the unexpected'. Someone suddenly remembered some traffic calming experiments that remove several of the standard tools for restricting speed and instead allowed drivers to 'self-police'.

From this we got to a point where we felt that tools that work have to be:
a) Relevant and current. Many of the tools in use have a 'shelf life'. For example, a policy doesn't stay relevant over time. And, it appears, neither do speed bumps!
b) Simple and trusting of the user rather than over-controlling
d) Selected for the context and purpose – what works in one context may not in another.

Our discussion also led us to propose that:
a) There can be unintended consequences of any tool used. For example, speedbumps are exciting challenges to skate-boarders. And what might be intended as an enabler could become a disabler. (Sadly, I've forgotten the actual example given on this)
b) We had a fairly limited view of what a 'tool' is and we should extend our thinking on them. For example, person suggested that the way classrooms are laid out constitutes a tool
c) We don't know what tool will work till we try it out

With these ideas to hand we went on to look at what tools we could use to encourage building strong communities, and failing fast and learning. (Two statements of 9 from a wall chart about the culture we want to foster). I'd brought some paper-based tools along as examples to try out.

Build strong communities. The Scottish Community Development Centre has a set of good-practice principles and guidance notes designed to support and inform the process of community engagement. Back this up with the Community Engagement Toolkit that we also looked at, and you have some tools to start building a strong community with.

Fail fast and learn. We had a go at taking Fail Forward's comprehensive Intelligent Failure Assessment. In this case the discussion revolved less around 'fail' – not a word we warmed to – and more around 'learn' and we got some useful and usable ideas to immediately put into practice.

Further, towards the end of the discussion we came to a view that failing fast and learning could also be an integral element of building a strong community.

And so, a final idea was born – the group in the room could select and use a wide range of tools to design and build their own strong community that has all the hallmarks of the changed culture they are working to develop in their 'day jobs'.

What's your view on tools for culture design? Let me know.

We went walking in the Scottish Highlands last week. The idea was to take a holiday: to get away from organization design stuff, book writing, work pre-occupations, and all the normal business as usual of life.

Holidays are supposed to make you more productive when you get back to work, because you've had time for rumination, reflection, mind-wandering and all the rest of the reasons we read about that tell us taking a holiday is a good thing

Whether or not it's actually true I'm not sure, and neither are others . Maybe I'll find out during the coming week when I re-enter the digitally enabled networked world: not easy to be part of in the areas we were walking.

Although it was the Scottish Highlands which is mainly sea, sky, wild open green and/or rocky spaces – very different from an office in central London, I didn't find myself quite free-wheeling away from organization design stuff.

Like the man we met at Loch Achaidh na h-Inich who told us he was a professional prawn fisherman, also fished for fun (which is what he was doing when we met him), and went to the River Severn for fishing holidays, I found myself continuously placing my holiday experiences in relation to organizational design approaches. It turned out I was on a busman's holiday.

That sounds ridiculous but here's several reasons I couldn't – or, some who shall be nameless said, wouldn't – escape.

The first day, we walked past numerous info boards telling us the history of the area we were walking in. Many, in fact most, of them detailed aspects of the Highlands history of clan conflicts and other fights between various factions over territory and resources, power struggles, wealth disparity, seizing of resources, and so on.

In a small snatch of internet access I managed to get, I looked up what I remembered of Louis Pondy's theories of organizational conflict. His classic paper categorizes 3 types of conflict: bargaining conflict (competing for scarce resources), bureaucratic conflict (conflicts in the vertical dimension of a hierarchy), and systems conflict (lateral conflict amongst the parties to a functional relationship). Yes, they were all reflected in the clan conflicts. So the next day I found myself pondering methods of reducing conflicts through design work.

Second, we walked into Plockton. It's a village with 350 people (now). Here's a snippet of its history:

Originally called Am Ploc, the settlement was a crofting hamlet until the end of the 1700s. As in so many other parts of the Highlands this all changed when landowners found it was possible to make much more money from their estates by letting their land to sheep farmers: and to make room for the sheep they simply cleared the crofters from the land, people who in many cases had lived there for generations. Many had little choice but to emigrate, and Plockton soon became a port of embarkation for those displaced during the clearances.

In the early 1800s the landlord, Sir Hugh Innes, decided he could increase the value of his estates further by giving tenants cleared from inland areas an alternative to emigration: instead they could resettle in a new fishing port he developed under the name of "Plocktown". New streets of houses were built, many with small crofts, pieces of land that the residents could use to supplement the income they derived from fishing. This was the era of the "herring boom" and Plockton rapidly grew to accommodate over 500 people, many living two families to a cottage.

But the herring boom simply ended when the fish changed their migration patterns, and the area was also severely affected by the potato famine of the late 1840s. Before long Plockton became known as Baile na Bochdainn, or "village of the poor". It saw a resurgence following the arrival of the railway in the 1890s, but large-scale fishing never resumed.

Since then it has had more ups and downs – being used as a location for a TV series turned it into a victim of its own success. But now it appears to be a thriving tourist location with upmarket gastro pubs serving haggis, neeps and tatties in tasteful arrangements, a high school with 300 pupils and a well organised community .

Plockton's story, mirrors many organizational ones, and triggered in my mind questions on agility, adaptability, and thriving. I wondered why is it Plockton is thriving and other villages with similar histories aren't?

There's an interesting blog on community thriving by Bettina von Stamm here. She discusses a range of factors that seem to need to be in place to enable a community to thrive. Several of them Plockton has. Her piece is related to cities but she wonders if the same factors are applicable to networks and organizations – so the following day found me musing on engendering thriving organizational communities.

Third, we spent time (in various pubs, sipping wee drams) reading print books: a wonderfully relaxing way to end a day's walking. I was reading John Le Carre's novel, Absolute Friends, even then I couldn't stop myself highlighting – not in a library book in case you're wondering – the paragraph, 'Promotion, Teddy, I would say, is in inverse proportion to knowledge. … The butler knows more than the lord of the manor. The lord of the manor knows more than the queen.'

And on the next page, 'in a mammoth bureaucracy obsessed with its own secrecy, the fault lines are best observed by those who, instead of peering down from the top, stand at the bottom and look up.' Yes, a reinforcement worth bearing in mind when I'm trying to help sort out what's going on in a customer journey that isn't working optimally.

When I next logged on I reached for Barry Oshry's work on Tops, Middles, and Bottoms, and Frederic Laloux talking about Reinventing Organizations.

So, a complete break in some respects, and not a break at all in others. Do you take busman's holidays? Let me know.

We've had several discussions this week on 'single point accountability'. This sounds straightforward as a concept. Like financial accounting, 'accountability is about giving a reckoning of the actions taken-—and the actions not taken-—that led to the final outcome. Just like in accounting, where your balance sheet must add up correctly, there also has to be a balance in performance accountability'.

Unfortunately, mostly, we think of accountability in relation to assignment of blame (loss) rather than in relation to credit (profit). If you're accountable, you take the blame for what goes wrong. CEOs are usually held accountable for wrong-doing that occurs in their organization and in many cases resign as a result. Sir John Rose, formerly CEO Rolls-Royce, and Martin Winterkorn, formerly CEO Volkswagen are two cases in point.

While they were still at work, both Sir John Rose and Mr Winterkorn received accolades for their leadership and credit for rising sales and share prices. Now, they face pressure to explain why they should not be held accountable for the bad things that happened on their watch as well.

Resignation doesn't solve the issue of what causes something to go wrong: why has the loss occurred? It's often hard to find out. Faster, Higher, Farther: The Volkswagen Scandal by Jack Ewing, a new book on the Volkswagen emissions problem attempts to explain how that situation arose.

But, as in similar situations, he can't give a clear-cut answer. He cites a range of factors involved – tolerance for breaking the rules, lack of checks and balances, employees who had reservations about illegal software had no place to turn, and the personality of Ferdinand Piech – a demanding and fearsome boss.

Finding a single accountable person, close to the work process or issue involved, In this sort of situation is probably impossible, so the CEO takes the 'buck stops here' position.

Many organisational redesigns involve doing a RACI exercise (putting names against each of the four aspects of accountable, responsible, consulted, and informed with an emphasis that there should be only one person accountable) in order to mitigate the risk of diffused accountability. That is fine in some situations – for example a single process operating within obvious organisational boundaries. In most cases it is insufficient. There are few work processes which are not complex. Many cross organizational boundaries.

Take the fashion industry's supply chain which the Bangladesh Rana Plaza catastrophe highlighted. A 2013 Panorama programme, "Dying for a Bargain", review commented that '[It] again showed the total fallacy of factory audits as finish times for workers were falsified and workers locked into factories. Research also shows how many western fashion buyers base their calculations on misleading industry standards set on 100% efficient factories.'

In the networked situation, there are still people responsible for doing work for which they are held accountable by someone else but it doesn't work neatly in a hierarchy to the top single point of accountability. It's not like the nested Russian Matryoshka dolls.

Additionally. accountability is not only about the people: individuals and their relationships, but also about the processes, systems, checks, and balances that enable people to take accountability or to be held accountable. And, in my experience, these formal system aspects are rarely examined as part of doing a RACI analysis or other work to assign accountability.

Assigning accountability in networked organisations is hard. The Oxford Handbook of Public Accountability notes that: 'In all networks, responsibility is shared, ruling out any single point of accountability and giving rise to intensified problems of "many hands". If no one person or body is formally in charge, nobody can be called to account for the network's collective outcomes or made to impose remedies in the wake of acknowledged failure'.

Our discussion on accountability was in relation to a work process that crosses several organizational boundaries – both internal and external. How do we make it work more effectively in the absence of any obvious single accountable owner, and the reality of assigning one?

Peter Bregman in an HBR article, The Right Way to Hold People Accountable, suggests five ways for ensuring people take accountability. He is focused on individuals but his suggestions are usefully extended into organisational policies, practices, systems and processes, within and across boundaries.

Clear expectations: along the work process which organisation is delivering what and accountable for it? Can this be stated and reinforced through contracts, service level agreements, or similarly formal arrangements?

Clear capability: do all the organisations in the work process have the right capability – technology, time, skills, money, data – to deliver what they are expected to deliver? If not, how can others in the network support or help reduce any gaps?

Clear measurement: is the work process being measured across the whole process and not just in discrete steps? How often are the measures reviewed? How transparent is the whole process to every organisation along it? Can each party clearly see at all times their contribution to the overall outcome?

Clear feedback: How quickly are the feedback loops operating in the case of failure? Does everyone have equal rights in highlighting and starting to solve any issues? Are the channels available to ensure rapid feedback? Are decision rights balanced to ensure the work process can work effectively all the time?

Clear consequences: What are the agreed consequences for failure in any part of the whole process? Are the consequences equitable along the process or is one part likely to be blamed more than another in the event of failure. Is there a better way to operate that avoids blame rather looks to collaborate and problem solve rather than to finger point?

There's much research in the field of networked governance that shows both the high value of good relationship building within the network and the formal ties of bridging and brokerage through systems and processes.

The ultimate aim is for everyone to feel accountable for the success of the overall process and be supported by systems, processes and policies which support this. In my view accountability is a design issue, perhaps more than a people/relationship issue? What's your view? Let me know.

I'm wondering whether the phrase '70% of change efforts fail' is down to not knowing how to get from a design to an implementation – so things stall at the point of a detailed, tested concept design. The 30% that don't fail may have cracked the process of a) planning to get safely from current to designed state and b) getting there. (Whether 70% of change fails is largely unproven but that hasn't stopped people thinking that is the case).

The topic came to mind when someone sent an email asking me to run a session with project managers where we 'delve deeper into the tools of change' which (in a previous workshop) I'd suggested included: incentives, policies, symbols, feedback, communication, education and development.

He asked 'from your experience what has worked, what's not – why to both, how can you use the tools in the project world, both internally to the project team (i.e. incentives to drive performance/change in behaviours, are there any lessons we can learn from the Agile delivery?) but also to the products of the projects'.

As I was pondering this I came across Ron Ashkenas HBR article We Still Don't Know the Difference Between Change and Transformation. He defines change management as 'implementing finite initiatives, which may or may not cut across the organization. The focus is on executing a well-defined shift in the way things work.'

He defines transformation as 'another animal altogether. Unlike change management, it doesn't focus on a few discrete, well-defined shifts, but rather on a portfolio of initiatives, which are interdependent or intersecting. More importantly, the overall goal of transformation is not just to execute a defined change -— but to reinvent the organization and discover a new or revised business model based on a vision for the future'.

This seems to me to be a useful distinction and I started to form a hypothesis that project managers confuse 'change management' and 'transformation'. And if they don't get the distinction between the two their transition plans and the implementation of them are going to lead to failure.

In my experience 'transformation' requires a good knowledge and understanding of systems thinking. (If you want to learn about this I recommend the short, free FutureLearn course Systems Thinking and Complexity)

My hypothesis began to morph towards a question – how much do project and programme managers know about systems thinking? Is there a tendency to treat transformation projects as change management projects? And if so, is that why projects 'fail'?

One researcher (2012) also asking how much project and programme managers are schooled in systems and complexity found that: 'Surprisingly, project managers do not seem to use simple systems thinking tools even though these provide unique benefits in framing and solving problems that arise from multiple perspectives and relationships.'

And in 2013, the Association for Project Management set up a group 'to promote systems thinking across the wider decision-making community in the UK in order to support the improved delivery of complex projects and avoid common pitfalls.'

The next thing to hit my inbox was a run of email exchanges about introducing the Spotify model of Product Development Units. This model involves functionally integrated, highly autonomous, self-organized, self-steering, teams, measured for performance at the team level. (See Niels Pflaeging's blog). The emails were discussing to how to effectively transition to them. An HBR article on this model discussed three challenges: balancing autonomy and accountability, balancing freedom to innovate versus following proven routines, balancing alignment with control.

If an organization is hierarchical, measures individual performance, has functional silos, and traditional management then introducing the Spotify model is not the change management Ashkenas describes as a few discrete, well-defined shifts. Because it affects the whole organization, it is the transformation that he describes as reinventing the organization and discovering a new or revised business model.

In this example, a typical change management plan to transition built around levers of change will not work. What's needed is a transformation plan – one which accommodates, what Ashkenas calls, the 'unpredictable, iterative, and experimental'. It requires not a 'tools and levers' approach but a systems thinking approach.

Now I'm wondering whether project and programme managers skilled and knowledgeable in systems (and complexity) thinking have a better track record of successful change and transformation delivery – because they can distinguish between the two and plan appropriately – than those who don't. Do you know? If so, let me know.