Voices in DevOps – Episode 12: A Conversation with Simon Fairbairn of Igenico

Guest

Solution Development Director Western Europe for Ingenico Group. Dedicated to delivering better outcomes through technology. A seasoned entrepreneurial senior manager with 26 years’ experience in client facing environments. I am currently leading the transformation of Ingenico Group’s Western European delivery teams. My role at Ingenico involves full responsibility for the conditioning, delivery and revenue assurance of a portfolio of client delivery engagements for banking, acquiring and retail partners across Western Europe. I have in-depth knowledge in securing sustainable revenue growth, cost reduction and profit improvement, with a focus on delivering results through effective leadership and the adoption of innovative technology solutions.

Transcript

Jon Collins: Hello and welcome to this episode of Voices in DevOps, where I'm delighted to be here to speak to Simon Fairbairn - I hope I’ve pronounced your name right there, Simon - who's Head of Professional Services at Ingenico. Massive organization, lots of challenges, lots of real-world stuff. I'm really interested to hear what you've got to say about DevOps because we do hear a lot from people who are already there. They're already solving some of the issues. They don't have those big organizational enterprise-y challenges that bigger organizations have. That's why we're here.

First question, as always, is Simon, what brings you to this point in your career? What brings you to end up being Head of Professional Services at Ingenico? What's your background and what have you ended up doing now?

Simon Fairbairn: Cool, thank you. Thank you for having me on the podcast. It’s been a mixed journey. I think like most people in our careers, we don’t plan to get to where we [are]; we just find our feet taking us in that direction. I’ve been with Ingenico for nearly three years now. I look after the software development from a regional perspective. We have a group function that takes care of the core platform, but we have a lot of localization work to bring the solution out from that platform into our world. Ingenico is the leading payment provider, so you’ll know us by the payment terminals that you see on many shop counters taking credit cards and debit cards.

Prior to this, though, I spent a good number of years in consulting, running an information technology practice, and a variety of other roles before that in project management, but it’s all, largely, been around technology: largely around, ‘How do you solve problems and how do you deliver outcomes for your customer?’ [It’s] trying to see past the world where it’s only process or only technology to, ‘How do you bring the best of your organization to bear to solve problems and solve things that people really need?’

It’s been interesting because when I started some 20, 25 years ago, technology was fairly basic but it was still a big part of our DNA. The jumps, the evolutions, the revolutions in what’s possible now, has made it very interesting because technology is moving far, far faster than people. I find myself here now and embracing all the goodness that’s on offer.

It’s interesting, thinking the project manager role is–essentially, people can have all these highfalutin’ ideas but ultimately–and you use the term ‘outcomes,’ which some organizations see as a bit of a dirty word because it’s easy to say but hard to do. Your job as project manager is actually you make or break dependent on whether or not you can actually deliver, and you’ve spent a lot of years doing that.

I got a reasonable philosophy and it was actually born in my time in consulting. Customers don’t buy products, they buy outcomes. They buy it for a purpose and if you can’t understand the outcome let alone deliver it, then what’s the point? When you do understand the outcome, you do deliver against it, it’s going to be valuable to your client and if it’s valuable to your client, they’ll pay you. You end up with that win-win that we all aspire to that becomes a bit of a cliché. If your client gets something they really genuinely need and they’re paying for it, you’ll make your revenue, you’ll have a satisfied client, you’ll have a story to tell.

It’s important, whether people like it or not, but that’s the way I’ve been coaching the language in our organization. We were very much a hardware business selling products, shifting boxes. We’re trying to turn that around to one that’s understanding where our customers are at, what they’re trying to achieve, what their customers look like and how we actually become part of their organization to service that need. It sounds trite but it’s really important to think that way. If you do, you’ve got a fighting chance of being able to deliver success.

I’m going to throw in another cliché, which is ‘customer-centricity.’ Ultimately, your success is based on whether or not people can actually take money, spend money, and online/offline. If they can’t use your stuff, then we might as well all go home, basically. It’s got to be pretty user-centric, hasn’t it?

