CDO Sydney Summit

Paul gave the opening keynote at the 2017 Sydney CDO Summit on 15 March, on 'Change, not change management'. A write-up of his speech appeared in ITNews. You can watch Paul's speech, access his slides, and read a transcript of his comments, here.

View transcript

Paul Shetler: So I want to - the title is ‘Change not change management’. And I think that sort of gives you the tenor of what I want to talk about here: not incrementalism, but actually going ahead and making the really serious changes to an organisation, which we need to make to ensure it survives and thrives in the digital age.

So first: definitions. I want to get a couple things out of the way. So when people use the word, when organisations use the word ‘digital,’ what are they really trying to say? You know, why not just use ‘e’? Or ‘online’? There’s something specific that people are trying to drive at, when they use the word digital. And I think they’re trying to tell us, and their employees, something about the way they’re structured, and how they work.

And the first part really is that Internet is the primary channel. It’s a recognition of what’s happened in the rest of the world. And it’s the primary channel for delivering and for requesting services. And they know that their services are going to be judged by the standards that others have set. They know that they’re going to be compared to Uber, and they’re going to be compared to Amazon, and they’re going to be compared to Airbnb, and Netflix, and Google, and so on and so forth. So, you know, having to have a solicitor to figure out what button you press next at the end of some website? That doesn’t work. It doesn’t work for anybody.

It also means that they operate at an Internet quality and speed. They develop things quickly. They learn continuously. They pivot when they need to. And they constantly take on information in real-time, to learn how their users are using their products. This is not sort of long-term, Soviet-style planning. This is responding to the environment that they actually operate within. And I guess one of the points was made earlier, by the first speaker, about deployment and about automation. Google and Amazon deploy thousands of times a day, thousands of times a day. At DTO, we didn’t deploy thousands, but we did employ hundreds of times a day, hundreds. Now, you compare that to a traditional brownfield organisation - and that doesn’t have to be government, by the way, that can be a bank, or a brokerage, or anybody else - and you’re talking about release cycles of six months. Once, every six months, versus hundreds or thousands of times a day. And that’s what I mean when I’m talking about Internet quality, and Internet speed.

And lastly, really importantly, they’re focusing on what the user is actually trying to do. Not the internal structures. They’re hiding all the complexity, they’re hiding all the supply chains, they’re hiding all their innards from you. If you had to know all the complexities of Amazon’s physical and financial supply chains, you would never use them. They’d go out of business immediately, right? They hide that from you. But unfortunately, you know, lots of large legacy organisations don’t. They delight in their own internal organisation, and they think you should, too. But actually, that’s not how it works.

Finally, they use Cloud, so they can focus on service design, and not on CAPEX. By this I mean, you know, think about say 15 years ago, if you had a start-up, among the first things you’d have to think about were, ‘How am I going to pay for my Oracle licences? How am I going to pay for my Microsoft licences? How am I going to pay for my Solaris licences? How am I going to pay for my tin?' That’s all CAPEX. That takes a lot of time, that takes a lot of money. That means lots of governance, that means lots of up-front risk. That means you can’t pivot. That means you can’t do all the things we just talked about. Moving to Cloud changes the whole economics of the material circumstances under which a lot of bureaucrats work. It means that they can actually now start being flexible, they can actually start learning from users, they can actually now start incorporating that into their planning cycles, and it means they can take all the money they were spending on these very expensive internal processes, and they can focus it on actually building the best products in the world.

Now, what do users think about, when they hear about ‘digital’ or ‘transformation’? Not, this sort of ‘company telling us about itself, and how it works’ - but what does the user think? I think they mean something really different.

They’re talking about their expectations. They’re not talking about a process, they’re talking about their expectations. And they’re talking about the product. That’s what they’re talking about. They want something which is simple, which is clear, which is fast, and which meets their needs.

And by that, I also want to be clear, it’s not about ‘engagement’. I hear this a lot, ‘We’re going to build a really engaging platform. We’re going to build a platform for citizen engagement. We’re going to engage, engage, engage, engage,’ right? And when I was at the Republic National Bank in the late 1990s, and when I was setting up our first - in those days, it was called ‘e-banking’ - subsidiary, it was called ‘Republic Interactive’. The name is instructive, because it gives an idea of what people thought people wanted from digital: ‘interactive!’. People thought - executives thought - users wanted to interact with the bank. And they even said to me, ‘Paul, won’t it be wonderful, won’t it be wonderful - people can actually interact with their bankers! It’ll be great.’ Nobody wanted to interact with their bankers. They weren’t that interesting. You know, people want to interact with people they know and they like. That’s why Facebook is popular. But interacting with your banker? Not so much.

