Leading Transformation at one of the Worlds Oldest Enterprises

Paul McMahon is Global Director of Technology and Innovation at Coats, a company that was established in 1755 and by 1890 was the world's second most valuable company. He'll be presenting with Tim Dempsey, who helped him create a world-class technology capability as his Delivery Director.

Most likely, Coats creates the threads in the clothes you are wearing. They also create materials that protect firefighters, enable peak athlete performance in gear such as made by Adidas, and the fibers in fiber optic cables. They will describe the importance and lessons learned in their digital transformation and how they are supporting the CEO's effort to move the company into the digital age.

This journey has taken them deep into the company's most critical capabilities and creating entirely new ones to better serve their staff and their customers. Please welcome Paul and Tim.

Hello, my name is Paul McMahon. I'm the Director for Technology and Innovation at Coats. I'm here today to talk to you a little bit about our journey from the industrial age through to the digital age.

But before we get there, a little bit about our backgrounds. I have been responsible for many digital transformation programs over the years. I've worked across multiple sectors, including telco, public sector, manufacturing, and energy. A lot of those experiences have generated patterns and rhythms, which we see again at Coats, and I'm here hopefully today to convey a few of those to you. But before we get into that, Tim, would you like to introduce yourself?

Yeah. Hi, my name's Tim Dempsey. I worked previously with Paul at Vodafone, before we joined forces again at Coats. My last transformational work was moving the Ministry of Justice team, nine teams there, in fact, from an environment where they were only able to deploy software every six weeks, introduced DevOps tools and practices there that enabled them to actually deploy six times a day, which is a great story, but one for another day.

So, as you know, in our world of DevOps and software delivery, one of the key things we look to do is to remove assumptions. So let's remove the assumption of who Coats is. Next slide.

Coats is one of the world's oldest organizations. As Gene said, it was born in the late 1700s, and since then, it has grown to operate in over 50 countries and has around 17,000 staff globally.

Coats makes a number of different products, including the EcoVerde set of threads. Those threads are in most of the products that you will be wearing, from a shirt or the logo design on my polo shirt, through to other uses such as automotive, in cars with alloy wheels, and also into the energy sector and telco, again, as Gene said.

One interesting fact about Coats: Thomas Edison, when he invented the light bulb, used one of the Coats threads in that process. So we've got a very long heritage of pioneering and innovation, which are two of our brand archetypes, and hopefully, when we walk through some of our experiences, you'll see some of that coming through. Next slide, please.

I mentioned that I had run a number of presentations and transformations across different sectors in large organizations, and there is a sense of common challenges, which I'm sure resonate with a lot of you listening today. Those common challenges have been brilliantly broken down and described in great talks over the years at the DevOps Summit.

I have joined in the audience looking at people like John Smart and Mark Schwartz talking about how to create anti-patterns around these challenges and make a real breakthrough to drive that transformation. Within Coats, we've seen a number of areas that have caused us to focus in on one good thing and try and do that well, around paying down tech debt and delivering software of good quality at pace.

To talk a little bit more about the mission that we took on at Coats and how we drove transformation, I'm going to hand back to Tim, who's going to take us through an application that we built for our e-commerce world. E-commerce in Coats is where our customers place their orders for products. We have around 40,000 customers, and the system itself takes around $1 billion a year in revenue. So Tim, take us through what our mission was when we joined forces again at Coats.

Yeah. Let's move on to the next slide.

Being given the job as the program manager, I've got the business asking me for a new version of e-commerce because it takes four to six months for any new features to be put on there, but as Paul's just outlined, it's kind of the lifeblood of the revenue of Coats. So if we want to do anything new for a customer, you'd be wanting to do that in a matter of weeks, not in months.

Rather than just replace that software with something else, the business is seeing this as a technical problem. What me and Paul know from having done this a few times in some other places is actually it's not the technology that needs to change, it's actually the way of going about doing IT, if you like.

So rather than sit down and write loads of new code, throw it out there, let the business use it, we knew that we had to actually change the way we were going about the way that we worked.

Not just the e-commerce system I was being asked for, we were also being asked for a new color manufacturing system, five different applications as well that were being demanded of us as an IT team from across the business. There's always something new in terms of requests.

So just like we do when we're running a software sprint, you can only do so much at any one time. If you try and do too much, you're going to fail. So if you try and deliver on all these fronts all at once, you're going to do a bad job of all of them. So I was very strict and said, "We're only going to do two things. We're going to do a bit of e-commerce work, but we're also going to try and introduce the tools, ways of working, and methods that allow us to then accelerate what we're doing in the future." So it's almost like we're going to go slow, so we can go faster later.

