Skip to content
All insights
From the trenches 9 July 2026 2 min read

What sixteen years in telecom taught me about failed automation

The technology was almost never the reason a project died. Understanding what actually killed them is most of why I now work with smaller businesses.

By Stanley Watterson

I spent sixteen years in telecom and network infrastructure. In that time I watched a lot of good automation ideas die, and I can count on one hand the number that died because the technology did not work.

What actually killed them

The integration was contractually impossible. The data we needed sat inside a vendor platform whose agreement did not permit the access. Technically trivial. Legally finished. Nobody was going to renegotiate a multi-year contract for one workflow.

The policy predated the problem. Security rules written years earlier for a completely different threat model, applied to a new situation by people who could not authorize an exception. Nobody in the chain was wrong to say no. The system simply had no mechanism for yes.

The approval cycle outlived the idea. Eighteen months from proposal to sign-off, by which point the tool we had scoped had been superseded twice. The project was not rejected; it just aged out.

Nobody asked the person doing the work. Requirements gathered from management, who described the process as designed rather than as performed. The gap between those two things is where the actual bottleneck always lives.

Why this matters to a smaller business

Almost none of that applies to you, and I do not think enough people say so plainly.

You are not renegotiating a five-year contract to get at your own data. Your security decisions can be made against your real risk rather than a policy inherited from a different decade. The person who understands the bottleneck is often the person who can approve fixing it, sometimes in the same conversation.

That is a structural advantage over organizations with a hundred times your budget. The thing that used to frustrate me most is now the thing I find most useful — I know exactly which constraints you do not have, and how much faster that lets us move.