What people want - they don’t want to engage with your brand, or your agency. They just want to get something done. They want to transact. They want it to be seamless. They want it to be frictionless. They want it to be easy. And they want it to be - they want it to get to the point, and the point is what it is they’re trying to do. Much more detail on that shortly. But this is really - understanding this is key to the art of digital product management. And I think it is an art, and that’s a really important part of it.

Now, a little bit about my experience. When I first started in the UK in 2014, I was working at the Ministry of Justice, and then at the Ministry of Justice, we had five executive agencies, and we had about 35 arm's-length bodies. We had a lot of - a lot of organisations were a part of this. And I asked the agencies to do three things, which they assured me they had done, but which I knew they had never done before. And the first one is getting back to what I said earlier: ‘Start with user needs’.

In Australia we have - this is the number I used to use, I think it’s actually been updated, and I think the number’s even higher - 1,524 different federal websites. That’s an awful lot of content, and sites, and places to go, to navigate through, to find out information. Now, government policy - there’s lots of government policies, and strategies that encourage new business formation. But, if you’re trying to start a business in Australia, your user journey is going to be split between federal, state and local. You’re going to do certain things at the federal level, like getting a Tax File Number, or an ABN. You’re going to do certain things at a state level, like getting various permits or licences, or whatever. And actually, because you’re probably a business with a physical location, at some point, you’re going to have to get permits and licences at a local level, too. But nowhere, nowhere - and I challenge anyone to prove me wrong - is there any place you can go to see, ‘What is this user journey? What are all the things you actually have to do?' There’s 1,524 federal websites, I think about 3,000-4,000 state websites, I don’t know how many local websites, but let’s say there’s about 7,000 websites you’ve got to go through, to find out this information. There’s no golden thread that you can use to go through all of this. So how do you know, actually, that you’ve done everything you need to do to be compliant? Really basic, simple question. It’s got nothing to do with whizz-bang data analytics. It’s just about how you represent yourself to users. How do you know?

Well, the simple answers is, people don’t know. We did a lot of research with users. And a lot of this quote. This guy said basically - he’s a serial entrepreneur, he’s opened a few business, he said, ‘You know, if you can afford it, pay an expert to deal with the government. It’ll bury you, and distract you from your business’.

Now, I think a clear test for service design is, ‘Can a user go through something the first time, unaided?’ And I think if they have to go to an IFA, or a solicitor, to figure out what to do next, you can probably do better. Again, keep in mind: this guy does not want to engage with the agency. This guy does not want to engage with the brand. He just wants to get a business started. That’s what I mean when I’m talking about the need. That’s what I mean when I’m talking about the outcome. He doesn’t want this particular licence, he doesn’t want that particular tax number. He could care less.

Secondly, I asked agencies to take a leaf from start-ups, of which there were quite a few in London, and to start using MVPs. Minimum viable products, it’s a way of learning really really quickly, instead of long requirements-gathering sessions, and so on and so forth. Put things out there, and start seeing, empirically, ‘Is this meeting a need? Is it not meeting the need? Where are they falling off? Do they like it? Do they not like it?’ Whatever, right. You do that, and you also simultaneously reduce delivery risk. You chunk big projects down into very small pieces, and you can incrementally deliver them very, very quickly. That reduces risk, that increases learning, and it allows you to maintain a very, very fast pace of delivery. Pace - when you’re talking about a brownfield transformation - pace is absolutely essential. You have to keep the pace going, because the faster that you’re delivering the right thing, the more political capital you’re going to be building up, and you keep people interested in what you’re trying to do, obviously, the more political capital you’re building up. When you start slowing down is when bureaucracy, in whatever form it is, in whatever organisation it is, will start to congeal around you, to slow you down. It’s important, it’s massively important.