Absolutely. Payments are something that all of us do. Whether we like or not, it’s a big part of our life, but we’re trying to make it frictionless. We’re trying to make it easier for all people on the points of that journey. Fundamentally, it’s just a means to an end but when it becomes the thing that blocks you, it has a hell of an impact on how businesses earn their money. If they can’t take the money, then you’ve got a problem. You lose the customer. You lose the moment. You lose the appetite. For us, reliability and performance is a very big part of our DNA and you’ve really got to understand what that looks like.

We spend time thinking about the user experience, the user interface design because fundamentally, that’s what happens. At that 60-second moment when someone says “and that’ll be £60,” you’re on, you’ve got to perform, so it’s important.

Nobody cares about Ingenico apart from 60 seconds, little moments.

Yeah. There’s a curse we talk about within Ingenico that nobody knows who Ingenico is because we’re a B2B firm. The reality is as soon as you explain what we do and you point out our products and our services, then you can never unsee it. Next time you walk into a shop and look at the terminal, there’s a good chance, particularly in the UK, it’ll be one of ours and it’ll have our badge on it. Then you’ll start spotting them everywhere because it’s such a ubiquitous part of what we do as a utility. We’re not there to push our brand out, we’re there to deliver the experience that allows our customers to make payments.

I actually do that, by the way. I now walk into shops and go, ahh, Ingenico! For no other reason than this podcast, and as you say, you can’t unsee it.

I’m going to try and ask a question but I think it might come out as a bit of a ramble, so bear with me because I think there’s a lot of pieces here. One of the bits of the question that I’ve got to get out of my head is, is Ingenico an Edinburgh-based company because I didn’t know that, or is it headquartered elsewhere? I’ll get that question out of the way. While you’re answering that, quickly I’ll then tee-up for a longer ramble.

Okay, Ingenico is actually a global firm. We are headquartered out of France, we’re a French company. We’re the sum of many parts. Ingenico has been around for some 25, 30 years, but as part of that journey it grew at a hell of a rate. What you’ve now got, I think we are at present in 170 countries, so we’re in nearly every single country on the planet, some more overtly than others. From a Scotland perspective, we were one of the acquisitions. There’s a manufacturing plant in Dalgety Bay, where we operate, but increasingly, it moved from a manufacturing facility into more of an operational hub and a software development capability. We have a presence in pretty much every single country but we’re kind of that hidden brand. If you don’t know us, you don’t really go looking for us.

Okay, well that’s added a fourth element to my ramble, so I don’t think that’s helped at all! This is all about DevOps. We’ve got your project management background, which is all about delivery, and I think that’s really interesting, if we put that back to back with questions of DevOps. Just doing things faster doesn’t necessarily mean you’re delivering better, so we’ve got that aspect.

We’ve also got the aspect that Ingenico is a global concern, moving from, as you say, more hardware-based stuff to more software-y solution-y stuff and delivering better and better to what the customers need. Then we’ve got your own background in terms of having seen it and done it and helped other organizations actually deliver things and make a difference etc., etc.

I’m wondering, therefore, what your take is and how you perceive success. You might say to me, for example, “actually this DevOps stuff is a load of rubbish. What you really want to do is A, B, C and DevOps is just one manifestation of that.” Or you might say, “We are all in on that and now it’s a case of trying to get the organization to the right…” (how do you frame it?) There you go, I told you it’d be a ramble. How do you approach the very notion of DevOps in Ingenico?

I’ll start off my saying that we probably don’t consider it as DevOps. In my career and experience and certainly what I’ve seen in Ingenico–and I think we are further back on the curve. We’re certainly not leading edge when it comes to some of the ways of working that are being touted, explored and talked about in the marketplace. My experience is you give it six months and there’s another label, there’s another thing to talk about, but they’re all fundamentally trying to find a way to get us to work better. From coming in, and particularly from a consulting background, when we generally deal in titles and new things, the Emperor’s new clothes, actually what we’re trying to do is get more grounded and actually apply as much common sense as we can.