So I'll hand back to you, Paul, at that point.

Next slide, please.

So as Tim has just described, we focused in on starting our work with an e-commerce platform and solution. However, the capabilities we had internally to deliver that platform had previously relied on external software developers. So one of the first things we needed to understand was how do we build the permanent, sustainable capability that can deliver digital products for Coats and drive innovation and value to our customers into the future, beyond the single product that we were starting with, the e-commerce product?

One of the challenges that we have within the organization is the word product manager actually means somebody who designs a new product, designs a bit of thread to go into a new use case for a customer. We therefore had to step back and try and figure out how we fixed this product management gap, this mindset that needed to be ingrained into the DNA, not only of the development teams, but also the business colleagues that we were working with.

If a feature within our existing e-commerce platform worked in a particular way, we drove debate and focus on was it still the right thing to do? Is there a better way of delivering that feature using new technologies and tools? Or now we know more about the customer's behavior on the system, can we start to think differently about how we can deliver the outcome to the customer?

And that's where the concept of design thinking, human-centered design thinking, came in. So design thinking was used to plug that gap and ensure that we were able to put into our DNA as a product team a way of thinking about the features and functions that were in place, and understanding if we could build them in a better, more advantageous way for our customers to drive more value.

We broke that down into three areas. We started with the ability to look at the empathize side of human design thinking. What is our customer doing? How is their behavior on the system? Is it bringing them the joy of ordering in a seamless and straightforward way? Or can we do things to improve that process, make it more seamless, create a stickier user experience for them buying products from Coats?

That enabled us to gather quite a lot of data, and that data can be used then to evidence the solution that you want to put in place and start to ideate that solution. Create a minimal, lovable product that can be pushed into our customers and pushed into our existing Coats members who might be using those products to understand what we can do to improve, to get fast feedback, and again, focus in on how we can drive more value to our customers. Next slide.

I mentioned that we needed to build a sustained capability, and we needed to go fast. The previous versions of the e-commerce solution had been in a bit of a stasis position. They had been in development for around 18 months. There was a large set of technical debt within the code base that had been written, and in order to tackle that, I was very clear that we needed to build an interim team with some expertise to be able to go fast.

That interim team joined us at the start of April in 2019, and whilst we began building out our new e-commerce platform in Google, we also looked at how we could build an SRE capability in India, in Madurai, where Coats has a large presence, and couple them up, buddy them up with our internal contractors who had lots of experience from working within the UK marketplace. And that melding of skills together enabled us to drive quite a fast delivery mechanism, with the enthusiasm and youth from India, with the experience and understanding of the technology from the UK-based team.

The other opportunity that we seized upon was the chance to create more diversity within that new team. I inherited an all-male team from a development and engineering viewpoint, and when we were able to start to expand and grow new capabilities, we took the opportunity to go out and seek top female talent. And I'm pleased to say and proud to say that we now have a team that has a gender balance, which is more even, and it's creating great results. Having that thought process from a wide range of people is now driving faster and better outcomes.

Tim, next slide.

So let's talk about some technology, I think, after that. What I wanted to talk about here was the big shift that we had to make through those generations of e-commerce that Paul's introduced there.

Just to add to the excitement, we already had a new e-commerce system in place called D2, which you can see there, rest in peace in 2019. A lot of learnings that we've seen over the years from a DevOps community are sort of writ large in what went on with D2. It worked on cloud, but the way it had been created was using all the anti-patterns that we've seen over the years. So no automated testing. Everything had to be done manually, even though it existed in Azure. We were down to a quarterly release pattern.

So we started off the program actually thinking maybe we could salvage something from this. We'd be able to reuse bits of it. But there was so much tech debt, it was going to be more advantageous, the correct decision was to go again and move over onto Google.

So the way I approached that as a leader was to ask our team of engineers, who are really talented, experienced guys, knew what they were talking about. I said, "If I set the rules for you of what I want, what I think good looks like, I'll trust you to convince me that you're choosing the right technology to build it." Something I've always wanted to do with a team of people is rather than sort of top-down at them, is actually say, let them make their choices and see what the impact they've got. And it was great. It was a really great experience to do that.

So the sort of rules I set for them were: full automation is mandatory. All environments are kind of the same. Everything's got to be zero touch. You've got to be able to do that. And they said, "Yes, that, we'd love to do it like that, please, Tim. Thank you very much."

Security has got to be there by design. So when code gets released, I want to know the infrastructure code, I want to know the app code has gone through a pipeline that has checked that out so that our overall security officer, the CISO at Coats, doesn't have to worry about us.