Now, I’ll give another concrete example of what I mean here. When I was in the UK, at the Ministry of Justice, we delivered four of the government’s 25 digital exemplars. And these were, you know, touted by GDS as end-to-end transformations of fundamental government services. They were the top 25 by transaction volume services that people were being offered by the British government. We had four in the Ministry of Justice. And one of them was civil claims. Lots and lots of people in the UK like to make civil claims against each other. They like to take each other to court. So (laughs) our job was to simplify that, make it drastically easier. And yet - I think I was like ten days into the job, as well, like, a week and a half I was there - I had a product manager for this project come in, and he was almost in tears. He was very emotional. A really smart guy, but he was like, ‘Paul, you know, I don’t know how we’re going to do this. We’ve got 18 months. I don’t know where to start. I don’t know where to end. I don’t know how to go through all of this. I’ve all this bureaucracy being thrown at me, I have all this governance' and they're starting to be absorbed by the Borg, it’s starting to be very Waterfall, we’ve got all these digital professionals from the outside who are used to this agile way or working, but they’re sort of being pulled into this end-to-end big-ness. And he didn’t know what to do next. And so I had to go back to my management, and say, ‘You know what? We’re not going to be able to make that. We cannot do that. This will not happen. There’s no way we’re going to be able to make it in 18 months, not end-to-end transformation, not that kind of thing. We’re going to have to do something different.’ And so I pressed the big red button, and reset the project. (Loud band from mic) Reset the projecct. Bang! Sound effect. Appropriate, right? And I said, ‘We’re going to do something different. We’re going to look at that service map, we're going to see the complexities there, and we’re going to start saying, ‘Well, what are the parts of it that really are causing the most pain to users? Also, what are the volumes there? Where are people falling off?’ And so on and so forth' so we could identify where the highest priority things were to fix.

And we said, ‘We’ll start with that one first. Then we’ll do that one. And then we’ll do that one, and then we’ll do that one.’ Transformation by chunks, transformation by slices, whatever you want to call it. And these were all little MVPs, we continued to iterate them, and then we added them all together. At the end, we delivered the entire thing. And we did deliver the entire thing. Like I said, in fact, we delivered four exemplars, more than any other government department did, and four delivered live, because at GDS, we had different stages of acceptance, ‘Discovery, Alpha, Beta, Live,’ most departments didn't get past Beta and we got to ‘Live’ in every single one of them. So this does work, this does work. We also had a much happier team. We didn't have people coming into my office crying, frustrated. People were actually able to work the way they wanted to work in a kind of digital, lean way.

Third, as you’re delivering these things, as you’re chunking things down, it doesn’t really matter, you know, you’re cutting your risk by delivering smaller things, so the impact theoretically will be smaller if you fail at something, and that’s good, but if you’re still stuck on a sort of timeline, of it being linearly built this way, if you’re still thinking you're delivering an aircraft carrier, or a nuclear power plant, and you’re still planning that way - and, by the way, that’s an appropriate way for doing ceratin IT thimgs, and I'm not putting it down, I’m just saying that there are certain types of problems which are new, and novel, and user-facing - then how do you pivot, right? Every single project, when it first starts out, has a whole bunch of assumptions. You think you know a lot, when you first start these things, but actually you don’t. You know very little. That’s when you know the very least, at the absolute beginning. You have to be able to pivot, and change, and move - in other words, be agile - in the course of these things.

I’ll give an example very briefly, of limited power of - lasting power of attorney, which was one of the four exemplars we delivered. When we first started out, we had a public servant who was very used to PRINCE2. He loved PRINCE2. He loved his big papers, and everything else, his risk registers, and so on and so forth. And he was like, ‘You know what? I’ll try this agile thing’. And he was very glad he did, because he found out very early on that we were making some false assumptions, which would have led us to deliver the wrong thing. And yet, if we had gone by the traditional way of managing risk and governing projects, we would have delivered the wrong thing, and wasted time and cost. We saved cost, and we delivered the right thing.

Now, all that sounds easy. Doesn’t that sound easy? Start with user needs, do MVPs, iterate wildly, and be agile. What could be easier? Actually, I’ll give you a little background to this. After I was at Ministry of Justice for a few months doing this, I had somebody from GDS pull me aside, they said, ‘Paul, I just want to let you know, we’ve never done this at scale before. We don’t really know what we’re doing. That’s why we hired you guys to come in here! Because we know it’s a landmine, and we want you to run through it, and see all the things that are going to go wrong. And you’ll tell us, and then we’ll start fixing the organisation.’ And that’s what I want to talk to you about next.

The first thing I think that’s really important to get across is the iron lock of bureaucracy. Every bureaucracy’s first goal is to preserve itself, in its current form, with its habits and policies and hierarchies. You’ve heard the line, ‘We’ve always done it this way’. If you’ve worked in government, if you’ve worked in a large bank, anything like that, you know it’s true. Probably one of the reasons why IBM has hired a CDO.