If we start from the outcome and work ourselves backwards, we’ve got real clarity on what it is we’re trying to achieve. Now if we know what we’re trying to achieve, we then think about how we form our assets around that in order to be effective. This is a big thing that we’ve talked about within Ingenico and something I push really hard.

The whole point of something like DevOps is not to embrace a new methodology, to move from an Agile to a DevOps to whatever the terminology. You want to get effective and you’ve got to get effective before you get efficient. We always talk about: “Make sure you’re pointing in the right direction and once you know what you need to do, then you’ll work to become more productive at it, to get better at it.”

Everything is about looking at the different parts of your process, looking at your people and culture and the way they work together, looking at your technology, to find that secret sauce that just makes it work. I’ll give you an example. When I came on board, from a delivery methodology, we were very ‘waterfall,’ very classical project management delivery. Define everything upfront, spend an inordinate time of doing it, agree that with the customer, and then take a long period to deliver it, test it and then play it back to the customer, only to discover the world had moved on and what you actually had delivered wasn’t really what they wanted, and we’ve switched that across Agile.

Now, parts of our business in other countries had taken on Agile and Scrum and had largely sheep-dipped their team into here’s now we do it. We said, well that really doesn’t work for us because what we’ll do, we’ll just end up with another flavor of the same thing... different working practices but we’ve missed the fundamental point. Have we actually got better? Have we delivered better outcomes, whether that’s better quality, better cost to service, or whether that’s just more profitable? Whichever dimension you talk about, you have to achieve something. Back to the outcome.

We started adopting a lot of the principles that we see, some within DevOps, some within Agile, some within other methodologies and we were starting to describe what would work for us. We layered it on very slowly, very organically and said, “right this week, we’re going to bring something new to the table.” We did that week after week, building out our story, building our landscape, building and bringing the team with it until we’ve ended up with something that looks a lot more agile and a lot less waterfall but it’s very us. An app that was very much from the software development team from my part of the business.

Then we’ve expanded that out to other teams to say, “Well actually, how do we bring you into this process? That’s allowed us to start to join up some of the key processes, some of the ways we communicate your information, some of the technology we use to underpin that process. We’ve moved on to using Bitbucket for our software development. We use Maven and Nexus that allows us to do a lot of builds and common libraries to do stuff.

Fundamentally underneath it all, it was about people; about how do we get the right people at the right point in time, collaborating together against a common purpose that was clearly defined. For me, that cuts to the chase of all these things. You can only be effective when everyone knows the direction they’re heading, the task in hand and they trust each other to perform. The best technology, the best methodology, the best processes do none of that and that’s why this journey is, for us, probably a little bit more patient but it’s been far more rewarding because our quality of service, the quality of output and outcome we deliver, the speed by which we get there is only improving because we put the foundations down to allow us to deliver.

How are you measuring success then? Is that how you’re measuring success, through the delivery, speed of–the higher levels of customer success? Are you measuring those things specifically or are they just general things you’re looking at?

Some specifically, some are more qualitative, it’s observational-type stuff. Some of the things you’ll see, productivity. ‘Right first time’ is really important to me. I’d rather do the right thing and get the right result for our clients and for our business than having something pushed out quickly and then come back for rework because it tends to sour things. That doesn’t mean to say you can be slow and take forever to be a perfectionist. If you’re engaged and you’ve got the customer inside your circle, they’re on the journey with you and you’re building a no-surprises approach, generally what happens is, is you’re clear about what you need to do. You’re clear about how you do it. You answer your questions en route because everyone’s working together. Invariably, you get there just as fast. Not necessarily slower-faster, but you’ll come out with the right result.

