The next thing should be easier than the last

The last few weeks have made me think a lot about what scale actually means.

In a very short period, On entered football with Kylian Mbappé, Thierry Henry and Sydney Schertenleib, announced our move into golf, and at Investor Day talked publicly about the ambition for the next chapter of the company. From the outside, these are obviously exciting moments. New sports, new athletes, different communities and entirely new ways for the brand to show up.

I see another side of them too. Every time a company decides to do something new, a surprisingly large part of the organisation has to respond. Product, commerce, supply, content, customer service, data and technology all get touched. Something that appears externally as one announcement creates hundreds of decisions underneath it.

A few years ago, a moment like the football launch would have felt very different to me from a technology perspective. We had more tightly connected systems, more places where one process waited for another and more things that could become a bottleneck when demand changed suddenly. A major launch required a lot more coordination and, if I am being fair to the technology we had at the time, a little more hope than I would have liked.

We have spent years changing that. More streaming, more asynchronous flows, better separation between customer experiences and the systems running behind them, stronger customer and data foundations. Most of that work is almost invisible when things go well, which is exactly how it should be.

But when the company suddenly becomes more ambitious, you discover what all of that work bought you.

It has left me with a question I keep coming back to: did doing the last thing make the next thing easier?

I think it should.

Growth has a habit of leaving complexity behind

There is a pattern I have seen in almost every growing organisation.

Something new appears and a team needs a capability quickly. There is a good product in the market, so a vendor gets added. Another part of the company develops a similar need six months later and chooses something slightly different. A new market needs a variation because the existing process does not quite fit. Another channel arrives and needs another integration.

There is usually nothing obviously wrong with any individual decision. In fact, most of them are sensible when viewed locally.

The problem appears when you zoom out a few years later. There are several platforms doing overlapping things, several versions of the same information and a surprising amount of work devoted to moving context from one place to another. The complexity rarely came from one terrible decision. It came from hundreds of reasonable decisions accumulating.

This matters more when the company itself is changing quickly. I do not want football to require a football technology stack and golf to require a golf technology stack. They should feel different to the people experiencing them, of course. Different sports have their own culture, communities, athletes and expectations. If all we did was change the imagery on the same experience, we would have missed the point completely.

But that freedom at the edge should not require us to build another company underneath it.

That tension has become important in how I think about technology. I want the outside of the company to become broader, more varied and more ambitious while the machinery underneath becomes simpler and more reusable.

Truth, structure and expression

I have a shorthand I use internally which has become increasingly useful to me: truth, structure and expression.

Truth is the foundation. It is the set of things the company needs to know and agree are true: products, transactions, customer context, brand knowledge and the other basic facts on which everything else depends. I want this layer to be fairly boring. Reliable, accessible, understood, and not recreated every time somebody builds something new.

Then there is structure. This is where the company starts making sense of that truth. Business logic, rules, decisions and the interfaces between capabilities. APIs are part of it. MCPs are increasingly part of it. It is also the layer that allows software and agents to work with the company without every new application having to rediscover how everything fits together.

I spend quite a lot of time thinking about this middle layer because I suspect it will matter enormously over the next few years. If the truth underneath is fragmented and the structure in the middle is weak, every exciting new idea eventually turns into an integration project. Someone builds the thing people can see, and then a group of people spends months working backwards through the organisation trying to connect it to everything else.

If those first two layers are strong, the top can become much more fluid.

I think of that as an expression. A website is an expression. An app is an expression. A retail experience is an expression. Something we create around an athlete, a sport, a particular market or even one moment can be an expression.

Some of those things will last for years. Others may increasingly exist for a much shorter period, and I think that is going to become perfectly normal. Software is becoming cheap enough to create that we will be able to build experiences which once would have been far too specific to justify.

The important thing is that every new expression should not need its own version of reality underneath it.

Simplicity is partly about knowing what not to own

There is another part of simplicity which I have probably become more opinionated about over the years.

I do not believe companies should build everything themselves. There are plenty of things where the market is better, has more scale and where having a unique solution gives you absolutely no advantage. Use them.

But I also think companies can make themselves remarkably complicated by adding vendors without being deliberate about the boundary. You use one slice of one platform, another slice of the next, wire them together and gradually place more and more layers between the company and its own data.

The distinction I care about is whether something is utility or whether it contains part of the company’s advantage.

If it is table stakes, I am very comfortable treating it as such. If it sits close to proprietary data, business logic, accumulated judgement or something which becomes more valuable every time the company uses it, I want to understand much more carefully what we are giving away.

