Leading Transformation at one of the Worlds Oldest Enterprises

From the Industrial Age to the Digital Age, Leading Transformation at one of the Worlds Oldest Enterprises (Coats PLC)


Our session tells the story of how we inherited a stalling, debt burdened project, relying on external suppliers, and under mounting pressure to deliver urgently, and used it as the catalyst to create a new, permanent digital capability. This can pivot and meet the needs of the challenging times we live in, delivering new products that are digitising the way Coats engage with our customers.


We will describe how we filled the product gap, how we created a ‘dev circle of life’ to enable rapid development and operational excellence, and share some lessons learned along the way. We will also dip into examples from our past transformation journeys and highlight some patterns we have seen, and then attempt the impossible, and show to the world for the first time, a scientific formula for successful digital transformation. Or as we call it ‘The Success Calculus’.

TD

Tim Dempsey

CTO Transformation, Coats PLC

PM

Paul McMahon

Global Director of Technology and Innovation, Coats PLC

Transcript

00:00:09

Paul McMahon is global director of technology and innovation at coats, a company that was established in 1755 and by 1890 was a world's most second valuable company. You'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 meant create materials to protect firefighters, enable peak athlete performance in gears, 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.

00:01:04

Hi, 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?

00:01:44

Yeah. Hi, my name's Tim Dempsey, uh, worked previously with Paul at Vodafone for we joined forces again, uh, copes my last, uh, transformational work, uh, was moving the ministry of justice, uh, to allow nine teams there. In fact, that, uh, from a environment where they're 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.

00:02:14

So as you know, in our world of dev ops 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. A next slide. Coats is one of the world's oldest organizations, as Jean said, it was born in the late 17 hundreds. 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 eco Verde 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 UCS, such as, uh, we in cars with aloe wheels and also into the energy sector and telco again, as Jean said, one interesting fact about coats, Thomas Edison, when he invented the light bulb used one of the coats threats 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. So piece,

00:03:30

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 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 a billion dollars a year in revenue. So Tim, take us through what our mission was when we joined forces again and codes.

00:04:46

Yeah, let's move on to the next slide. So given the job as the program manager, I 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 that. But I suppose to start aligned, it's the lifeblood of the revenue of coats. So if you want to do anything new for a customer, you'd be wanting to do that in a matter of weeks, not in months. So rather than just replace that software with something else, businesses, seeing this as a technical problem, what many people know from having done this a few times and 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, um, sit down and write and lens a new code, throw it out there that the business that the business user, um, we knew that we had to actually change the way we were going about the way that we worked.

00:05:43

Um, not just the e-commerce systems being asked for. We're also being asked for a new color manufacturing system, five different different applications as well, that were being demanded office as it team from across the business. There's always new, uh, from, from, uh, 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. You try and do too much, you're going to fail. So try to deliver on all these fronts all at once, you're going to a bad job of all of them. So I was very strict, as I said, running 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 also like we're going to go slow so we can go faster later. So I'm back to you pull up

00:06:39

Next slide please.

00:06:43

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 a 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 eCommerce 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.

00:07:46

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 advantage this 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?

00:08:43

How has their behavior on the system? Is it bringing them the joy of ordering, um, 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 codes 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 minimum lovable product that can be pushed into our customers and pushed into our existing coats members who might using those products to understand what we can do to improve, to get fast feedback. And again, focusing 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 status position.

00:09:45

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 matter, I wear 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, um, with the enthusiasm and youth, from India, with the experience and understanding of the technology from the UK based team.

00:10:45

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 agenda balance, um, which is more, um, 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.

00:11:24

So let's talk about some technology. I think after that, um, what I wanted to talk about here was, uh, the big shift that we had to make throws generations of e-commerce that Paul's introduced the, uh, just to add to the excitement. We already had a new e-commerce system in place called , which you can see the rest in peace in 2019, uh, this London, a lot of learnings that we've, we've seen over the years from, uh, devil's crusade or sort of writ large in what went on with DC. It was, um, what on clouds? But the way it had been created was, uh, using all the anti-patterns that we've seen over the years. So no automated test stick, everything had to be done manually, even though it was listed in Azure, we were down to a quarter release paddle pattern. So we started off the program actually thinking maybe we could, uh, some something from this, we'd be able to like reuse bits of that, but there was so much tech that it was going to be, uh, more, um, uh, advantageous the correct decision was to go again and move over onto Google.