We had a history of perhaps pushing things too quickly and then missing out on quality, so ‘right first time’ is a really good metric. Does the customer accept what you’ve given them? Do they appreciate–do they use language that’s complementary? Customer stats is another dimension, so if the customer actually gives you the kudos or is willing to respond and talk favorably, whether that's a local stat survey or lessons learned interviews. Again, that's a really good way of exploring “Am I doing the right thing? Is this working for them?”

When you use the term ‘customer,’ what kinds of people [are you referring to]? Are you talking about little retailers? Are you talking about internal customers, big business, big B2B customers?

For my part of the business, I sit in a community called ‘banks and acquires.’ We largely serve the key banks, the acquiring organizations, so these are the Barclaycards, Worldpays, global payments of the world. We also have a number of ISO organizations, resellers who will consume the services of the acquirers but will deal with us directly. They're big enough to have their own business model.

We're B2B in that nature, and not to get involved with the end customer unless the end customer is quite sizable in their own right and has enough leverage to engage in the process. These are organizations in themselves [that] have strong brands, strong reputations, and are looking to get good, quality solutions to the market at the right price that have a good experience with their customers, so they're very conscious of it as well. We have to satisfy our direct customer first, then consciously focus on how we satisfy the end customer, the actual user of our technology.

I'm thinking out loud. I'm just going to state the obvious here. Your solutions have to be quite scalable, don't they? If it's going to work, it has to work in 170 counties. Otherwise, it's not really suitable and it's going to have to be deliverable across that and scaling up to the number of transactions it's going to have to go through. What's your target infrastructure? Is that onto their infrastructure? Is that onto your–how does that architecturally work?

I'll give you much more clarification. While most people would think the worlds of payment and what we do would be homogeneous and being able to apply right across the roles, the reality is the payment industry is incredibly fragmented, so every country has its own local idiosyncrasies. That means that –

That makes it worse.

To give you an example, within the UK, we service the UK, Republic of Ireland, and to a degree, the Nordics, and there's some commonalities between the way the card schemes and the regulatory bodies allow us to do things. Even inside that, I've got three different payment applications that all do the same job but they're legacy applications I've inherited. We have large estates of customers, so we have, I think, somewhere near a million terminals, payment terminals, in circulation within the UK and Republic of Ireland for Ingenico, but even that breaks down into: these were run on that payment application and these ones will use a certain estate management capability to manage the terminals while they're in the field. It's actually really complex underneath the bonnet, which makes life even harder because you've got all sorts of inefficiencies as well as having to manage quality control in lots of different places.

Oh, boy. I just suddenly had a ‘flash by’ of what the document must look like. We need this, ahhh!

Yeah, today it's three times around. This is why I said at the top of the billing that different organizations are in different stages in the journey towards how integrated and how capable they are by being able to deliver software at pace and deliver a solution at pace. We're further back in the chain like a lot of organizations because of legacy. You've got a world that's been built over time and changing it can be hard. Now, we're very much on the journey.

We're trying to converge technology stacks. We're trying to adopt new ways of doing things with lots of tools and support that we build. How do we actually promote capability into the marketplace? Have we managed that process? It's a journey because you still got to keep the lights on whilst you're making all the innovation in order to get yourself to a better place. We're somewhere down that journey but it's hard work. It gets in the way of doing the rich, interesting things you really want to do.

Specific question, and this actually came up. I was at a conference over the last couple of days, and this conversation came up about whether or not DevOps or any agile process should be prescriptive in terms of telling you “this is what to do.” Back in waterfall days, you had a set of steps that you worked through across the waterfall. It was a V life cycle. You always did requirements, design, and then build, and then a couple of types of testing, and then delivery.

Whereas DevOps is kind of–there isn't anything hard and fast, and what you said was that you essentially evolved your own processes and methodologies according to the needs of the organization. The question is: is that your preferred approach, and was that what you wanted to do and that's what Ingenico needed? Would you have preferred that someone just came along and said, “There you go; that's your process. That's what it looks like these days. That's what it wants you to do”? Then you'd get the right tool set and you wouldn't be trying to work it out as you went along.