You guys will be running this. You build it, you run it. So you've got to make sure that it's good quality when it goes out, because you don't want to get woken up at 4:00 in the morning when it doesn't work in Vietnam. And you want to choose your monitoring very well, so you can work out what's going wrong with it at any given point.

Please also make everything as simple as possible, because we're going to make some big choices on architecture really early on. And I don't want to have to find out that we're going to have a three-month delay while we rip out some sort of load balancing or whatever that's gone wrong and introduce something else later on. So I wanted everything to be as modular as possible. So we created this concept of macroservices, built everything around gRPC and a common API layer as well.

Running the team, we started off using Kanban. There was so much to do. I wanted to limit work in progress to actually make visible deliverables for our stakeholders as early and as often as possible. But once we got into the, we finished sort of building our infrastructure, and once we got into development mode, we moved into just doing normal sort of sprint work. So anyway, back to you, Paul.

Thanks, Tim. Next slide, please.

Thanks, Tim. So as you've heard, we've got three generations of our eCom platform in our story, and the focus around D3, our third generation, took a big shift, a big pivot. Coats to that point had been very much an Azure house, and choosing to move the solution into a different cloud provider was one of those things that we asked the team to help us decide. We ran a tech spike over a few weeks to prove out that we could actually leverage some services, GKE, the Kubernetes service in Google being the big one, to be able to run fast within Google.

What we also uncovered, though, was around the foundation that you would expect to be there to be able to do repeatable, fast deployments of code at a level of quality that is good. Now, in order to drive that capability, to build that foundation, at the start of the eCom project, from April through to around the August timeframe, we put a lot of emphasis into building our automation pipeline, our CI/CD pipeline.

And the diagram you can see on the slide is attempting to show not only the tools and technologies we use, but also that we didn't just look at pushing code from development through to production seamlessly, but we actually took it from the ideation and the design-based thinking right the way through to the operate.

We used tools which have become very popular due to the lockdowns around the world, like Miro, to collaborate and whiteboard and pull out where we saw the features and functions our customers needed, to help prioritize those with our business colleagues. And once we had done that, we then fed that Miro into Jira and started the process as normal for software development.

All of the pipelines that we built did enable us to focus in on test-driven behavior. Our coding quality and our standards, some of the rules Tim was talking about, was to ensure that the cost of any change and the cost of future iteration through the automation testing we were very strong at prescribing to our teams, was central to everything that we did. This pipeline moved Coats from the ability to release code once a quarter, to being able to do it multiple times a day.

The technology stack as well became a really useful weapon in attracting the right level of talent. In India, there are a large number of technology companies, and if you're going out to universities to build talent pipelines and attract engineers to form an SRE capability, then having a modern, cool technology stack really helps with that. And that proved very, very powerful in attracting the right talent pipeline. In one university, we had a year group of 100 who took part in a hackathon, and 92% of people wanted to take part, wanted to join Coats and join us on the journey.

So technology pipelines, yes, they are brilliant for automating rapid software delivery and the creation of new digital products, but they also can help in other ways, such as us being able to win the talent battle. Next slide, please.

So did it all go as planned? We've got quite good at doing these projects and programs over the years. We've tried to do this at Vodafone and at BP and other places. So Tim, did everything go as we planned?

No. No, it didn't. We'll run through a few examples. Yeah.

You've spotted where I said, "I want you to build this, guys, so that if we've got something wrong, we've made a decision wrong early on, we can swap things out." Yeah, we did build it like that. But the thing that we actually did choose the wrong solution for was the database.

So to get started really quickly and cheaply, we used the NoSQL one on Google Cloud. And when we got quite a long way and actually had live customers on the platform, there were features that the business was asking for around reporting that was just going to be convoluted as anything to do on a NoSQL platform. We needed to go back to a relational world.

So even though we had that compartmentalization, it's like all the writes and reads were in different gRPC calls and basically different APIs. Take all that, put me back in. Really, that cost us weeks, and that was painful at the point where we're just getting momentum to bring people onto the platform. So not being could have been it, had we not done it that way, Paul, yeah, because we could have lost the entire project at that point.

Being the optimist amongst us, I think it also provided us an opportunity, though, as you just articulated, to learn about more features and functions that in the end drove us to the appropriate choice for our database for the solution. So it wasn't all bad.

Now, Coats and that database example is not in isolation. At Vodafone, we had a very similar experience, where the notion of having a very clear, simple vision of digital transformation was forefront of our minds. And a colleague at the time by the name of Martin was sitting opposite me, and we were trying to figure out what the target for the organization should be to drive the organization towards a new world using cloud technologies and building cloud-native applications.

