Continual improvement, and the gap between intent and impact
This talk is about continual improvement. Specifically, how to avoid the unintended consequences of badly managed service improvements. Because here is the uncomfortable truth — most continual improvement programmes fail not because the ideas are bad, but because the improvements quietly become the new problem.
Before we begin a programme of continual improvements, we need to ensure everyone is aligned to what we are trying to achieve. We are seeking to deliver meaningful and impactful changes that add value to the business. Not motion. Not activity. Not slide decks. Value.
Two types of improvement, and why the difference matters
It is critically important to classify your improvements into two types.
Remedial improvements — where we resolve aspects of our services that have not quite landed as planned. Innovative improvements — where we add new value, or enhance the overall capabilities of the IT organisation.
This sounds obvious. It is not. Most improvement backlogs do not separate the two — and what looks like a programme of innovation is often just a long, polite list of things we should have got right the first time. Mixing them up makes it impossible to tell whether you are building a better organisation or apologising for an older one.
Before you improve anything, understand the flow
Before we plan our improvements, we need to understand our landscape. And that begins with understanding flow — starting with work types.
You can classify your work into three primary types, familiar to anyone who has read The Phoenix Project:
Planned work. Work you can prepare for. Specific outcomes, timelines, requirements. Recurring work. The administrative, ops and maintenance tasks. Reporting. Generally a consequence of planned work. Reactive work. The work you will be familiar with on the service desk — taps on the shoulder, walk-ups, incidents, events.
And there is a fourth: business change. Work you contribute to alongside the rest of the business but do not directly manage. Mergers, acquisitions, divestments, expansion into new markets, new product lines. The kind of work where IT is not the lead — but pays the price if it goes wrong.
These work types are universal. They are not specific to technology teams. Understanding them is the foundation for everything that comes next — choosing your frameworks and tools, designing your operating model, structuring your organisation, deciding where improvements will land.
Shape the structure around the work
Once you can see the work types, you can shape the organisation around them.
Reactive work primarily flows into your support functions. Incidents, service requests and events into the service desk; walk-ups; taps on shoulders. We design models around ITIL and NIST and structure teams around how this work arrives.
Planned work flows into your more technically focused teams — architecture, engineering, the people involved in planning. Recurring work falls in the centre, with operations and maintenance tasks performed by IT Ops, or across the top with service management — managing reporting, delivering service reviews.
This is more than a tidy diagram. Understanding your work types lets you start evolving your structure. You can build a model that allows teams to pull from left or right as workload fluctuates. High volume of incidents or a major incident? Pull from engineering into a Tier 4 swarm until the storm passes. Project that needs additional resourcing to hit deadlines? Pull additional capacity from IT Ops to support engineering.
Another advantage comes from aligning your senior technical teams into disciplines — communities of expertise such as Networking, Cloud, Platforms. These extend right down to your Tier 2 support teams. Each discipline is led by a Principal Engineer, responsible for setting direction, defining core capabilities, structuring the development path. This not only supports the business need and manages workflow — it gives your team a clear development path. The ability for them to plot their own career inside your organisation. All of it underpins a culture of improvement, driven by organisational behaviour rather than by an annual programme.
The 2,800 touchpoint trap
With our knowledge of work types and our operating model, we need to take a step deeper — into how work actually flows between teams.
Picture a workflow diagram. Each box is a team or department in the wider IT organisation. Inside each box, the ITIL practices they are responsible for and their latest maturity score. Red lines represent the flow of work between teams. A solid line represents tooling or automation. A dotted line represents a manual handover.
If we focus on the IT Operations team, the first thing we notice is that for every automated handover, there is a corresponding manual handover. On top of that, there are seven touchpoints with other teams.
So we have found a key team to drive some improvements, right? Wrong. We have probably found the most dangerous place to implement any improvements.
Imagine this team is twenty strong, and each of the other seven teams is also twenty strong. Quick maths: each team member could have up to one hundred and forty relationships to establish and maintain across teams. That is two thousand eight hundred touchpoints in total. Beyond just the inefficiency of moving workloads manually, it is an enormous cognitive load for your team to carry — resulting in a serious loss of productivity.
A single poorly managed improvement here could have a catastrophic impact on a huge part of your organisation. The temptation is to focus all your improvements where the most heat is. Resist it.
The work nobody puts on a backlog
We have control of our workloads. We understand how they flow. But still we are missing SLAs, projects are slipping, and we cannot understand why.
What are we missing? Hidden workloads.
It is in our nature to improve, to evolve. Every one of us tries to do this every day. But the validity of the work is uncontrolled, undocumented, hidden from view. These include measures taken to mitigate potential risks, and ongoing efforts to continuously improve processes and services without formal recognition. They only become noticeable when our metrics slip and we cannot explain why.
The question is — what are the characteristics of these hidden workloads, and how do we get them under control and integrate them into our systems of working?
Look at risk management for the answer. There are mature, well-established models for managing risks and issues — models that output work into recognisable types we have systems to manage. Both risk and continual improvement involve repeating cycles that refine strategies over time. Both focus on early identification to reduce potential disruptions. Both benefit from the inclusion of multiple stakeholders. Both rely on data for objective decision-making. Both require structured documentation and reporting. Both are loop models, where measurement is integral and KPIs guide continuous monitoring.
So we can borrow the risk model and apply it to continual improvement.
RICE — bringing the hidden into the visible
Risk models use a scoring mechanism — assigning scores to impact, probability, proximity to define likelihood and therefore priority. Can we apply this to continual improvement? Absolutely.
By using four measures, we can build a scoring model that drives prioritisation and decision-making.
Reach. How many people benefit from this improvement? What areas — internal and external — will benefit? Impact. Measure the impact on strategic goals — MTTR, regulatory compliance, customer outcomes. Confidence. What is your confidence in success? Other workloads, seasonal demands, known impending changes. Effort. What headcount is needed? Do we need new technology? Increased budget?
Apply the RICE calculation, produce a score. We now have visibility and control of all our workload — which gives us a far better degree of confidence in the success of any improvement initiatives we launch, because we will fully understand them.
How do we stop this becoming an administrative overhead? Use the score outputs to drive autonomy. Only Critical and High items appear in executive dashboards or summaries — these are the issues that require leadership awareness and potential resource reallocation. This tiered approach makes it easy to identify quick wins or high-impact items at lower levels, streamlining leadership focus on transformational or high-risk areas.
The cultural shift underneath the model
How have we reached this point? We have embedded holistic thinking into our culture, through our systems and our tools.
A holistic approach not only leads to greater operational efficiency. It builds a resilient, agile organisation ready to adapt and thrive in a complex, ever-changing environment. Enhanced understanding of interdependencies. Stronger organisational culture of continuous improvement. Better decision-making through comprehensive insights. Efficient resource allocation. Improved agility and responsiveness.
That is the operating context an improvement programme actually lands in. Not a vacuum.
Systems thinking and design thinking — both, not either
Now we have a platform of control, we can start to look at how to build and define our improvement programme in a way that maintains a holistic approach. We can introduce two methods, and both have a place.
Systems thinking is for complex, systemic, long-term challenges. It is holistic, analytical, abstract, conceptual and relationship-oriented. Use it for understanding the whole system and root causes — for organisational change, policy development, strategic planning.
Design thinking is for user-centred problems and rapid innovation. It is deeply human, creative, tangible, experimental and action-oriented. Use it for creating practical, user-friendly solutions — for product design, service innovation, user experience design.
The choice is rarely either-or. Most real improvement programmes need both, applied to the right kind of problem.
For the service desk, design thinking brings the most value because it is focused on user experience and high-velocity output.
Desirability, feasibility, viability — the design innovation triangle
There are three critical domains we need to consider when designing improvements that resonate.
Most IT organisations start with feasibility — focusing on the technological, ensuring the innovation is technically possible. As they mature, they consider viability — the business aspects, ensuring the innovation generates value and is sustainable inside the business. Finally, the often-overlooked domain — desirability — emphasising human values, meaning the innovation meets user needs and preferences. The understanding of people and organisational culture plays a role in making innovations desirable.
Successful innovations arise when solutions are feasible, desirable, and viable. Two out of three is not the win it looks like.
Build, test, learn, deliver
How do we build sustainable, high-value changes that resonate with users and support organisational success? A three-phase approach.
Start by researching and defining the problem. Through persona-based role play we delve deep into each interaction — beyond just our scope as an IT organisation, because we are often a small part of a wider process. We need to truly understand each actor's experience.
Then ideate solutions. Develop prototypes. Test, learn, refine at pace.
Finally, deliver an initial improvement with the essential features. Demonstrate capability. Build trust in the team.
The double diamond shape — broad exploration, then narrow to specific outcomes; broad again, then narrow again — is not a graphic flourish. It is a discipline.
Where this leaves us
And we should never overlook the importance of celebrating success. Acknowledging and rewarding the work behind those achievements reinforces a culture of improvement and motivates your team. It strengthens stakeholder confidence. It drives ongoing engagement. It helps create a sustainable environment where improvement is both valued and continuously pursued.
Six core takeaways.
First, clearly align with your definition of continual improvement and the difference between remedial and innovative. Second, understand your landscape — work types and how they flow within your team. Third, get control and visibility of your hidden workloads, bring them into your ways of working. Fourth, embed holistic thinking — use your understanding of workflow to shape your structures, rather than the other way around. Fifth, enable high velocity by empowering teams and escalating only relevant decisions. Sixth, use design thinking to drive sustainable, relevant improvements at pace.