I'd like to say there was a policy that just said, “Here it is, an icebox, a red door,” and it just gives you all the answers. My experience is that just doesn't exist. Anything that is prescripted, by its very nature, will fall at the first hurdle because you've got far too many variables you're trying to accommodate. I think the reality is you want [to be] somewhere in between the two states. You want a framework, and a framework equips your organization and your team with all the things they need to do and it gives them guidance and steps.

Maybe years from now with AI coming through that we're going to have the capability that personal dimension can be removed from it, but the reality, so long as that's there, you're going to have to have flexibility. My approach has always been to say “Let's take the latest of the thinking, think about how we apply it to our situation, and then take people on a journey.” The journey is the means by which you adapt, you learn, you grow in order to accommodate and get the best of it.

I've seen situations in the past. I've been involved in some of those programs when you say we're doing this; it looks like that; everyone must comply. The lesson I've drawn from that is you've just set yourself up to fail. To set yourself up for success, you've got to understand what ‘good’ looks like, and you've got to give some latitude for failure. You have to give people the opportunity to try and learn, but having a good quality framework, having some ready-made tools, having some technology that works out of the box make that journey an awful lot easier, but you've still got to apply it to context. I think that is the real art of all of this. The good organizations are the ones that can see past the problems and see the opportunities, understand where it's worth fighting for, worth persevering, where you want to place your energy.

I inherited a legacy of technology; I also inherited a legacy of people. The nature of the organization was such that we probably weren't getting the best of them, but there was talent there. The journey is as much about giving people room to breathe and actually uncover their talent and explore. Every day that passes, we get a little bit better. At some point, hopefully we'll progress as far in the journey as we can go and then by that time, something new and interesting will come along that will allow us to take the next evolutionary or revolutionary path. For me, DevOps is just another step on the journey that says ‘how do we make the world simpler, how do we adjust the number of moving parts, and how do we improve the means by which we deliver our outcomes?’

Within that, I do see a binary nature between–you said you're moving from a legacy situation to a situation that's more agile. The more agile situation doesn't then become the next generation of legacy situation because it's definitely different [from], as you point out, waterfall. You won't have to start from scratch in five years, or I do hope you won't.

If you were to pick out the key elements of how you've managed to transition your organization or work with others to transition the organization from this more waterfall-y mindset world to a more agile-y, DevOps-y world, what would you say are the steps or the key elements or how would you characterize that?

I think one of the most important things–and often we think we've done it, that we give it too little credence, but actually planning, having a strategy, and thinking about what am I trying to do here, where am I trying to get to, and building some clarity around that. We spend time setting ourselves a vision, a mission, some goals. We describe what ‘good’ would look like and what it would feel like to be in a place that we would call successful.

We then broke that down into parts of what we're going to need to do in order to realize that vision. We gave ourselves long-term objectives, some short-term ones, some improvement things we had to take into account. We brought that down into our personal objectives and our performance development plans. We really spent some time saying ‘As a team, we're trying to get to this destination. Here's our North Star and making sure everyone had the clarity of purpose.’ If you don't, particularly something this agile or DevOps, everyone interprets it in their own way, you've got a recipe for disaster. We knew what we wanted to do.

We then focused on: “How do we create the building blocks to lay the foundations? What was going to get us started? What were the easy wins, the logical steps that would allow people to engage, allow people to start to make the journey, to start to build momentum?” We set those out, and that was–we took a view that says “We're going to reorganize the teams…” I'll come back to that one in a second.

We'll go quite hard on data management, so make the world a bit more colorful, and we'll make things in a way that is going to draw you into collaboration. You can't do them without actually having to talk to each other and we're going to adopt more of a Scrum-type process when everyone gets involved at the start of the process and you're flexible in your mindset. We got people together, we gave them purpose, and we gave them room to explore what that would look like. That really goes on the journey.

