Speed Kills (the Competition): A Confusing Speedtest Image Told the Story

We know telco customers want faster speeds.
But is it possible that we’re focussed on the wrong type of speed?
Here’s a hint: the real drag isn’t line-speed.

.

“Finally”: The Message that Triggered an Article

Late last week a friend pinged me with a SpeedTest screenshot and a single word: “finally.”

I was confused. At first I had no idea what he was trying to tell me. The result itself was unremarkable – pretty decent speed (bandwidth), but not mind-blowing.

Then it dawned on me. I’d totally forgotten that nearly 3 months earlier, I’d introduced him to a couple of telcos to get an enterprise connection for his business. (I should also mention that the lead-in was already in his premises. Fibre was sitting there, quietly ready.)

Back when he kicked off the process of ordering a new service, he had a few options. He chose the provider that could activate his service the fastest. Not the cheapest, nor the one with the most impressive brochure, or the one with the most features. (Yes, 80-90 days was actually the fastest of the options.)

That “finally” message told an important story.

Despite being what we tend to focus on, customers don’t always care about peak throughput. Like many others, this friend’s choice was about the speed in terms of when his service would be ready for use. In a market that loves to advertise speed, we sometimes talk about time-to-market (TTM). But implementation speed (across all sorts of factors) is something we rarely spend time thinking about do we?

.

What Happens Inside Telcos That Slows Everything Down

I always say that when I’ve worked inside big telcos, I feel like I make 1 day of progress for 5 days of effort. I feel slow. Running at 20%. Argh!

It’s not because people aren’t working hard. If anything, they are working really hard – back-to-back meetings, instant messages pinging, escalations escalating… and then there’s the slide decks, steering committees and change review boards. Everyone is busy.

Despite this, very little is actually moving.

This is the hidden tax of scale. Not just in telco, but especially in telco.

Every update has a forum. Every risk has a workshop. Every design doc has a team of people too busy to review it.

Our OSS and BSS stacks are already complex enough, but the processes and organisations layered around them are often even more complex. By the time a simple order flows from sales, through design, through provisioning, through a hierarchy of contractors, dozens of people have nudged it, questioned it, or just slowed it down a little.

Complexity is another scourge. A ravenous time-suck. We should talk about OSS/BSS simplification. Oh wait. I just noticed that I’ve written 870 articles tagged with “simplification.”

Individually, these delays feel tiny – a day here, an approval or secondary revision there. Collectively, they turn a “simple” activation into a 80-90-day experience. From the customer’s perspective, it just looks like the telco is slow.

We’re all encouraged to find ways to incrementally speed up orders, resolve issues faster, etc.

But when was the last time you were asked, “what would it take to reduce by a factor of 10x?” That would need a total re-imagining of the people, process and tech. OSS and BSS have their fingerprints over all of them, so it’s a great place to start re-invention.

.

Working From the Outside: Where Speed Feels Real

Interestingly, when I’ve worked with carriers from the outside in, it feels completely different. I feel like I make 5 days of progress for 5 days of effort. Same person, similar work, same industry. Just a different operating framework (eg rarely back-to-back meetings, etc) and a different velocity.

When you’re on the outside, you tend to have clearer outcomes, and far less internal signalling to worry about. You’re not required to feed as many status machines. You’re judged more on what is delivered than how many meetings you attended along the way.

For OSS/BSS projects, this cadence can be the difference between shipping something meaningful in 6 weeks and still debating scope in month 6. Smaller players, niche integrators and specialist teams often have a competitive advantage simply because they can move faster.

They’re not better resourced. They are just less encumbered.

In a world where a customer can switch to whichever provider will “just get it done,” a 10x implementation speed reduction would be a massive competitive weapon.

.

Protecting Time: Why the Communication Burden May Be the Culprit

Here is the uncomfortable truth: almost all of our comms tools (chat, channels, email, SMS, calendar pop-ups, meeting reminders, phone calls, social media, etc) are designed around interruption. They are optimised to get your attention, immediately. Whether truly urgent or not!

What’s the opposite of a competitive weapon?

We’ve become so distracted by notifications that even if we’re not enveloped in meetings, we almost never get any real time in the zone. Yet that is exactly what makers need to make. Deep design or think time, which doesn’t thrive in 15-minute slices squeezed between pings, responding to emails or idle chats.

A couple of weeks ago, a friend of mine was co-opted into a team developing a new communications app from the ground up, targeting corporate, enterprise and government clients. We were talking about ways of ensuring the app wouldn’t be just another derivative of all the other comms apps that have come before it.

Rather than just cloning the use-cases of other platforms, I suggested a contrarian angle. Rather than seeking attention, build an app that protects workers’ time and attention.

Imagine a platform that considers the content and context of messages, is aware of what the worker needs to deliver right now, and delays notifications deliberately / selectively. One that understands whether someone is in “maker mode” (ie operates best in 4 hour uninterrupted windows) or a “manager” (ie operates in 5-15 minute slices), what deadlines they are working to, and what phase of work they are in. During a 4-hour design block, the comms platform might quietly queue anything non-critical. During a scoping or discovery phase, it might allow far more real-time interaction.

An app where it’s not just you that controls the settings, but your dependent stakeholders (eg your boss). This would help to overcome complaints from peers about not responding to their email or pings faster. This removes the social burden of responding.

.

If Speed Matters So Much, Why Aren’t We Building for It?

In OSS/BSS delivery, a single engineer getting 4 uninterrupted hours on a hard problem can advance a project more than 4 weeks of fragmented half-hour time-slices ever will. Yet our current tools and cultures are almost perfectly tuned to prevent that from happening.

And yet, if you look at how most telcos are designed, speed is rarely the primary (or secondary, tertiary, etc) concern. We build layers of process around our OSS and BSS to ensure nothing breaks. In doing so we quietly accept that almost everything slows down.

What if we treated speed as a first-class design principle? What if every major initiative had someone explicitly responsible for reducing time-to-value, not just delivering on scope? What would it take to reduce a simple activation from 80 days to 8 days?

In the end, my friend didn’t care which carrier had the nicest architecture diagram, features or even brand value. He ultimately cared who could get his business upgraded fastest.

Feel free to share your thoughts in the comments or via a private message in the contact form below. We read each one.