How a Severed Fiber Optic Cable Sparked My Passion for Data

Some people find their subject through their studies, others through a particular job. For me it was a mix of both, plus a bit of stubbornness. When I work with analytics and AI today, there is a fairly straight line leading back to a desk in the Master Service Management Center of Deutsche Telekom in Bonn. This is the story of how it all began.

Faults, Root Causes and a Constant Race Against Time

My working day on the Telekom Campus revolved around one simple question. What is broken, and why? I analyzed faults, identified root causes and fixed problems remotely whenever possible. When that was not an option, I coordinated with the field technicians so they could step in on site. Some things simply cannot be repaired remotely. A severed fiber optic cable, for example, cannot be patched over the keyboard. It takes a splicing machine and a lot of patience.

The job had its own rhythm, and the standards in our department were always high. It was not just about fixing faults once they occurred. The real goal was a different one. We wanted to spot patterns in the faults and solve problems before they ever reached the customer. After all, nobody likes it when the internet goes down or fails to deliver the performance they expect. Being reactive was the duty. Being proactive was the ambition.

An Idea Born in the Lecture Hall

Alongside work, I was in the middle of my studies. That is where I learned to work with Python, and that is exactly where the penny dropped for me. We were sitting on a mountain of data. Measurement data from the devices at the customer’s home, day after day, in volumes that are hard to even imagine. And most of it was just sitting there.

My thought was simple. Why not use this data to automatically detect anomalies in the measurements? A kind of early warning system that would raise the alarm before something actually broke. Precisely what our department’s goal really called for, only data driven rather than based on gut feeling.

So I got started. I read up on the possibilities and wrote emails. Many emails. To literally everyone at Telekom who might somehow be involved. Anyone who has ever tried to organize something across departments in a large corporation knows what I am talking about. It is no trivial exercise. But eventually I reached the right address, the BI department, which was also based on the Telekom Campus.

From a Gut Feeling to an Official Project

After a fair amount of back and forth, the time had finally come. An idea turned into an official project. My vision was to use the measurement data we received from the devices at the customer’s home to make predictions. Specifically, it was about the probability that a component would fail in the near future. Predictive maintenance, long before the term started showing up in every other presentation.

This must have been 2015. My approach was to train a perceptron, in other words a binary classification based on linear trends. Today that sounds almost quaint, but back then I had read about it in a book and it seemed like a sensible first step. Above all it was accessible, and I understood what was going on under the hood.

You have to picture the context. At that time very few people in my surroundings had engaged with supervised and unsupervised learning. It was something special, almost exotic, and the pool of experience was correspondingly thin. There were no ready made pipelines, no tutorials around every corner, no colleagues in the next office who had already done it three times over. You had to work much of it out yourself, and that was exactly what gave it its own particular appeal.

When It Is Not the Technology That Slows You Down, but the Organization

In the end we were only able to build a proof of concept. Not because the idea did not hold up or because the technology failed, but because of internal company politics.

The problem was as mundane as it was typical. The measurement data belonged to another department. It was already stored there in a Hadoop cluster, prepared and available. But they would not grant us access. From their perspective, it simply was not our job to do this. With that, the door was closed before we could really walk through it.

A shame? Absolutely. But that is how it goes sometimes in a large corporation. The data is there, the use case is there, the motivation is there, and yet in the end a question of responsibility decides the matter. That experience was, in its own way, just as instructive as the technical part. Using data is not only a technical problem. It is at least as much an organizational one.

What Has Stayed With Me

Despite the abrupt ending, I took something from that project that has stayed with me to this day. I developed a feel for the power that data holds when you use it the right way to drive improvements within a company.

That is exactly what sparked my passion. It motivated me to keep going, to stick with it and to dig deeper, and that is ultimately why I have ended up where I am today.

Today I help companies get more out of their data. That is precisely what brings me so much joy. There is hardly anything more rewarding than watching a company take the leap and turn its data into real value. The moment when raw numbers suddenly become a decision, an improvement or a tangible benefit fascinates me just as much today as it did back then at my desk in Bonn.

The lovely thing about it is that I still enjoy it just as much as I did back then, when everything was new. In this field you never stop learning. And the current developments in particular show, at an impressive pace, how techniques and methods keep evolving. What was a bold perceptron in 2015 is almost a footnote today, and tomorrow the world will look different again.

Perhaps that is the real lesson from this story. It pays to stay curious. And sometimes an entire career begins with a single question on an ordinary working day. We have all this data, so why are we not using it?