There is usually a point when technology starts to feel harder than it should.
Projects are moving, but dates keep changing.
Something that sounded straightforward takes much longer than expected.
A release that was supposed to happen this month moves to next month.
Then again.
People are busy. The technology team is working hard. There may even be more people involved than there were six months ago.
Yet from the outside, it is becoming increasingly difficult to understand when something will actually be delivered.
For the leadership team, this creates a different kind of problem.
You start becoming cautious about commitments to customers. Sales wants to know when a capability will be available. Operations is waiting for changes. Finance is looking at an increasing technology cost. The board asks when a programme will be finished.
And the answer increasingly becomes:
“It depends.”
That uncertainty is often the first sign that something deeper needs attention.
The pain usually appears before the problem is understood
When I enter this kind of situation, I rarely start by assuming that the engineering team is the problem.
Most of the time, they aren’t.
The difficulty is that technology delivery is a system.
Architecture, priorities, dependencies, environments, suppliers, technical debt, team structure, operational responsibilities and decision-making all influence how quickly something can move.
A weakness in one area often appears somewhere completely different.
An architecture problem can look like a delivery problem.
A dependency on one person can look like a capacity problem.
Poor prioritisation can look like an engineering performance problem.
An unstable platform can make teams appear slow because much of their time is spent recovering from incidents.
From the leadership team’s perspective, however, all of these situations feel remarkably similar:
Technology has become difficult to predict.
Adding more people feels like the obvious answer
One of the natural reactions is to increase capacity.
If delivery is too slow, add developers.
If there are too many projects, create another team.
If the existing team is overloaded, bring in a supplier.
Sometimes that is exactly what is needed.
But capacity only helps when capacity is actually the constraint.
If releases depend on several systems, more developers don’t remove those dependencies.
If decisions are waiting for one senior person, more developers don’t distribute that knowledge.
If priorities continually change, additional capacity may simply create more work in progress.
The organisation becomes busier.
Delivery doesn’t necessarily become faster.
Before changing the organisation, understand how work actually moves
This is where I prefer to start.
Not with a new operating model.
Not with a restructuring proposal.
And not with a large transformation programme.
First, establish enough control to understand what is actually happening.
How does an idea move from a business request into production?
Where does work wait?
Which decisions repeatedly block progress?
Where are the dependencies?
How frequently do priorities change?
How reliable are the environments and release processes?
And when something is delayed, do we understand why?
You don’t need months of analysis to start seeing the patterns.
Once those patterns become visible, the conversation changes.
Instead of asking:
“Why is technology so slow?”
you can start asking:
“What is preventing this work from moving?”
That is a much more useful question.
Predictability comes before transformation
Technology transformation doesn’t always begin with changing technology.
Sometimes it begins by making the existing organisation understandable again.
Delivery becomes visible.
Problems surface earlier.
Decisions become clearer.
Leadership can distinguish between a capacity problem, a technology problem and an organisational one.
And gradually, commitments become something the business can trust again.
That is when meaningful transformation can begin.