I’m going to introduce you all to a little artefact I discovered when I was in government. We call it ‘The Triangle of Despair’. Each side of this triangle really reinforces the others, reinforces the paralysis which is induced by the other two. It is positively fiendish, and it’s the main reason, actually, why change can’t be incremental or slow. It’s the way that the bureaucracy reinforces its iron law, and it’s all based on the economics of large CAPEX, which make no more sense in the digital age. So this spell can indeed be broken, and I’ll tell you how we did it.

The first side is made up of inappropriate procurement: policy and practices. So here’s where I’m talking about: putting everything out to tender, expecting a large vendor to take care of everything for you. Waiting six months to bring in some talent, that will help with a few sprints that last all of eight weeks. Limited choice, delays, expenses. And this is the bane of every single large, deskilled organisation, right? In the UK, we used G-Cloud to help fix this. In Australia, we built the Digital Marketplace to help fix this, coupled with procurement reform, which is absolutely essential. You’ve got to get this fixed. Recently, I had a meeting with a number of banks here in Australia, they were talking about how they could bring in talent to help them with cyber, they said, you know, ‘We’d love to bring in some start-ups, but, gosh, it would cost us at least ten to fifteen times the licence cost just to do the implementation.’ You have to ask yourself, ‘Why?’

Secondly, governance. Inappropriate governance is a huge bane, again, spreading out responsibility across lots and lots of people in deskilled organisations, so that no one can really be held responsible. People using sort of the PRINCE2 toolset, and every single little bit of it. No one ever uses an entire toolkit to do anything. But in governance, a lot of times, people try to. Laying on governance that's suited to certain other types of problems, when you’ve already got inbuilt governance in the Agile methodology, and in Lean, means that you’ve actually got governance working at cross-purposes. It doesn’t work, it slows you down. And again, we’re not building nuclear power plants. And in the example I gave earlier of lasting power of attorney, the civil servant who was in charge of that was a very old-school civil servant who loved heavy governance, because that was what he grew up with. When we got him onto Agile, and saw what he could do, he now gives videos on YouTube talking about Agile and scrum and culture-change. And his point is, guess what? With Agile, he has much more visibility and much more control than he ever did with his risk meetings, where people handed him 300 pages of paper, one hour before the meeting started. Much more control, much more visibility, much more transparency. I recommend it. Go to YouTube, type ‘Alan Eccles, E-C-C-L-E-S, Agile’. See what comes up. You might find it interesting.

Finally, IT. Ancient systems, wrapped in layers of contracts, integrators and outsourcers, using outdated, proprietary technologies that really don’t take into account anything that’s happened on the Internet in the last 15 years, right? So everything that [gesturing] you were talking about, IT Departments are going against that instantaneously. We saw that in DTO: across government, it’s just the standard thing. When I was at Ministry of Justice, we were trying to - actually, not trying, we delivered - a digital service which allowed people to book visits with prisoners really really quickly, with a very simple interface: ‘look at the calendar, book a visit’. To do that, we had to actually access the prisoner database. That was wrapped in like three or four different layers of contracts to outsourcers and systems integrators, that made it almost impossible for us to get the job done, but we did solve it, and I’ll tell you how in a minute.

Now, these three things all draw their sustenance from a really heavily deskilled workforce, which is probably the biggest problem that any large brownfield has. Building up capabilities is going to be absolutely essential. I don’t want to go into too much detail about this, but I think, again, just the armies and armies of relationship managers, products managers, requirements managers, and so on and so forth, but not doers, not specialists. It’s a problem. And it’s made worse by digital cultism, when you have a digital team that comes in and tell everybody, ‘Everything is wrong! You guys are idiots.’ Not even understanding how they got to the point that they got to. It just creates a stronger divide. Makes it even harder to get things done.

So it can be a very painful experience, and there will be resistance. And I can tell you, because I know this from experience. So let’s get a few things out of the way that won’t help you, that you’ve probably heard a lot about them, and I just want to knock them out. And by the way, not by themselves, or in combination. They’re not going to be panaceas.

The first is innovation studios and labs. So I hear a lot about innovation studios and labs, right? That’s not a solution. That’s not going to help you. People working in innovation studios and labs have a great time when they’re in the innovation studio, or when they’re in the lab. When they go back into the business, which is still operating according to the old way of doing things, they get frustrated, they get demoralised, and they may leave. You actually have to solve the problem. And there’s a lot of books about this type of stuff, a lot of companies have used these things. They’re pointlessly stupid. They don’t actually solve the problem.

