Local optimisation is the enemy of change
Organisations scaling out of startup will be seeing high levels of change. Although definitions of “scaleup” varies, the ScaleUp Institute rates organisations as “scaling” if they are growing at least 20% annually. This level of growth can be hugely disruptive to how the organisation functions.
When looking at systems and structures for such a scaling organization, a key need is building the ability to scale. “Scalability”, as we might call it, is itself a capability to be developed. It doesn’t happen by chance and needs to be built in to the organisational design.
The important thing isn’t your process; the important thing is your process for improving your process.
“Lean from the Trenches” – Henrik Kniberg
“Best practice”
A scaling organization does not need to adopt perfect systems and structures. Indeed the idea of a “perfect” process is an illusion often pushed by people with a methodology or best practice to sell.
If the organization is scaling, especially at speed, it is changing. You may perhaps have identified today’s perfect process. But if so, it will not be a good fit when the organization has evolved. Accommodating change is much more important than polishing what you have.
In a past role, a wise auditor convinced me to stop saying “best practice” in favour of “good practices”. “Best practice” implies the problem is solved rather than improvement being continuous. There is a Scientific Management implication of a “right way” to work.
The “Spotify model” is a great example of how this is misunderstood. “Scaling Agile @ Spotify” was intended as an article describing the evolution of structure in a fast-changing organisation. Taking a static copy of the system described does not give you a perfect solution for all time.
This article is only a snapshot of our current way of working – a journey in progress, not a journey completed. By the time you read this, things have already changed.
“Scaling Agile @ Spotify” – Kniberg and Ivarsson
Local optimisation
There is a reverse pressure that acts against scalability.
There is a natural tendency for teams to fix the way that they work and get more efficient at working in that way. It is often easier to persist with a bad system than move to a new one. This is an outcome known as “local optimisation”.
An individual or team improves the details of their working practices to make them more efficient. Slowly they become a little more efficient but more tied in to their way of working and more inflexible. Small incremental gains are possible.
However, a significant improvement could be made by shifting to a different way of working. The more the team optimises their current way of working, the more inertia is built up and the harder it becomes to shift to something new.
The more the team optimises their current way of working, the more inertia is built up.
We might typically see this when organizations change tooling. The IT department (or a central Engineering group) has found new tools which are more effective and remove limitations in the old tools. Everyone has complained about the old system for years. They even accept the new tools are a better solution. However, when a migration to the new tools is proposed, there is one response which is almost inevitable.
“What about our scripts?”
The cost of moving
Teams have built a library of customisations and scripts to work around the limitations in the old tools. These scripts tend to be old, unreliable and hard to maintain. No-one likes them. The author may have left. Probably no-one really understands them anymore. But there is still a cost to moving to the new tools because any move has to be done in several steps.
- The current state – poor tools with local optimisation
- A transition state – new tools in which the team are not familiar
- The final state – new tools which are more effective
We expect that the final state is better than the current state. But because of local optimisation, the transition state is generally a drop in efficiency and worse than either. This prevents continuous improvement working incrementally and can be a barrier against any improvement programme.
Good practices
As an leader in a scaling organisation it is important not to view systems and structures as a “solveable” problem, despite people trying to sell solutions. As is central to the concept of Agile Plays, scaleups require a mix of good practices, tailored to the organisation.
You should expect change and build in scalability. This can best be done by promoting a questioning culture where change is expected.
- Metrics and KPIs will look at what is going well or badly
- Retrospectives will help to find where change is needed.
- Feedback from those using the process will inform change.
- Psychological Safety is needed to encourage teams to propose change.
However, it is easy to imagine that change will just occur if the new system has advantages. Local optimisation is one of the forces which will act against this. Change inevitably needs to be managed. As a leader you will need to ensure that new good practices are introduced well.
You will need to ensure communication and awareness of the benefits, to drive a desire to implement the improvement. But you also need to support the teams in migrating. You should recognise that local optimisation typically leads to an initial drop in performance in a transition state as teams move away from the old familiar systems before they can exploit the benefits of the new.
Leave a Reply