00:12:31

Um, 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. Um, something I've always wanted to do with a team of people, rather than sort of top down out them as actually say, let them make their choices and see what happens to have impact. And it was great. It was really quite experienced to that. So the sort of rules I set for them where a full automation has been taken through all environments say, everything's gotta be zero touch. You've gotta be able to do that. And they said, yes, that we'd love to do that.

00:13:10

Please do 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 outcome has gone through a pipeline that has checked that out. So that task overrun security officer CSO coach 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 only get woke up at four in the morning, but it doesn't work in Vietnam and you want to choose your monitoring very well. So you can do so you can, um, 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 like load balancing or whatever has gone wrong, reintroduced something else in nature wrong.

00:13:58

So I wanted everything to be as modular as possible. So we traded this concept of macro services, built everything around GRPC API layer as well. Um, running the same, we started off using Kanban. There there's so much to do. I wanted to limit work in progress to actually make like visible, um, deliverables for our, um, stakeholders as early on as often as possible. But once we got into Baylor, we finished building our infrastructure. And once we got into a development mode, we moved into just doing normal sort of spread work. So anyway, back to you, Paul,

00:14:34

Thanks Tim. Next slide please. Thanks Tim. So as you've heard, we've got three generations, the very calm platform in our story and the focus around the three, our third generation took a big, a big pivot coats to that point had been very much and as your house and choosing to move the solution into a different cloud provider, uh, 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, uh, some services GK, the Cuban 80 associate Google being the big one to be able to run fast within Google. What we also uncovered though, um, 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 e-com project from April through to around the August timeframe, we put a lot of emphasis into building our automation pipeline, our CICB 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 operator.

00:16:02

We use tools which have become very popular due to the lockdowns around the world, like Myro to collaborate and whiteboards and plow where we saw the features of functions. Our customers needed to help prioritize those with our business colleagues. And once we had done that, we then fed that Myro 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, uh, prescribing to our teams, um, was central to everything that we did. This pipeline moved coats from the ability to release code once a quarter, to be able to do it multiple times a day.

00:16:58

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 core 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 a hundred 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?

00:18:08

No.

00:18:14

Yeah, yeah. Sort spot where I, I said, I want you to build this guys so that if we've got something wrong, we made a decision wrong early on. We can swap things out. Uh, 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 no SQL one on, on Google cloud. And when we got quite a long way in actually had live customers on the platform, there was features that the business is asking for and reporting that it was just going to be convoluted as anything to do on a no SQL platform. We needed to go back to the relational world. So even though we had that compartmentalization and it's like, all the rights and reeds were in different, uh, you know, GRPC calls and twice the different APIs take you all that to me back in really cost us weeks. And that was painful at the point where we're just getting momentum to bring people onto the platform. So nothing could have been had we not done it that way, Paul? Yeah, because we come at a loss to the insight project at that point

00:19:15

Being the optimist amongst us. I think it also provides 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, uh, 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 sent it on 65.

00:20:07

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, and 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 renumeration and bonus checks to drive workloads to the cloud and behaviors that that resulted in was infrastructures that were VMware based with little, um, 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 flip 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 Yohanna. 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.

00:21:08

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 learned along the way. It doesn't result in the outcome. 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, of things that you get told from keynotes, that dev ops, you think that it's not that difficult to achieve greatness. However, I've got a picture on my next slide, which will flip to now, please. I thought this picture sums up the notion of transformation from my experience, this chap I live in, sorry, by the way. So this is very close to where I live.

00:21:55

He went fishing and on that day, when he was pulling up a fish, he accidentally brought up a live bomb, uh, from probably the second world war. And that I thought it 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.

00:22:29

So where have we ended up at with our digital transformation 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 I've 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 timeframe. So the use case you see on the slide, there is a very simple, um, tool for a sales person 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.

00:23:22

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. Um, 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 coach 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 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.

00:24:11

How do we start to temper some of that, 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? What 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 living drink. And in that conversation, one of the developers said, look, you guys have got a formula for this, you know, the way that you work, the way that you lead, the way that you drive value into an organization, there's a lot of, um, science behind that. So in that debate, we started to think, is there something behind this? Didn't we tend

