ELSA
Driving Effective Change
I am sure we all know one. That colleague who regales us with stories of how he has told ‘management’ (pervasive, omniscient, intransigent) what they need to do but they just won’t listen! Or the one who won’t do anything without checking with the entire chain of command. It is an obvious truism that change is hard on those impacted by it and certainly hard to initiate.
Big corporate initiatives have a terrible track record of success. Notwithstanding some helpful guidance from consultants in ‘Change’ — if ever there was a contradiction in terms that’s one — we seem to perpetuate a language of change that requires hierarchy to start it off.
Decisions shaped by hierarchy are dangerous: Conway’s Law is a famous statement of this. (Conway’s law — Wikipedia, the free encyclopedia) Coined by Melvin Conway in the 60’s it states, “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” So the design decisions we make, how we define value and what we build are heavily determined by who we think we work with and for. It is important to note here that hierarchy applies as much horizontally as it does vertically — the next step in the process may be controlled by someone no more senior than you but still with the ability to reject your work based on their needs and perspective.
Silos lead to Supervision
To manage this, we create supervisors and supervision processes to ensure not only that work flows in the right direction (from development to testing?) but also that the quality of the work as it passes through the process is sufficient. In this model, those who work in the functions being evaluated and those doing the evaluation, are all working in a manner more or less directly inherited from the industrial revolution and wartime Europe.
As we began to produce goods on an industrial scale, we ‘saved up’ labour by embedding tasks it used to perform manually in automated processes. We refer to this as Capital. There have been many studies that cover the impact of the industrial revolution on skills and the findings are broad. However, in general, skilled labour such as artisans moved from their trades to industry and rather than creating new skills, this industrial model narrowed their focus on individual tasks within a process rather than requiring them to learn new ones. This is sometimes referred to as the “de-skilling hypothesis”. The focus on doing many repetitions of a single task created efficiencies because the outcome could be broken into discrete parts. The best example of this is the automotive production line. Henry Ford famously said, “When my men come to work, I wish they would bring their hands and leave their brains behind.” The assumption of the continued value of job specialisation has continued through the large enterprise and even though car doors and internet software deliver value in different ways we use the same mechanisms for structuring labour as we did 100 years ago. The modern corporate structure was first implemented by Du Pont after World War Two, taking as its guiding metaphor the command and control structure implemented in the victorious Allied armies. Again, planning the taking of a bridge is very different to planning the evolution of internet software. I will defer to another time a discussion of the problems of the production line metaphor in some lean thinking applied to software development.
Specialisation
The irony for the modern corporation is that its search for “T-Shaped” people — people who are deep in an area but broadly knowledgable across the domain too — is thwarted by depth of knowledge in each function crowding out much of an employees ability to develop breadth. I prefer the term “specialising generalists”. So what has this got to do with change? Making changes to how we build or how we organise to build something directly bears on people’s jobs. So every change effort has to overcome the perception of de-skilling (Will I learn a new valuable skill?) or skill destruction (will my skills, I.e. Me, still be valuable?). As we consider how to enable high velocity software development, it is unsurprising that the supervisors over the process feel a little like Turkeys at Christmas. Take certain roles or functions that are often consulted ‘late’ from their perspective, such as architects or security experts. Why should they believe that the new way will be any better than the old way they still haven’t gotten to function effectively? More particularly, how can any individual trying to drive change, change their minds and get them to give it a shot? The challenge faced by most change initiatives is that the result of the change, what the job looks like once its done, is abstract until it’s delivered. If we are able to concretise what the new world looks like we are more likely to engage support.
My approach to driving change relies on two key claims:
1. Individuals don’t initiate actual change in organisations. No matter how senior or charismatic.
2. The same principles we use in delivering software can be used to deliver large scale organisational change.
As organisations all become software companies — since, to echo Andreessen, “Software is eating the world..”, those that create the most value are those that create the software. Not just the engineers, but everybody actively focused on creating that frictionless delivery of value to the customer. Where in the world of Du Pont in the 50’s (think Mad Men) a manager was expected to know more about the job than his employees, today as managers we expect to hire people who know much more than us on specific topics. Evaluating their design decisions becomes more difficult the more complex the software they write. In short, the makers have all the cards, not the managers. There is still a role for managers, I believe, as coaches, connectors and roadblock removers (see Becoming a Multiplier). But the myth of control of the manager is being debunked (Velocity NYC: Myths of enterprise control).
If the makers are those that now control the factors of production… then it follows that any change must start with them and probably prioritised by them too, since they know which resources are most in need of change.
As we evolve to develop software products, our siloed organisations need to transform from projects orchestrating disparate functions into product teams with creativity and agency to respond to customers needs all the way down the stack — from front end developer to sys admin. Any other model creates additional friction in the delivery of value to the customer. However, from this it follows that in both cases there ARE boundaries that knowledge of a new way has to cross in order to spread across the organisation.
Diffusion of Innovations
The famous work on Diffusion of Innovations by Rogers (Diffusion of Innovations, 5th Edition), outlines a 5 step process whereby new ideas diffuse across an organisation or community.
1. Knowledge — You need to know the new idea exists.
2. Persuasion — You think that it could solve a problem you have.
3. Decision — You decide to actually use it.
4. Implementation — You use it.
5. Confirmation — You look for other supporters that confirm your use of it.
Often though, this model is interpreted, as originally researched by Rogers in fact, in a centralised model, with ideas passed top to bottom. Schon (working with Argyris on double loop learning) challenged this view and proposed that innovation is decentralised and evolving. I have certainly found this to be the case in practise, but in the light of the discussion above, in order for a company to operate at high velocity, it can’t possibly wait for slow innovation diffusion from top to bottom. This development in how we think about innovation is mirrored in the philosophy of science where we consider how new science develops. The structured paradigm shift of Kuhn may be compared to the more chaotic model of Feyerabend.
Following our software development principles, we want to compress steps one to five into a small time and scope so that we can test the new idea. Picking a team, with a product and testing how a new way of working creates additional value is of course the way to do it. But, there’s a catch. While we all focus on delivering more value, ironically, it is less convincing and less visible, than the solving of a real problem shared by teams. In other words, we might deliver better software faster but any team can ask, “how much better?” and “How much faster?” If on the other hand, we can identify that both teams have a specific, and perhaps thought intractable, problem such as… “how to provision a VM in under 2 weeks,” the solution of this very precise problem has more success in driving the adoption of the new idea. This is because the problem is more concrete for that team than the other team’s value delivered.
Events
Taking some inspiration from Alain Badiou, I define an event as “a task that once performed forces a questioning of the current modes of operation by all those who witness it.” Said another way, if you can solve a problem that everyone thinks is just ‘how we do things around here’ then once they realise that there is a solution, it makes them question not only how they might use your solution but also the intractability of other problems too.
The compression of the many new methods, approaches or technologies that may be used in a project into an expression of essentially the solution of a single problem may seem impossible but it should be remembered that the creation of this event is merely a mechanism for fuelling the diffusion of the idea to be found in the new project. We need to give people a reason to engage with our way of seeing the world. In order to do that we need to rock theirs…
Remember how we used the term, Event, when talking about customer value? We wanted to create an event for the customer — the HSM — that would really grab their attention. Isn’t every great feature you have ever discovered in software, followed by “wow… I never realised I could do that!” There are events internally and events externally. What they express will be different. A problem for a team is likely not the same problem that their customer has. But they force engagement in the same way. In order to drive change in customer behaviour and team behaviour, we need events.
Metaphor and Language
An event creates a metaphor. Using an example from Lakoff and Johnson (Metaphors We Live By), who pioneered the study of metaphor, they show how metaphors reflect mental models. An example they use is that of war and argument…e.g. “Your point is indefensible”. These metaphors reflect the mental models underpinning our use of language and our biases in action. Metaphor becomes an incredibly powerful means of distributing mental models and their continued use reinforces the mental models themselves.
Imagine a phrase such as, “provision a VM”. This is metaphorical in that a VM is seen as a resource that is provided to you, as you might be provisioned a new uniform at work (Burger King?) Consider a different metaphor, “create and destroy a VM”. The control here is in a different place… could you create or destroy something that does not belong to you? Of course not. You can use and abuse your own resources as you like. Consider the impact that the diffusion of this simple, rather unassuming, requirement of merely creating your own VM’s when you need them could have in the organisation. The trick is to nurture and perpetuate this language, reflecting the new models of behaviour. In reality, as mental models change, and a team solves a problem, the metaphors write themselves and we find it everywhere we hear the solution discussed.
Language and Structure
In linguistics, the Sapir-Whorf hypothesis refers to a simple idea that the structure of our language determines the structure of our thinking and action. Now this is fairly controversial and I don’t intend to discuss this idea in any detail, suffice to say that the mental models we use to decide what to do next are influenced by what we find we can talk about. A simplistic example illustrates the point. Consider the use of the term ‘governance’ in your organisation and the possibility for the use of the term, ‘self-governance’. In software, over the last few years the very idea of self-governance has been considered only through the success of development teams at collaborating with stakeholders. But consider this same pairing in an investment banking context. After the financial crisis, any idea of not separating deal making with deal approval is literally impossible to discuss. From this, directly follows how we set up the world so that we can act. In other words, organise or structure. In the investment banking case it results in supervision functions. In the development case, it results in teams that have autonomy to release, with the resulting reduction of an independent release management function. New events and the metaphors they create, equip people (literally) to consider new ways of organising to achieve their outcomes.
Imagine if you will, a demo…that shows some cool new feature including its automated deployment into the cloud. The metaphor, ‘create resources on demand’ immediately causes someone in the audience to ask how they can similarly create resources and perhaps share yours. While it might not appear on an org chart, this audience participant has created a new structure. It may be as ephemeral as the VM or it might persist and grow.
Agency.
We wish to create teams with agency and to increase the agency of our customers. The new structure we create with events generate agency through creating new options for expressing what it possible and for aligning with resources that make it actionable. In just the same way that we attempt to reduce friction in delivering value to the customer, we also need to reduce the friction that impedes the effectiveness of the language in producing action. When somebody puts their hand up to ask for support, we need to ensure we pair them with a team or project operating in the same metaphorical space as quickly as possible. This could mean using members of the original team as mentors of new teams, or it could merely be to provide training that deepens the understanding of the metaphor itself — an example of this could be CHEF training, where people learn about automating resources. The cycle closes when individuals are able to create their own events within their own contexts using the tools provided as well as new tools that they have discovered or developed.
You will notice that agency is a core concept underpinning customer, team and organisational value.
ELSA
I formulate an approach to change that implements these dynamics and have used it in both small and large corporate contexts.
To recap, events create new language. New language generates new organisational structures and new organisational structures enable new agency.
Every project, iteration or release should be striving to create an event.
The continuous drive to create events not only creates value but also enables us to create value in new ways.