I wrote recently about how my own build versus buy boundary has moved, so I will not repeat that argument here. The connection to this one is simpler: you cannot make your core reusable if you have never really decided what your core is.

What AI changes is not only speed

The obvious AI story in all of this is speed.

Software can be built much faster. Small teams can attempt things which would have required significantly more people a few years ago. Existing systems can be understood faster. Ideas can become working prototypes quickly enough that it changes how you explore them in the first place.

All of that matters, but there is another part which I find at least as interesting.

Companies forget an extraordinary amount.

Think about everything created during a major launch. Decisions, tickets, code, customer feedback, conversations, incidents, documents, things which surprised people, things everyone agreed never to do that way again. Some of that becomes formal knowledge. A lot of it remains scattered across tools or in the heads of the people who happened to be there.

Then the next major piece of work begins and somebody starts looking for the person who remembers what happened last time.

The scale of context modern models can work with changes this in a way I think we are still underestimating. You can take the work of the last two seasons, or an end to end value chain spread across documents, email, tickets and conversations, and ask surprisingly simple questions of it. What actually happened? Where did we repeatedly get stuck? Which decisions kept coming back? What did we solve twice? Which assumptions turned out not to be true?

I have started doing versions of this myself and still find the result slightly mind bending. Not because the model somehow produces perfect truth. It does not, and people who understand the work still need to challenge what comes back. The interesting part is that you can get a coherent view of years of organisational context quickly enough to use it as a starting point for thinking.

That means the organisation has a much better chance of remembering what it has already learnt.

A new sport should therefore leave more than a new sport behind. A launch should leave more than a launch. Each difficult thing the company attempts should leave better context, stronger capabilities and fewer things that the next group needs to discover from scratch.

I wrote before that work should leave something behind. I am starting to think the same test should apply to growth itself.

How much ambition can the company absorb?

Technology organisations have traditionally had fairly clear ways of talking about scale. Can the systems handle more traffic? Are they reliable and secure? What do they cost? Can the team deliver what it is committed to?

Those questions have not become less important. If anything, the last few weeks have been a nice reminder that invisible technology only stays invisible while it works.

But there is another measure I have started to care about alongside them:

How much ambition can the company absorb?

Can the company enter another sport without creating another technology estate behind it? Can a team build a completely different customer experience while reusing the capabilities underneath? Can experimentation at the edge become much faster without every experiment leaving permanent complexity in the middle?

And perhaps most importantly, can the ambition of the business grow materially faster than the systems, people and coordination required to support it?

That has become a much more interesting definition of scale to me.

It also changes what I value in a technology organisation. Excellent engineering is obviously fundamental. Reliability, security and cost discipline are not negotiable. But I also want people who know the business extremely well, who genuinely enjoy partnering with it and whose instinct when faced with an ambitious problem is to understand it deeply rather than immediately defend the systems they already own.

Sometimes the answer is to build something very quickly. Sometimes the answer is that we already have the capability and should resist adding another tool. And sometimes the request in front of you looks like a one off until you understand it properly and realise that it exposes something the whole company is going to need again.

Recognising that difference is part of the job.

Seeing the pattern

This connects to something I wrote recently about leaders needing to stay close enough to the work to notice when the operating principles change.

I feel the same way about scale.

From far enough away, football can look like one programme. Golf is another. A new market is another collection of requirements which eventually lands with Technology to support.

Once you get closer to the work, the more useful question becomes: what should we learn or build now so that we never have to solve this class of problem from scratch again?

That question is difficult to delegate entirely to any one function because it requires seeing the pattern across the company. The teams closest to an individual problem will naturally solve that problem. Someone still needs to recognise when the solution should become part of the way the organisation works.

The next thing

I like moments when On stretches into places it has not occupied before. The outside becomes more interesting. New people discover the company, different communities interpret the brand differently and we get to learn things we could not have learnt by staying where we were comfortable.

I do not want technology to make those experiences uniform. I want almost the opposite.

I want strong truth underneath them, clear structure connecting the company in the middle, and as much freedom as possible in how we express ourselves at the edge. And when we do something difficult, I want more of what we learnt to remain available for whatever comes afterwards.

That is what scale has started to mean to me.

Not simply whether the technology can handle more, but whether the company can attempt more without becoming proportionally more complicated.

And whether the next thing is easier because we had the ambition to do the last one.