And the number that we were using for the target was moving up and down, and we centered on 65. We thought it was fairly ambitious, but not as ambitious as 75. And it was supposed to be a vision statement. However, five years later, it's been declared as a mantra to the stock market of what we wanted to try and achieve. It drove behaviors into people's remuneration and bonus checks to drive workloads to the cloud, and behaviors that resulted in was infrastructures that were VMware-based with little automation being treated as a cloud, and therefore, managers being able to claim that workloads had been moved to the cloud without actually doing any real transformation.

And if you flick to the next slide, please. As you can see here, this popped up in my LinkedIn feed about a week and a half ago from Johan, who's the group CTO at Vodafone. The five-year vision completed in 2020, and the 65% target lived on. And you can see from the words, there's still more work to do. So having a simple and concise vision, whilst it's a good thing, you also need to ensure that you've got clarity as to where that vision is going to lead. And I think having an arbitrary target was something that we learnt along the way doesn't result in the outcome that you really want to drive to.

That, in terms of BP and other organizations I've worked at, when you join them and you look at the challenges they've got and you know the things that you get told from keynotes at DevOps, you think that it's not that difficult to achieve greatness. However, I've got a picture on my next slide, which we'll flip to now, please.

I thought this picture sums up the notion of transformation from my experience. This chap, I live in Surrey, by the way, so this is very close to where I live. He went fishing, and on that day, when he was pulling up a fish, he accidentally brought up a live bomb from probably the Second World War. And that I thought was a great analogy for how transformations tend to pan out. You start with what you perceive to be a relatively straightforward use case, and as you get more into the detail, into the weeds, you discover, like with Coats and the product management gap that we had, there is much more work, not related necessarily to the development, that's needed to drive the outcomes that you want.

Next slide, please.

So where have we ended up at with our digital transformation at Coats? Well, it's still an ongoing piece of work. There is much more to do. We have had a global pandemic that has caused us to have some uncertainty, and of course, the business has had to react, as all of your businesses, I'm sure, have had to do similar. We have had to prioritize and focus in on new things that drive speed and value to our customers beyond building an e-commerce platform.

Now, fortunately, the foundation that we built within Google has enabled us to build many applications for the business in rapid timeframes. So the use case you see on the slide there is a very simple tool for a salesperson to sit next to one of our customers and take a number of different components, blend them together, and create a quote in the engineering yarn space. So the part of Coats that builds protective materials, automotive, telco.

That process used to take three, four weeks and would involve quite a lot of spreadsheet work. So we built a very simple mobile tablet-based app that can automate this, and we can now do quotes in seconds with the customer, and we're getting great feedback from our customers as a result. And Coats themselves use this as a marketing tool. So if you go to the website, if you go to LinkedIn or Facebook, to the Coats pages, you'll see the marketing material talking about the value that this is creating.

We've created many other apps, including a contact tracing app for COVID within our factories, and the demand now that we're seeing from the business, now that they can see value coming out of the machine that's been built, is starting to overtake our capacity. So that's going to be our next challenge. How do we start to temper some of that demand?

But before we finish the keynote, and in preparation for the keynote, Tim and I got thinking. With all of the patterns and all of the experience and all of the learnings that we've had over the years, why do things still go wrong? Is there some sort of secret formula? Is there something behind this? And with our developer teams from a contracting viewpoint rolling off during the pandemic, we had to have a virtual leaving drink.

And in that conversation, one of the developers said, "Look, you guys have got a formula for this. The way that you work, the way that you lead, the way that you drive value into an organization, there's a lot of science behind that." So in that debate, we started to think, is there something behind this? Didn't we, Tim?

We did, yeah. So yeah, let's move on a couple of slides, actually.

How can we discuss this without massively incriminating ourselves that we're competent? But yes. So actually, we were doing this retro sort of leaving drinks with the developers, and they said, "Well, what do you do? So you know what we do. We write the code, and you look at it all day and nag us about it. Well, what do you do?" And I said, "Well, basically, we do three things. We have three things to manage. We've got you developers and engineers. We have to make sure that you've got the right tools, you're happy, you've got the right stories feeding you, we know what's coming out.

"The other things that you see us do so you don't get bothered all day by people asking daft questions of you is that we manage the business, try and teach them about this new way that we're going to be working. So rather than waiting four months for IT to turn up with something which wasn't quite what you wanted anyway, we're going to actually have a very fast cadence and start working together a lot more.

