← Speaking

Leadership, the singularity and large language models

Aug 2023 ยท Telia Company · Podcast · 43 min

A leadership conversation about running a transformation, and about the mistake inside it. A leader owes both enablement and thought leadership, and staying technically current is part of the job. Transformation should never end, because continuous improvement belongs in the DNA. Then the candid admission: too much was attempted at once, which is neither deliverable nor fundable at that size.

Asked by my kids what I do, I say I bring the internet to people, and it stays satisfying to watch customers use connectivity for their own lives and their businesses. What frustrates me is time spent inward, resolving frictions or perceived frictions, when the energy belongs with customers and with getting things done. Salary and the rest are hygiene factors. The reward is seeing tangible progress, happier customers, better products reaching the market.

A leader owes two things, and we tend to talk about only one. The first is enablement: build a team diverse in every dimension, not just male and female but age, competence, background and culture, then remove the roadblocks, create clarity and let the team succeed. The second is thought leadership. We have to be competent people with a lifelong learning mindset, humble enough to accept that being on top of things last year means nothing this year unless we kept up. Our framework has four verbs, engage, envision, enable, execute, and I cannot pick one. The role requires giving the company direction on what a digital telco is and how it works, staying mindful of what is broken today and fixing it, and getting things done.

On how we are organised, the country is the leading dimension, because the customers and the revenue are there, and winning our customers' minds and money in the market is the only priority. What my organisation adds is scale and synergy: if a market needs a product, I can look at what already exists and plug it in faster and cheaper than building it again. There was a misconception worth correcting, that we would impose a target platform or architecture on someone. We invest on a business case, full stop. If I can meet a demand with something we have, we do. If a market genuinely needs something different and it pays off, we build it. To make that real we changed the structure: every market now has its own CIO, sitting in my organisation but close to the market leadership, and every product has a local product manager accountable along the whole journey, linked to a common product manager holding the product core. Complexity is no advantage and it kills us a little; scale is the advantage. The hyperscalers build one product and sell it across the planet, and local difference becomes a parameter: price, promotion, language, sometimes branding. Changing a price should be a parameter change, never an IT project.

Transformation never ends, and it should not, because continuous improvement is one of the most fundamental things to get into our DNA. Are we ever satisfied with the customer experience? We should never be. If I am bad today and good the day after tomorrow, I should still want to be better the day after that. The mechanism is simple: something is broken, an outage, a complaint, an issue visible before it lands. Take it up rather than push it away. Work out what removes it, which becomes an initiative. Quantify it, because most of them cost money. Then take a conscious business decision about which ones we do and in what order, to get the maximum value out.

Two learnings from three years. The good one is that we are on track, which is outstanding for what is one of the most daring transformations in the industry. We set daring goals, two billion of savings by 2023 and four billion by 2025, and we also defined the underlying drivers, which hardly any company I have seen does: how many products we take out, how many platforms, how far we consolidate partners and system integrators, how far incidents fall, how far call centre volumes fall. We report them internally and to investors, because it keeps us honest and shows where progress works and where it does not. The phase has now shifted: the foundation is built, and it is time to monetise and scale what we have rather than invent more. Customer value management is the example, built and nowhere near exploited.

The harder learning is mine. We have been almost too daring, and I have been too daring in the number of things I wanted to do at the same time. Changing a company of this size, with this complexity, in a short time is genuinely hard, and it needs people brought along through communication and change management, which is not a one-year or two-year journey. Trying to transform everything everywhere at once is neither doable nor fundable. So we scale back to the must-win battles, the network transformation and the fixed network quality work in Norway, and we scale the foundation we have already built.

On people, the skills change as coding automates. The shift is from manual work toward design and exception handling, and toward the people who unlock the technology for productivity. We put a learning platform in place and opened it to anyone, and the honest verdict on uptake is okay, and it could be better. If a day has eight hours and none of them are for learning, people will do it in their own time, which some of us do. My vision is data-driven talent management, the same way we do customer value management: rather than a job title in a system, see what someone has actually contributed, what training they have taken, what certifications and real outputs they have, and offer them the next thing on that basis, so people move by capability rather than by role.

Nobody can see ten or fifteen years ahead, and people like Ray Kurzweil who put a date on the singularity are braver than I am. What I do see is that every major technology shift removes some work and enables a new set of use cases, new talent and new jobs, with tenfold and hundredfold productivity behind them. My advice is to understand these technologies properly rather than superficially, including their limits. A large language model is a trained model, more sophisticated with attention and the rest, and the restrictions in its training data flow straight through into the answers it gives you. It is not awareness of truth. It is a very large repetition of what the training data put in.

Frameworks

Watch the recording ↗

rainer-deutschmann.de