To come back to that question of structure, what I unearthed when I came on board was a very fragmented organization. To characterize it, project management sat under one division reporting to one director. Development sat in another at a different one. Test is somebody yet again. Solutions and architects, especially managers and architects, were dotted to another area.

We effectively had four business divisions actually all responsible for delivering a common goal, a common outcome. You can imagine that just doesn't lend itself to working well together. There was lots of tension, lots of divisions and gaps between teams. That fragmentation was just holding us back, so we brought everyone together. We put them into one big team. We then started to change the language. We moved it from being project management dev test to ‘We're professional services. You guys are responsible for the solution outcome. You're responsible for solution delivery. You're responsible for solution development. You're responsible for solution design.’ As quaint as that may sound, it was a very good way of getting people to start to use the language.

Language is a very powerful thing, and if people use the words and play them back to you, it generally means it's starting to stick. We brought them together. We broke down the barriers. One really simple one, dev and test, two separate teams. Dev would build something, give it to test. Test would say it doesn't work, throw it back to dev. Dev would challenge them and say it does; you're testing it wrong. This would be a never-ending cycle of tension.

Put them in the same team under a common management structure and suddenly, they can't throw rocks at each other. They're now the same team, and they've got to figure out actually how do I understand that we're building? How do I build the right test scripts? How do I get in the conversation early enough, that what actually comes out the other side is the right thing. That changing structure and real focus on collaborative behaviors then allows you to introduce new ways of working, new processes, new technology, much, much [more easily] because people are ready for it. They've got an appetite for it. They're in the right head space.

I once gave someone a piece of advice, which I've never tried. Bear with me; you'll understand in one sec. It seemed the right thing to say when someone was saying, “How do we get over this problem?” I said, “Why don't you make everyone play football together?” It was the same principle. Literally just get everyone starting to play for the same team and then realize that they're not those people over there. This is those people over there. I don't know if it worked, but it's just that getting people into the same space and the same head space and the same direction and sharing, isn't it?

Totally, and this for me is where one of the areas of DevOps starts to win out. For me, it's not the process and the methodology but what you're doing is–for me, I've taken the journey I'm taking my team on and seeing how do I join in the other parts of the business we interact with. You've got the same challenges we face, just on a bigger scale. We deliver through–we have to work with our iTeams for our infrastructure and platforms about how we promote software.

We've got operational teams who actually manage the software from a loading terminal and customization and update process. Again, we do all this good work but then they go make a hash of it. Well, is that really the case or are we maybe not that effective in how we deal with them? We've not really seen the world through their lens. This is what I think. I think DevOps is getting it right because it's just extending that ability to all harmonize around a common problem and use the tooling to get you to where you need to be together.

I think that's what you're quietly doing is flipping the argument, which is really clever. What I have heard frequently is everyone should be doing DevOps but there's cultural issues. What you're saying is we need to understand the cultural issues and how to address them. Once we've done that, we'll be better able to do DevOps or anything else.

What would you say across your entire experience–I'm not saying you need to pick a specific recent example, but in terms of that culture change and structural change and personal change, what would you say are the harder bits of that that you've seen for people to actually have those epiphanies or whatever it is?

Every organization I've seen that culturally struggles is–generally in my experience–this was at Ingenico but other companies as well. It's a question of trust and respect. We tend to set organizations to be top leadership, but we deliver management that actually–we mean management, but often what we deliver is supervision. If you think about things like the psychological stuff, the transactional analysis, we don't have purposeful relationships.

We treat it like a parent/child thing. As an organization, we allow people who say, “Do this. I want it done this way. Get it done now,” so we're not giving clarity in instruction; we're not giving reasonable room for autonomy; we're not allowing people to give a response in an adult way. Then we get a surprise bit of results when people behave like children. “I can't do that; that doesn't work for me; that'll never work here; I'm not interested; I'm taking my toys and going home.”

The question is about rebuilding the trust and getting people to want to be there and want to do stuff. Work is not fun, and it's not play, but it can be a very rewarding thing. You've got to create the environment. A big thing I talk about with teams that I get involved in is about leadership because leadership can help create that culture; you can build the trust.

