Four in a Room of Sixty-Four

The switching technology under the fixed-line network was approaching end-of-life. Maintaining that generation was becoming more expensive than migrating to a new one. From a Telekom-internal perspective, this was a cost-pressure decision: All-IP had to come at some point, and the maths said the time was now.

From the perspective of the organisation that had operated the fixed-line network for decades, it was something else.

I came in as interim product manager for the entire DSL product portfolio. 32 months. My brief contained two threads that later turned out to be a single thread: the migration to All-IP — and the build-out of a process setup, across all sales and service channels, that could carry the migration. Stefan, a process architect, took on the second half with me. We met there; the friendship came later.

The problem wasn't the technology. All-IP worked. Equipment worked. Migration paths existed.

The problem was change. The sales and service organisation had built up over decades a model of the world in which voice and data are separate, mutually independent services. In that model you could promise a customer a voice line without it having anything to do with the bandwidth of their data connection. In All-IP that no longer holds. Voice and data share the same channel. The minimum bandwidth available to a customer co-determines how many simultaneous voice channels are possible. Voice runs against data throughput.

Bringing this dependency into a sales organisation that had spent thirty years selling the opposite — impossible. Not in the sense of difficult. In the sense of: in the time available, with the available means, and without destroying ongoing operations, retraining the heads was not the lever.

The setup that emerged can be put in one sentence: the new dependencies live in the systems, not in the heads.

Concretely:

When a sales agent sells a DSL product to a customer, the system checks in the background whether the voice-channel configuration is compatible with the bandwidth, and excludes invalid combinations. The agent doesn't see incompatible options — the friction is removed before the click.

When a service technician records an incident, the ticket system itself prompts for the data that has become diagnostically relevant in the All-IP world. The technician doesn't have to know why these data fields are now important; they just have to populate the schema.

When a customer orders online, the same checking logic runs in the background — on standards that are identical across channels, so that the same order ends identically through the phone channel, the online channel and the retail channel.

The end-to-end process mapping (BPMN) across all channels, which I set up together with Stefan, was the carrier of this logic. It did not explain the new world. It made it invisible.

1. In long-lived migrations the organisation's mental model is the constraint, not the technology. Whoever wants to retrain a workforce with thirty years of ingrained logic in the time available loses. Whoever builds the new logic into the systems and lets the workforce keep operating in the old model wins. Friction-engineering is the name of that method, and it is — especially in regulated, long-grown organisations — the only way that holds under live operation.
2. Four to sixty isn't a workshop. It's a diagnostic. When the externals are the majority in the room, the organisation isn't learning. The consulting market is. That isn't morally bad, but it has to be processed in the setup decision: what doesn't fit into internal heads has to fit into internal systems.
3. The lifespan of a setup is the most honest assessment of its quality. Sixteen years of load-bearing under live operation, through two technology generations, is the kind of evidence that doesn't show up in a quarterly report and doesn't decorate a consulting deck — and that says more than both combined.