"And then we also have to manage what we call the mandate there, which are our stakeholders. So someone on the board has put a seven-figure sum on the table for us to come and do this work for them. So let's hope that they're happy with it." And they said, "Oh, I see what you mean. I see what you're doing now."

I don't think there's anything particularly new or earth-shattering on that slide. It's just like that's DevOps and cloud, that's business change management that was being done for 20 years, and that's senior stakeholder management that's been done forever as well.

But actually, I think what is happening is that the technology that we have now, the cadence that we can work at and the DevOps mindset of the way of working, it throws a very bright light on how those three things work together and exposes any failings very fast.

So one of the engineers on the call, a guy called Connor Farrell, who has a doctorate in computational physics and sees everything as mathematics, said, "Ah, so what you're doing is not actually managing three forces of transformation there, Tim. You've got a negative feedback loop." I said, "What?" And he said, "Yes, a negative feedback loop." So he sent us a very detailed email to explain what he meant about a negative feedback loop.

I'm sure everyone can understand that, Tim.

No, we didn't understand it, so we asked him to record a video to try and explain it, and that went a bit better. So here's the video.

Hi, my name's Connor Farrell. I'm one of the software engineers that work with Paul and Tim at Coats. I also have a computational physics PhD, so they asked me to briefly explain what a feedback system is for people who don't know.

So feedback systems are really everywhere in nature. Essentially, all it means is that you take your past results into account when you iterate on a process. You can see examples in the human body, for example, with your blood sugar or your body temperature. You can even see life itself in general as a sort of feedback system if you like.

So there are two types of feedback system, positive feedback and negative feedback. Positive feedback is where you just want the output of the system to become bigger and bigger every time. You don't really care about stability, you just want the number to go up.

For negative feedback systems, and you shouldn't see negative as a bad thing really here, it means something like self-correcting feedback. You care more about stability. You don't want the output to get too high or too low. You want a happy medium.

So if we think about delivering software as a negative feedback system, it means that the controller should balance or compensate between the different forces that are driving the system, the dev function, the business function, and the mandate coming from above. If the effect of one of those gets out of line with the others, either too high or too low, you're not going to get the outcome that you want. You need to step in and take some action. For example, strengthen the product function if it's not able to provide some clear direction.

But with a self-correcting process, it means that you can deliver the right software at a predictable cadence to add business value, and that's what you really want.

Thank you, Connor.

All right. So Connor explained it in a way that we could now understand. I was thinking about what we did as just three isolated forces that I was running around between. Actually, what Connor's done with his negative feedback analogy is to explain that there's some other things wrapping around this that we need to understand to have an insight into how transformations work.

So the formula that he built in that email also has controller C is the digital transformation leadership team. That's been Paul trying to control the forces that are going on inside the business. The mandate from the board, if the board's asking for too much, too quickly, putting too much pressure on us, we can't deliver quickly enough. If they lose patience, we lose all our money and we go away.

D is external forces, external sort of disturbances that come in, and COVID-19 is just the ultimate example of that. That would be like a minus one million arrived in our formula of success from out of nowhere, changing everything. S being the strategy that we're trying to execute.

So when we see those different things that Connor's talked about in there all put together on the next slide, we actually have something to work with. So rather than just sort of managing three forces in isolation, we now all of a sudden in the last couple of weeks saw that we have a strategy on the right that we need to build towards. O is the business value that we're delivering out of the work that we're doing, and the very complex interaction of the technology team, the business team, and the board, the stakeholders in the middle of that calculus there.

And calculus means modeling change over time. That's what a calculus does. So me and Paul are not mathematicians at all, but we're starting to get quite excited about what we're seeing on the screen there, because it enables us to give us maybe some more tools, another way of thinking about the transformation and the other things that are going on within it, rather than just the things we can control with our everyday activities. We need to keep our eye on strategy, need to keep our eye on the value, but also look out for those big external things coming in.

So really, so let's wrap up, Paul. On the next slide-

Thanks, Tim. And the success calculus, I think, is something we want to investigate further. So if you have seen similar things in terms of keeping those things in balance, not letting the mandate become too overbearing or delivering too much code too fast for the business, then we'd love to hear from you.

There's a URL on the screen, so feel free to hit that up and send us a note. And in terms of any of the experiences and messages we shared, if there's a way that we can help you, then we'll be on Slack to answer your questions along with Connor, so you can ask difficult mathematic questions because Tim and I can't answer those. We're not mathematicians, as he said. But we're very happy to help you in your journey if you think there are areas of synergy. So get in touch and let us help.

So that's it. Thanks for your time and attention. I hope you found our chat useful. Stay safe, and hopefully we'll meet next year in person.

Bye now.