Case study

Interim CTO: steadying a business that had outgrown its technical direction

Six months at a listed video-surveillance company: a failing overseas project taken to go-live, a new product range chosen, and the business handed back stable.

Six months as interim CTO of a listed UK company that designed complete video-surveillance systems, everything except the cameras themselves, for transport, port and highway networks at home and abroad. Three jobs at once: restore technical leadership, choose the next product range, and rescue a major overseas project. The project went live before the contract ended, and the business was handed back stable.

6months, interim, with a defined end
1overseas transport project taken from drift to go-live within the contract
0customers lost, including the multi-million account I was sent to rescue

The problem

The company had been built by its technical founders and had grown into a large, successful business with installations in demanding places. It used off-the-shelf industrial cameras; everything else in its systems, from transmission to control, was its own. It had also grown past the point where the founders could set its technical direction on instinct. A new chief executive, brought in to take the business forward, could see the symptoms: projects overrunning, systems failing on site, often overseas, and some expensive wrong turns in technology and operations. The most visible was a decision to bring manufacturing in-house, which had strained both capital and quality. A separate consultant was already unwinding that and returning production to specialist manufacturers when I arrived.

I was brought in for three reasons. Technical leadership needed resetting. The company needed a new product range and did not know which direction to take. And several major overseas projects were in trouble, one of them badly.

The project nobody could afford to delay

The most urgent was a system for a large urban transport network overseas, part of a multi-million account, where delay was not acceptable to the client. The common assumption is that a failing technical project has a technical cause. This one was partly technical and largely a relationship that had gone wrong.

On the technical side, work had drifted and morale was low. The system was large and highly complex, with many parts communicating asynchronously, and it was unreliable in ways that looked random. They were not random. In systems like this, particular sequences of events produce failures that are hard to reproduce and easy to misread. I refocused the engineering team on analysing the faults properly, rather than patching symptoms, and on a rapid, complete fix.

On the client side, the project directors were angry, and with reason. I spent a lot of time listening to them, and I took their predicament seriously. That earned the trust I needed for the harder conversation. Much of the overrun came from features the engineers had accepted along the way without pushing back. Because the original scope had been well documented, I could show where the extra work had come from. It had been done and could not be undone, but the client had to acknowledge its part in the problem, and that took pressure off a team that had been carrying all of the blame. From then on the client received working updates on time, which did more for the relationship than any promise.

The system went live before my contract ended and was a success.

Choosing the next product range

The existing line-up had known weaknesses, and the company had been unable to agree what should replace it. Much of the expertise needed was already in the engineering team; it had simply not been getting a hearing. I drew on it and guided a new range built on three ideas: modularity, so that solution architectures could be assembled to fit each site instead of forced into a fixed product; more processing power at the edge, where each camera connected to the network, so that video analytics could run there rather than back at the control room; and faster communications with built-in monitoring, so that the behaviour of a complex system could be seen rather than guessed at. Each one answered a specific problem in the existing products.

Handing it back

An interim role should end with the organisation stronger, not dependent. After six months the overseas project was live, the product direction was set and delivery was stable. The founders stepped back in to lead the technical side again, now with a clear direction and a team that was working.

Where this helps you

If your business has grown faster than its technical leadership, if a key project is failing and the customer has stopped believing you, or if you need to choose a technical direction and cannot get agreement, interim or fractional technical leadership can steady things without a permanent hire made in a hurry. See fractional technical leadership, or book a 30-minute conversation.

Tell me what you are trying to decide, or where you feel stuck.

I will suggest the smallest useful first step. Based in Leeds, working in the UK and internationally, on site or remote.

Not ready to talk? Try the free AI Ladder Check. It takes about 3 minutes.