Last week I wrote about the pioneering work of the Tavistock Institute and the thinking that they provided into dealing with a world of cloud-like problems.
That terminology was taken from philosopher Karl Popper’s beautiful analogy of a world in which some problems are clock-like (complex, complicated, but ultimately knowable) but many of the real challenges are much more like clouds – chaotic, confusing and constantly changing. Too often organisations try to deal with cloud-like problems in by decomposing them to clock-like projects. The problem with that approach is that it often ends in failure.
A clock-like approach is easily summarised as the “best practice” approach. Implement the best practice and your problems will be solved. Deploy the best technology product and your challenges will be resolved. We, as a species, are a sucker for the promise of rainbow-pooping unicorns.
So what to do about it? Well, in 1976 Tavistock’s Albert Cherns published a paper in which he described six key facets of a cloud-like approach. It’s couched in the heavily academic language that predominates in so much of the Tavistock Institute’s work; here’s my hopefully simpler interpretation:
1. Compatibility of process
If you are trying to make some sort of change happen in a cloud-like situation, the approach by which you tackle it has to be in harmony with the objective you are trying to achieve.
Let’s take an example that I’m seeing in a number of clients at the moment. Many organisations want to become more collaborative. Now that’s a term in it’s own right that needs significant unpacking (see this useful model), but a key to making an organisation increase its collaborative capability will be to approach it in a completely collaborative way: mandating that your workforce should collaborate more is in conflict with the aim, so won’t work; neither will simply unleashing the latest and greatest enterprise collaboration software into your organisation.
A more compatible approach? Well, next week I’m taking some staff in one of my clients through a series of coaching sessions that will help people understand the basic tenants of why being more conscious of their networking activity can help them become more productive and make their lives easier. It won’t tell them what to do, but will hopefully open up their minds to why working with others is useful to them. From there the seeds of collaborative working may grow.
2. Control variance at the source
If you are going to introduce change into a cloud-like scenario, some things are going to work and some things aren’t. In that world, the people who are best able to address those variances are those closest to them – the people involved.
This is a concept that is well illustrated in the way in which user forums have sprung up to support software in recent years. Where support used to be something you bought, today it is often something that you find provided by other users. The mobile telephone service Giff Gaff have made such user support forums and communities the centrepiece of the customer service proposition. On the face of it, it might look to be (and may well have been) a cheap source of support, taking out the nasty expense of helpdesk services. That cost-saving is real because it does get reflected in the charges Giff Gaff customers pay. However, on Cherns principle, it might well be the better form of support to boot. Running a mobile network these days, with a plethora of technical and user issues, is more cloud- than clock-like (although a significant failure in the network itself is probably still more like a clock).
3. Minimum Critical Specification
Albert Cherns coined this phrase at the latest in 1976. It sounds an awful lot like the Agile concept of Minimum Viable Product.
MCS, however, I think could be a better approach for how cloud-like problems are addressed in the context of an organisation, especially if it is trying to come to terms with adapting and adopting to agile approached. Too often a business will still specify the everything including the kitchen sink when thinking about systems it needs. When a minimum viable product is delivered, expectations have been raised and then not met. Explaining that this is only the first step is hard.
Limiting the specification of a new approach to the bare minimum might help keep those expectations in check. What is the minimum that we need? rather than what is the minimum that we will deliver in the first instance?
4. Information flow
Quite closely tied to the concept of controlling variance at source is the idea that information about the use of the new way of working should be supplied directly to the people doing it, not just to management (or developers). How many systems, for example, provide usage information directly to the user? How might new working practises be improved more fluidly and dynamically by giving participants more direct feedback on the things that they are doing?
To an extent this idea is what’s underpinning the recent explosion in wearable technology and the quantified self. Tell me how many steps I walk each day and I’m likely to walk more.
5. Organisms not mechanisms
The history of industrial expansion is to treat an organisation like a machine. From Adam Smith’s concepts of division of labour, to Frederick Taylor’s scientific management, businesses have been increasingly created like machines. This is fine if the machine is operating in a clock-like world where change is limited. It’s great for building cars.
But if you need to suddenly retool your car production plant to make cheese, you hit the problem with mechanisms. They are slow to adapt and change because they have been optimised for their circumstance. Cloud-like problems need to have adaptable approaches, and need organisations structured like organisms.
Spotify have talked about their engineering culture of aligned autonomy, where small cells of workers are given autonomy to create their parts of the product on their own terms – small, multi-functional teams that are given free rein to work in how they see fit. This kind of organic, cellular approach works for software development. It also works for terrorist organisations at global scale; make of that what you will.
6. Boundary locations
Cherns in his paper talks about the example of a machine shop on a factory floor; traditionally, teams would be subdivided on the basis of the technology that they used: the milling department, the grinding department, the forging department and so on. Manufacturing processes these days have tended since towards being more focused on the product than the function; indeed, Spotify and others have multi-functional teams developing their product components, and this is common in agile teams. I spoke with a credit card company last year who are developing new product propositions in a similar way with multi-skilled teams focused on products or customers.
Yet white-collar work in general still looks like a functional machine shop: finance, sales, marketing, HR, IT, legal… Boundaries are the place that the pain sits in most organisations, and in a cloud-like world, it’s no wonder.
There’s one final factor that wan’t in Chern’s paper, but was a concept that he adopted later from the work of Nehemiah Jordan…
7. Don’t compare humans to machines
The common starting point for designing a new way of working is to divvy up the activities between machines and people. The trouble with this approach is that it’s a one-way thing in which we will inevitably lose out, because machines (with their limitations) will always get first choice. Rather than making humans the centre of decision making, we end up with the drudge work of tending to them. Look at the way that email enslaves – machines are terribly good at packaging and delivering data, we poor saps get let with the challenge of managing and acting upon all of that information.
This last point, which I see all around, is the only one I have difficulty with, as I find it hard to see what the alternative approach may be. However I think the answer probably lies in platform thinking – delivering basic technology that in itself does very little, but leaves us in control to use it as we see fit. This, in essence, is why despite many decades of investment in complex enterprise technology, most businesses big and small actually run on Excel.