CW@60: What sport taught me about technology, and vice versa

From engineer to translator

I started out in software engineering but moved fairly quickly into architecture and consulting. What pulled me in was turning a business challenge into a technology solution that actually delivered the outcome the business needed. That’s been the constant thread ever since.

One of my first jobs was at Electronic Data Systems, working with government statisticians in London. It was old-fashioned, almost quaint by today’s standards. There was even an annual cricket match between the statisticians and the IT team, at which I was once told off for being too competitive, which was code for “don’t bowl out the lead statistician”.

Soon the projects became larger and the consequences more tangible – transforming the way goods moved between the UK and Europe, or architecting the systems behind the tax self-assessment filing peak when millions of returns land in the final days before the deadline.

I’ve also spent a good part of my career making sure Christmas runs smoothly, building Royalmail.com and Parcelforce.com to withstand seasonal peaks and helping Waitrose make sure it has enough turkeys.

All of this experience taught me that success is never just about the technology – there is always a business outcome to deliver.

One of the most ambitious projects came when the government was preparing to revalue domestic properties as part of proposed changes to council tax bands. I was asked to work out how geospatial data, property records and imagery could tackle the problem at enormous scale. We managed to revalue and band the country just before the government shelved the policy, so the work was ultimately never used.

It might sound strange to include an abandoned project among the formative experiences of a career, but it taught me something important – technology careers aren’t just made up of successful launches. Sometimes the most interesting engineering happens when you’re asked to take a problem that appears impossibly large and make it practical.

I still do that job today, just at a larger scale, and these days sport has found its way back into my working life too. I never expected to end up building technology for the sports I grew up playing, but I do now. There’s something special about seeing those two parts of my life finally converge.

Riding the waves

I’ve been lucky enough to live through several distinct technology cycles, from e-commerce to cloud and now AI, and I count that as a privilege. Each cycle has changed the industry. But I’ve also watched us repeat a surprisingly consistent behaviour – when something new arrives, we become so excited by its possibilities that we temporarily forget the discipline we developed during the previous wave.

“Some of the best sport coaches I had were great at reading a team – knowing who needed a clear instruction and who needed space to work it out for themselves. I didn’t understand how rare that skill was until I had to learn it myself, the hard way, running large and complex transformation programmes”

Steven Webb

Cloud is the clearest comparison with what’s happening in AI today. I spent years trying to talk retail clients out of simply lifting their legacy systems into the cloud and calling it done. It was tempting to pack up the old datacentre, ship it to someone else’s and keep everything exactly as it was. But that was just moving the furniture, and it usually cost more than staying put. The real value only showed up once we persuaded them to rebuild on cloud-native, so the platform could flex to seasonal demand.

I hear the same conversation now with AI, just with different words. Too many organisations want to drop it into what they already have, rather than transform how they work so they can use it properly. And we’re relearning another cloud lesson at the same time. It took years of bill shock and sprawl before FinOps brought proper discipline to cloud economics. With AI, the unit of consumption has changed from compute to tokens, and we’re now having to develop the same discipline around tokenomics.

I find the pattern more endearing than frustrating. Experience doesn’t stop you making mistakes with the next wave. It just helps you recognise them a little earlier.

The return of the all-rounder

I guess I was an all-rounder in sport, splitting my time between football, cricket, tennis, golf and rugby. When I started in software, the industry felt much the same. It was the age of the generalist. One person could reasonably be expected to understand the business problem, consult with the customer, design the architecture and build significant parts of the solution, software and infrastructure alike.

As technology became more powerful, it also became enormously more complex. The industry responded by specialising. Engineering split into ever more specific disciplines – front-end, back-end, cloud, data, security, platform engineering and many others. That specialisation created real depth, and let us build systems of a scale and sophistication that would have been unimaginable when I started.

AI is now shifting that balance back the other way. I saw it properly for the first time when we had to move one of our platforms onto a new data provider between the Rugby World Cup and the Six Nations, a switch that would once have needed a DevOps engineer, an API expert, a data specialist, and weeks we didn’t have. With AI alongside, we did it in a matter of days.

That doesn’t make expertise less important. If anything, it makes knowing what “good” looks like more important than ever, because the danger is confusing the ability to produce something with understanding why it works.

It’s also changing what a young engineer needs to learn, and how, since a lot of the narrow, repetitive work that used to build judgement is quietly disappearing. The opportunity, if we get it right, is a new generation of technology all-rounders who combine that breadth with the discipline the last 20 years of specialisation taught us.

Full circle

Some of the best sport coaches I had were great at reading a team – knowing who needed a clear instruction and who needed space to work it out for themselves, spotting the moment to step back rather than step in. I didn’t understand how rare that skill was until I had to learn it myself, the hard way, running large and complex transformation programmes.

My view of technology leadership has changed in much the same way. Earlier in my career I probably thought being a technology leader meant having the answers. However, through experience, and watching those coaches, I’ve learned that leadership is much more about creating the conditions in which other people find better answers than you could find yourself, and that’s what actually builds a high-performing team, on a pitch or in a project.

I’ve gone from an Amstrad to satellite imagery, cloud computing and large language models, and the tools I use bear no resemblance to the ones I started on. But the underlying job hasn’t changed nearly as much – understanding what actually matters, delivering business value and finding the best technology to solve the problem.

I can still picture sitting in front of that Amstrad, watching the screen flicker and judder as a game loaded from cassette tape, minutes ticking by before anything happened at all. These days I watch AI build something useful before that tape would have even finished loading.

My kids have never waited for anything to load in their lives. I wonder what technology will look like by the time they’re old enough to look back on their own childhoods and reflect on how far it’s come.

Steven Webb is chief technology & innovation officer for Capgemini in the UK.