Hackathons and other kabuki, for brownfields, don’t make a lot of sense. For greenfields, for new stuff, for ways to generate ideas, yes! For large organisations, that are bound by what I just talked about, that won’t solve your problems. That’ll show you some opportunities, but it won’t solve your problems.

Lipstick: ain’t going to solve your problem. There’s still a pig back there. Your back office is still a pig, your procedures are still pigs, your policies are pigs, your IT is a pig, your systems are pigs - no matter how much lipstick you put on it.

Agile everywhere: won’t solve your problem, because agile’s only a risk mitigation methodology for when you’re dealing with novel and unknown problems. It’s not suitable for building platforms, where you want absolute stability. You wouldn’t use Agile to build a nuclear power plant, and you wouldn’t use Agile to build a product processing system in a bank. You wouldn't. You’d be kind of crazy to do that. So Agile everywhere is not going to solve your problem.

Incrementalism, or ‘evolution’, isn’t going to solve your problem, either. Martha Lane Fox wrote a great paper called ‘Revolution not evolution,’ to Francis Maude. It caught the attention of an entire generation of digital professionals in the UK, and got us all to work for the government. The changes we’re talking about are fundamental. They go to the heart of how the business works. Incremental change - it doesn’t take on the Triangle of Despair, and deskilling. It won’t get you anywhere. You’ll get sucked right back - the bureaucracy will congeal around you.

‘Rip ‘n replace’: the only place I can think of where this ever has worked is Estonia. They did it under an absolute burning platform, the threat of Russian invasion. Most of us don’t deal with that, so most of us would go out of business.

And, two-speed or ‘bi-modal’ IT. I don't really care what Gartner and McKinsey are saying, it's a terrible idea. It doesn’t understand the nature of the problem, because digital is more than lipstick, and the back office needs massive transformation, needs massive transformation. It creates an immediate ‘us versus them’ mentality, which does not help you when you’re trying to create transformation. It leaves the old IT basically in place, and not upskilled. And it leaves you with no way to actually move things from the stage of being new, experimental, unknown and novel, through to making them more industrialised, through to platformising them. You’ve got no conveyor belt. You've just got a split - and I think that split’s something we have to get around.

So, what does work? Actually, there are things that work. We have things that work, things that work at scale, in large organisations. First, so that everyone understands what I’m talking about here, this requires huge cultural change. It requires capability uplift, because that’s what feeds the Triangle of Despair. And it requires organisational restructure. That’s why all those things that I said ealier don’t work, won’t work: because they don’t address these problems.

So firstly, you need a really clear vision that goes deep, deeply into the business. And on this board over here [gesturing], this was - you know, this isn’t a revolutionary thing, this is a common pattern now that you’re seeing across lots and lots of brownfields, when you’re talking about users coming in from multiple different channels, could even be third party providers, accessing user services, defined the way I described earlier - start a business, not just get a licence - that whole user journey, that complex one, which might traverse lots of different bits of back office. A fully automated back office, where you go from - current-state, in government, about 2% straight-through processing, to 95%, 98%, commercial best practice. Digital platforms - by digital platforms, I mean disposable, highly scalable Internet infrastructure. I mean things like notifications services from third parties, payment services from third parties, I can put a simple wrapper around it, if I don’t like it, I can sweep it out and put in another substrate. Disposable, cheap, scalable, IT, that’s what we’re talking about. And then real-time notifications, and so on and so forth. It’s the base architecture for any kind a business that’s trying to transform itself and thrive on the Internet.

And then political will to make the change. If you don’t have that, you’re wasting your time - everyone’s time - and you just shouldn’t bother. Just go quietly to the graveyard. Don’t bother.

And then ending the digital and IT split. Because, when you try to split policy out - the interface from the policy, operations and systems supporting it, you’re not actually solving the problem. You need to look at the service holistically. And the service is the interface, the policy, the people, the facilities, the systems, the procedures. All those things together comprise the service. They’re both the front and the back, and every layer in between. If you try to transform a business without doing that, you’re not actually trying to transform a business.

To talk about what I mean by this, in the UK, we actually got rid of CIOs. We had about 400. And we - I think we got down to zero, at one point, or maybe down to one. And it wasn’t a conscious decision, initially. It became one. We realised we had a layer of bureaucracy that didn't want to do what needed to be done. How did we do that? Why did we do that? Well, we looked at what CIOs normally do. We said, ‘Wow, they’re in charge of these large, deskilled organisations and in government, and I think in a lot of business, they do four important things: public-facing services, from digital to telephony to branch; ‘Mission IT,’ in the case of Ministry of Justice, we’re talking about things like court case management systems, prison databases, so on and so forth; ‘devices, networks,’ boxes, wires, hardware, telephony, all that kind of stuff; and then ERPs, payroll, accounting, whatever. And what we realised was, immediately, ‘Gosh, we have like 400 CIOs, do we need 400 ERP systems? Do we need 400 different ways that we payroll? Do we need 400 different ways to do HR across the British Government? Probably not. Let’s take that away from them. Let’s immediately simplify their lives, and put that in a shared services centre.’

