Architecting Organisational Change
A mechanism to systematically drive change through an organisation
One of the cooler lessons I’ve been able to learn through the years is how to systematically architect a change of policy in an organisation. This is a skill that’s become absurdly useful; particularly as I start to develop expertise in specific areas, and would like ideas to propagate to other people in the organisation.
The following is a structured approach to propagating changes that follow more or less informally.
The fundamental lesson: embrace time.
One of the more interesting lessons, and one that I would wish to drive home above all others in this post, is to embrace the passage of time.
Humorously , I am known at work as someone who attempts to drive change at an unsustainable rate. However, it is in the most recent few years that I have learned to readjust my expectations for how fast changes propagate.
Initially I modelled this something akin to a service with predictable boundaries — something that I started, put bound dates on, planned and executed. However, it turns out this is a poor model to apply to the propagation of attitudes. There is no clean implementation for changing peoples mind, and no predictable model to do so. Setting deadlines simply sets an intervention up for failure.
Instead, I model a change I am looking to make based on the present. Essentially, when making changes I seek to shift the economics around a change, until the way I wish to do things is simply the cheapest and easiest to do, or the way that I think needs to change becomes cost prohibitive.
This allows changes to propagate at the fastest sustainable rate. It’s self regulating — where my colleagues continue to make decisions that I do not think are correct, I continue to work to readjust the economics. That, plus time, slowly but consistently restructures attitudes.
Creating a plan for change
Creating an organisational change consists of a number of distinct steps. They may be out of order, and may happen at different rates across an organisation — but nevertheless, the steps below are the ones that I currently model.
Create a point of comparison
When attempting to push people towards a given way of doing something, we must first instead start with an abstraction that they both know and understand. People model things by difference — “working remote” only makes sense given the paradigm of “working in an office”, “kubernetes” only makes sense given “virtual machines” or other software management, “team first” organisational structure makes sense in comparison to “project first”.
Thus: When creating a change, first find the thing within your organisation that is the most similar to the thing that you want changed. Then, systematically start describing how you would wish to depart from that process to this.
Smaller changes are easier to sell, but defining something by defining its opposite means people can reuse mental models and language to communicate their understanding of your new way of doing things.
Understand the value propositions
As mentioned earlier in “the fundamental lesson”, people generally (always?) make the best decisions available based on their understanding of how a decision will impact the things that they find valuable.
Accordingly, when seeking to make a change, it’s important to understand the value propositions of a system and to highlight how a change increases the expected return on investment that your colleagues will have should they embrace your change.
Given the example “We should set up remote first”, we can first consider why we work in an office. Things such as “communication”, “team events”, “a separate work environment” etc need to be either accommodated in the new paradigm or be superior. Things like:
- While working in an office makes meeting face to face easier, working remote first means that our meetings must be both prepared and documented. This documentation will increase the understanding of the meeting and decisions made, and make for a much more transparent organisation
- While working in an office makes ad-hoc team events such as visiting the cinema much easier, it also encourages siloing on non company bounds. Teams will form based on common interests such as a movie type, rather than organisational ones such as the type of project. Working remote requires a structured approach to team events, encouraging colleagues to get to know those who they might not otherwise and promoting cross company collaboration
- While working in an office allows employees to have a separate work environment, it also forces them to travel potentially large distances to a work environment that they cannot absolutely control. By shifting to a remote first model employees can choose their offices as they wish, either in an office or a shared work environment. This superior personal work environment leads to better results.
The decision to work remote first or not aside, the above demonstrates how we can take factors that are supporting the current paradigm and shift them such that they support our new, proposed change.
Communicate the above value proposition to key decision makers
Within an organisation there are those who have more influence over strategy either by assignment or simply by expertise and social standing. It is much more important accurately communicate the value proposition to those people rather than equally across the company, as those are the people to whom others will draw their cue’s to make their judgement.
Establish a pilot program that tests the efficacy of the intervention
It is extremely difficult to get an organisation to buy into a restructuring without a limited proof of concept that demonstrates the value proposition. While it may be possible to convince a limited number of stakeholders that a new intervention is a good strategy, it will likely be impossible to communicate to all stakeholders just how this strategy will affect the things they care about. Additionally, even stakeholders that you have convinced may have concerned that they do not air, or that they are unable to articulate.
Establishing a limited pilot program to test (and demonstrate) the intervention allows the development of a common understanding of exactly what the intervention is, as well as forces us to solve the invariable problems that crop up.
Given the above example of “Let’s work remote first”, we would run a pilot on a team that volunteered for the task in which they would not come into the office for a period of 90 days. We would then watch the remote impact on that team with metrics such as employee satisfaction, deliverable rate etc.
Once the pilot is complete, those involved can either become advocates for the change or the change proved unsustainable, in which case it is correctly rejected.
Communicate about a prototypes success or failure
A prototype is invariably limited, and not all stakeholders in an organisation will be involved in it. Accordingly, the results of the prototype need to be communicated.
Given success, this is essentially the same as demonstrating the value proposition but with additional evidence and supporters. However, given failure it is important to isolate a series of reasons why this intervention did not function as expected such that it can be retried with different parameters.
Wait
Even once a prototype is complete, a decision may not be made about rolling out an intervention. It may simply be cost prohibitive, it might be badly understood or it might be that key stakeholders haven’t had time to properly consider the intervention.
This is fine, and a normal part of the process. It’s easily possible to continue to roll out an intervention despite no explicit approval, simply by running more prototypes. Presuming an organisation is structured to delegate decision making as much as possible, teams will simply pick up this process and it will roll out organically.
??? Profit
I have successfully used the above strategy to roll out various changes, particularly in the area of software delivery. This process is continually ongoing, but the company I work for is now significantly better equipped to understand the implications of pushing software to production systems, and in many cases we do a much better job than we once did. Additionally, other interventions such as employee satisfaction analysis and security policy changes have been successfully implemented in this fashion.
The above is not limited to any specific kind of change — simply a defined strategy for architecting any kind of change.
Related Material
Thanks
- Colleagues. No one can change things alone — the above is how I try and drive it, but people also have to buy into that.