The type of leadership is not for someone to stand up like a manager does and say, “I'm your boss.” It's rather to give people reasons to follow. That's a much, much harder thing to do and a much more subtle one, but if you can inspire people, if you can give them purpose, if you can motivate them to be better, then generally what starts to happen is like flowers coming up. Some of them start shooting up, and they start to trust, they start to engage. They'll exercise the talent. They don't fear failure so much. They're now willing to embrace new things. When you ask them to do stuff, when you treat them like adults, unsurprisingly, they behave in kind and do great stuff. Every single organization I've been in, when you get that right, it's a very, very powerful agent for change in being able to do stuff.

The journey I’ve been on with Ingenico was from a manufacturing background when we had quite a controlling organization, people have to clock in and clock out and justify every minute of their day to one that says actually, I think you're all good, but I don't think you know it yet. How do we work on you actually having some chance to grow? Let's talk about failure; let's talk about risk. In my career, I spent a number of years at BSkyB and I had the good fortune to do a leadership development program there.

I remember one thing that really stuck with me in my career, and it was something James Murdoch–was a small group of us, about 12 of us. He took us in a room and closed the door and said, “Here's a bit of advice I was given and really simply, you need to take risks. If you don't start taking risks, you're all fired.” We were like a little gulp, a little pregnant pause. We went, “Okay, write note to self: take risks.” He said, “It's not as simple as that. Take a risk and get it wrong, we’ll support you. You take the same risk twice and get it wrong twice, you're fired.” There's the line. As a leader –

Fail fast but learn.

Yeah, the key as a leader is actually getting people comfortable with the principle of failure and taking risks, not to consistently fail and not perform but to push yourself out and do new things, try new things, grow into new things. When you start that journey and going, it's amazing how much hidden talent is actually out there, and you can really start to use that to build your organization. It becomes very self-fulfilling. That, for me, is a big part of what we've been trying to do in Ingenico as an overall leadership team and how I've been pushing my team is to rebuild the trust by giving people confidence that you're not going to get beat up. You've got people who are behind you, people who are going to support you, people who are going to lead you and hopefully giving you enough reasons to follow.

That's brilliant. I think what's excellent about that is the fact that it's everything to do with DevOps and it's everything to do with becoming more agile, that it's nothing to do with technology or putting in place methodologies for the geeks or whatever. This is about getting business right for the modern age, and that's probably an excellent note to finish on.

I'll leave you with the last word, if I may. Apart from hiring you–and I'm sure Ingenico wouldn't be happy with that–if you were to sprinkle a bit of gold dust around it and just–if any organization had the opportunity to start embracing some of this stuff but didn't know how to start thinking about it first, what would be the hook that we can leave people with? Just start... and the rest will fall into place. It may not be as simple as that, but what do you think?

I think really simply, explore. Be curious. You've got nothing to lose. Just because someone's come up with a new term doesn't mean to say it's bad. What you've got to look for is what does that bring to your context? The moment you stop being curious, the moment you stop learning is probably the moment you really probably want to stop working because your value's gone. For me, I try and bring that mindset into that, and I would encourage others to do it.

The first point of building that curiosity and exploring is do it with your team. They will have lots of ideas, lots of answers. Building something out with DevOps is not done by a small reserve group of people who have big heads and wrap wet towels around their heads and sit in dark rooms. It's something that all of us can apply to. We all have an opportunity to improve our business, whether that's a small marginal gain or a very large one. You got to start from a point of being willing to explore and giving people room to do it.

Excellent, wonderful. Let's leave it there. That was fantastic. I really enjoyed that conversation. Thank you, Simon, and hopefully–we did talk about this before, but I would welcome the opportunity to talk again. Thank you very much for your time, and I hope our audience out there appreciated that. Any questions, you know where to find us. Thank you.

Thanks for having me.