00:25:02

Pointed. Yeah. So yeah, let's move on a couple of sides actually. Uh, how can we discuss this without massively incriminating ourselves that we're competent, but yes. Yeah. So actually when 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 night is about what do you do? And, well, basically we do three things. We have three things to manage. We've got few developers and engineers. We have to make sure that you've got the right tools. You've got the right, uh, you're happy, got the rights stories, feeding you when it was coming out. The other things that you see as to that. So you don't get bothered all day by, uh, people asking daft questions of you is that we've managed the business, try and teach them about this new way that we're going to be working.

00:25:53

So rather than waiting four months for it to turn up with something that wasn't quite what you wanted. Anyway, we're going to actually have a very fast cadence and start to start working together a lot more. Uh, and then we also have to manage what we current mandate that actually 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 then said, oh, I see what you're doing. I see what you're doing now. And, uh, I think there's anything particularly new or earth-shattering on that slide. It's just like we, you know, that's dev ops and cloud that's business change management that has been 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, um, the technology that we have now, the cadence that we can work out and the DevOps mindset, or the way of work here throws a very bright light on those three things work together and exposes, uh, any failings very, very fast.

00:26:53

Um, so what are they engineers on the court guy called kind of feral who has a doctorate in computational physics and sees everything as mathematics. So, oh, so what you're doing is not actually managing three forces of transformation. That's, you've got a negative feedback loop. I said, what? And he said, yes, and I guess a feedback loop. So he sent us a very detailed email to explain what he meant about next, a feedback loop. I'm sure everyone can understand that Tim, 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.

00:27:28

Hi, my name is . I'm one of these software engineers to work with Poland, Tim, uh, coats. Uh, I also have a computational physics PhD, so they asked me to briefly explain what a feedback system is really don't know. Um, 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. Um, you can, you can see life itself in general, as a sort of feedback system will be locked. So there are two types of feedback system, uh, positive feedback and negative feedback. Positive feedback is where you just want the output of the system become bigger and bigger. Every time you don't want to care about stability. You just want to know where to go for negative feedback systems and you shouldn't see negative as a bad thing really here.

00:28:15

It means something like self-correcting feedback. Um, you care more about supposing you don't want to have them to get too high or too low. You want to have your medium. So if we think about delivering software as a negative feedback system, that means that the controller should balance and compensate between different forces that are driving the system. Uh, the death function, the business function and the mantic improved book. 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. Um, you need to step in and take some action. For example, strengthening the pod function. If it's able to provide some clear direction was with a self-correcting process, it means that you can deliver the right software at a particular cadence type business value. And that's what you really want.

00:28:56

Thank you comment. Alright. So Connor explained it in a way that we could not understand. I was thinking about what we did as just three isolated forces that I was running around between actually, what Khan has done with his negative feedback analogy is to, um, explain that there's other things wrapping around this, that we need to understand, to have an insight into how transformations work. So this, the formula that he built in that email was also has controlled. A C is the digital transformation leadership team. That's been poor 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 I lose patients, we lose all our money and we'd go away. Um, D is external forces, external, external sort of disturbances that come in and COVID-19 is just the ultimate example of that.

00:29:54

That would be like a minus 1 million arrived in our formula of success from, from out of nowhere, changing everything, uh, S being the strategy that we're trying to execute. So when we see those different things that call was talked about in that 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, um, we have a strategy on the right that we need to build towards is the it's this, uh, value that we're delivering out of, out of, uh, the work that we're doing and the very complex interaction of, uh, the technology team, the business team, and the board, the stakeholders in the middle of that, of that calculus there, and carcass means modeling change over time.

00:30:41

That's what, that's what a calculus does. So people are not mathematicians, mathematicians at all, but we started to get quite excited about what we see on the screen there, because they was just to give us maybe some more tools and other way of thinking about the transformation and the other things that are going on within it, rather than just the things that we can control, uh, with our everyday activities. We need to keep our eye on strategy, need to keep eye on the value, but also look out for those external things coming in. So really so that's, let's wrap up Paul

00:31:13

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 not delivering or delivering too much code too fast for the business. And 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 cause Tim and I can answer those. We're not mathematicians. As you said, 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, uh, stay safe and hopefully we'll meet next year in person.