And then we said, ‘Well, for public-facing services, right now we don’t have anybody to product manage them, we don’t have anybody who can do user research, or design, or development, we don’t have any Web Ops engineers, we don’t have anything like that. Maybe we should create a team in every department, and call it the digital team, the digital services team, and have it headed up by the CDO. And also, let’s look at the technology that’s in use in those departments. Why does it take half an hour for a Windows PC to boot up? Why can’t people use state-of-the-art IT?’ This. (Lifts iPhone) As the primary device. Not an add-on. We brought in people who could do that, we brought in Chief Technology Officers who revolutionised the way technology was done in pretty much every department. The Cabinet Office is a stellar example.

And then we had this zone of contention, which is [gesturing] this, what we called ‘Mission IT’. Who owns this? Well, if you’ve listened to what I’ve said so far, you’ll know who I think owns it, with what I said about services, about what services consist of. And, in fact, I made the case to our board at the Ministry of Justice, I said, ‘Well, guess what? You know, I can’t deliver that prison service - the one I mentioned earlier - I can’t deliver it, because it’s wrapped in all these contracts, and I have no say in those contracts. I have no visibility on those contracts. I can’t undo those contracts. I have nothing to do with those contracts. I have nothing to do with portfolio of development. Hmm... How can I deliver a service, if I'm only delivering the lipstick?’ And they agreed, the Ministry of Justice agreed, in fact Tom Read, his title is now ‘Chief Digital and Information Officer,’ because what they also then did was that they took all the technology bits, and they merged them in as well. Now, if you look at this picture, it looks sort of similar to the initial one, right? I’ve got public-facing services, Mission IT, devices and networks, all under one person. But the difference is, the seed of it comes out of digital, comes out of a product mentality, heavily influenced by service design thinking, not traditional IT. And that’s made all the difference, because now those organisations can actually transform themselves. And by that, I mean, instead of going through a bi-modal, sort of two-IT-speed type model, which really makes no sense, I can look at the people I have, and I can look at the problems that I have, and I can match people’s aptitudes to the right methodologies for the right problems, and I can say, ‘Well, yeah, I’m going to use Agile for those type of things there,’ and I’ll use people called ‘Pioneers,’ people who love uncertainty, people who love exploring new things. The kind of people who’d be really bad at platforms, the type of people who’d be really bad at Six Sigma, but great for this kind of stuff, and I’ll have them for my user-facing services. And my more traditional engineer talent, who don’t like uncertainty, who’d like things to be really simple and stable, I’m not going to put them on Agile projects. Why would I want to do that? They would hate it. I’m going to have them dealing with platformisation. And I’m going to have people in the middle who can take those end-user-facing services, and who can start industrialising them, turning them into real products, take them all the way through the lifecycle, before we get them to finish off with the ‘Town Planners’. I have a conveyor belt. I have a way of commoditizing stuff now. I don’t have a simple split. I can actually transform my business, instead of having a fossil bit over there, and a new bit over here.

So, I think people might have seen this, this sort of 'Look at me, I’m the Captain now’? From Pirates? I think what I’ll ask people here to do is realise that you’re a software company. And when you transform your business into a software company, you need to insource your core business, you need to take responsibility for it, because that’s who you are now. You no longer have the luxury of giving it to somebody to make it their problem. It’s your problem. That’s the nature of the transformed business. It’s a blessing and a curse, but actually it’s a lot of fun.

And, I’ll leave you with this last slide. I like the Leon Trotsky quote, ‘You might not be interested in war, but war is interested in you,’ but I didn’t think that was quite appropriate for this meeting. So I will say this, instead: ‘You might not be interested in competition, but competition is very interested in you’. If you are in a publicly listed company, you probably have some very interesting margins, particularly if you’re in a company that has not transformed, and lots of companies are interested in those, you’re not going to be able to keep your company healthy and thriving in the Internet economy unless you change the way you do business. I’m hoping that what I’ve just presented to you will be helpful to you when you’re doing just that.