00:00:13

The Sainsbury story started just over 150 years ago when John James and Marianne Sainsbury opened their first store on Drury lane in London, one of the major challenges the organization has faced in recent times has been how to adapt ourselves to rapidly changing customer demand while still preserving our reputation for quality and great value. Great technology is the enabler, but technical innovation. Hasn't always been our core skillset. Despite that history early this year Sainsbury's was recognized as being the best online supermarket by which we thought you might be interested to hear about some of the things which have happened along the way, same reason, employees, 180,000 people. Now, clearly there are so many changes that have contributed to this amazing journey. We're here to share our perspectives on the story and share just a few of the changes which have been made on the way, which we think will it be of interest to the dev ops community. I Nick Polton and I've been leading a team of agile coaches within the infrastructure platforms and workplace family in Sainsbury's tech for the last three years previously, I was coaching in Lloyd's bank and it seems like a long time ago now, but my background was in project and program management

00:01:37

And I'm at Carr. I'm also an agile coach. I lead the transformation coaching team, a central team of coaches focusing on provoking and inspiring transformation at the divisional level. We aim to address the systemic issues like finance processes or portfolio prioritization. That can be really difficult to resolve from within one of our engineering's names. Before that, my career was mostly in product management at smaller technology organizations

00:02:05

And I'll everyone. I'm Stuart Richards, uh, on the head of platform engineering within Sainsbury's tech responsible for end to end change and operations of all infrastructure cloud network, tooling, device integration, integration, and modern workplace platforms across the same as business. My aim today is to interject this story. Nick and ed will be telling with things I've learned along the way, not as any kind of ways of working transformation guru, like these two, but as a direct leader of a number of teams to which this thing's risk story applies

00:02:43

The world of retail, like many industries has been massively disrupted and transformed by technology. It's a cliche, but our experience in Sainsbury's is very much that changes. The only constant. We hope that the experiences we're sharing with you today will help you and your organization as you face into your own challenges, adapting to tomorrow as well. We definitely don't have all the answers and we know that we still have a long way to go on our journey. In fact, who knows where we're going to end up, we've made plenty of mistakes along the way together with the successes we've had. And we're going to share both of these with you today.

00:03:26

So let's skip over the first 130 years or so of the journey. And start from the point when Sainsbury's had a very large outsourcing contract with one of the giants of the IC industry, the strategy at the time was to outsource everything. And unsurprisingly, the focus was firmly on process documentation and contract negotiation for a long time. The world of it and Sainsbury's was ruled by the business case, the requirements catalog and the project initiation document and everything had to progress through the dreaded gated review process. However, there was a definite realization that this just wasn't working. There were a number of high profile project failures and painful write downs. It just weren't providing value to the business, a calculation which was done to demonstrate the problem at the time, says it all the table stakes for the smallest possible project were 250,000 pounds. And that was the cost calculated for all the mandatory documentation and for following the prescribed governance processes, without anything of value actually being delivered. And ultimately this slow pace of change meant that we weren't able to give our customers the great experience we wanted to. So how did Sainsbury's do it? How did we get to where we are today? Winning awards for our technology? Did we call it an expensive consultancy and to help us modernize while we're pleased to say we didn't, we did our own way. Our leaders were brave and committed and owned the solutions to the problem themselves. We've been carving out our own path on our own journey with our colleagues leading each other on the way ed you've worked in Sainsbury's the longest. It feels right that you should pick up the story from the beginning.

00:05:32

Sure. Uh, so when I joined Sainsbury's back in 2015, we were in the early days of our attempt to transform and modernize the way that we approach technology. There were a couple of wrong turns in those early days. So I thought it might be worth just briefly exploring those. The, um, the first big push on transformation follows what in software I'd call a strangler pattern. If you're not familiar, the tractor pattern, it's a method for incrementally moving away from legacy monolith systems towards more than architecture. And you build the new systems slice by slice slowly substituting beaches and the old system until the new one does everything the old one did, and then you can retire it. And that's basically what we tried to do with the it organization. We created a shiny new digital division. You worked in a lab in the basement of the office.

00:06:23

We hired new people to work in that division and sold a vision of a modern technology organization with a startup culture. And then we just aim to move stuff bit by bit from it, an individual, but we found that there's kind of an approach just didn't work for us. The strategy alienated the people in the old 80 division who felt that they weren't getting the same opportunities as those who were working digital. And that resulted in all sorts of cultural clashes. Um, the beer fridge instance is probably a good way of illustrating the kind of cultural issues that we faced around that time. So this was where, uh, after months of insistence, the engineers are working in the digital lab, got themselves a beer fridge for Friday drinks. So after all they'd been sold a startup culture and when the organization didn't chip in, they just took matters into their own hands with the approval of their local leadership. But when news of that got out to other floors, that was just total uproar, I guess you partly driven by jealousy, but also probably by a sense that it's not the kind of thing that seems breeds does. It was culturally incompatible with the rest of the organization and HR got involved and the fridge, and I think this just illustrates the mismatch of expectations that we had at a time between different groups.

00:07:51

The other thing that continued to hinder us around that time was that we were still operating with a pure project delivery model. So the finance and governance was unchanged. And we had, I mean, literally around a hundred template documents that needed to be completed to get a project from the inception to the transition phase. And then even the existence of that transition phase assumed or forced completed projects to hand the software over into a separate service operations area kind of makes DevOps impossible. Um, and the funding of teams through projects meant that when a project was completed, the team was at risk, not in an HR way, but I saw many high-performing teams disbanded at the end of projects because there was just no new project for them to work on. And this whole way of working was underpinned by our functional organization structure. So from the CIO downwards, we were organized into teams of product owners and architects and engineers and testers. And that model meant that there was no accountability for actual outcome delivery. So to successfully deliver anything, you need one person from every area. And we found that that structure encouraged lots of finger pointing and excuses, notably the engineering area and the architecture area forever blaming each other for projects not going well.

00:09:17

So in summary, the key lessons we learned from those early wrong terms were firstly, we needed to be inclusive and give everyone the opportunity to participate in the transformation. Secondly, we could only get so far with grassroots change alone. We actually needed to change our structure in order to truly transform. And that didn't mean just mean that the way we were organized, it also meant changing some of our critical processes, which were constraining us.

00:09:49

Yeah, that's right. So the, the thing which really generated some momentum and was a huge unlocker for us, uh, around that time was to flip our organizational structure from functional to divisional. So we regrouped ourselves into cross-functional product families, uh, which each looked after a portfolio of products aligned to a particular business capability. So like marketing, finance, logistics, that kind of thing. And the impact of that structural change was profound and incredibly powerful. It's probably the single most powerful and enabling these change that I've seen in my career, almost overnight groups and individuals who've been actively working against each other, like the engineering and architecture example were suddenly working together with shared purpose is a great example. I think, of, of Naaman's fifth law, that culture follows structure. So this structure change enabled the beginnings of the long drives to move from a project centric, product centric, way of working. And we moved in that direction over time using a number of different interventions to try to incentivize the change in mindset. And we wanted to share just two of the most impactful of those.

00:11:07

The first was the launch of a new operating framework, which encapsulated our new ways of working the framework, included values, principles, and practices, and most practices were important to get finance and audit on board. It was really the principles, which were the key to helping our colleagues understand what was changing and what was now expected of them. They were limited to six to make them easy to remember, and they were used to help colleagues make decisions when planning, organizing, and governing their work. We found principles to be super useful because they could be applied differently depending on the very different contexts, which existed in our division from groceries, online, mobile apps, supply chain, and logistics systems, HR digital workplace, and cloud infrastructure in order to adopt the new framework and taking on the previous lessons learned each project, family was invited to create a transformation.

00:12:06

Scrum. The scrum team was formed with colleagues from their family with a diverse set of roles, represented and supported by an agile coach. The transformation scrums were charged with making sense of the new operating framework for their families. And they did this by understanding the needs of colleagues and deciding on how best to support them with adoption, whether it was training, coaching, mentoring, or facilitation in the round transformation, scrums were a good way to be inclusive and ensuring that the operating framework landed were context for those receiving it. However, transformation scrums weren't successful everywhere and the critical ingredient which appeared to make the difference was unsurprising. The leadership support Stuart, you had some comments to make around the role of the leader in the sames restoring.

00:12:59

Yeah. The role of the leaders key as like an art colleagues through the organization will take their cues from what you say and how you behave. Uh, we found our strongest leaders are the ones that truly bought in to what we're doing. And didn't just delegate the issue to new the hired coaches. No one was looking to coaches for cultural cues and role modeling. Uh, it's the leaders who need to show up here really, um, where you've got leaders who are still diving into details to lead or rescue a situation or telling people what needs to happen or asking for when something complex is going to land at the point of knowing the least about it. I added beginning, uh, not enough has been learned and you're not going to bring about the change. You think you might. The best thing I personally did was read furiously.

00:13:45

So the Phoenix project by gene Kim and others smarter faster, better by Charles Duhigg sooner, safer, happier by John smart and others. The culture code, Daniel coil and Amy C Emerson's brilliant fearless organization, or any of the dozens of the short videos posted by Simon Sinek on YouTube and experiment using the techniques and intentionally so and tell people you're doing it. I found that's the best cue of all for others saying, I, as a leader, I'm willing and trying to learn new and better ways of doing things. You go first, others will follow and be willing to be vulnerable with it. Uh, we found open to some leaders, went a long way to taking people on the journey sharing way are at what you're finding difficult transparency about failures, as well as successes. They're all cues that show teams that you are human too. And that this is a safe space to learn, to try new things, to solve your own problems.

00:14:41

And if something doesn't go right, well, let's learn from it openly and move on. Without fear of being punished. Nick also talked about our inclusive approach to transformation, which was another critical factor for us in an ideal world. You're inviting teams to join the sort of change rather than inflicting it upon them. The fast followers dive in the saggy middle will join when they see that others are getting involved and enjoying it. And then the lifeguards may never get on the bus. Um, of course you need to do what you need to do with the lifeguards, but health, uh, we found is learning to recognize when the invitation is only bringing marginal gains because something bigger needs to happen like a major operating model shift or a reorganization or something like that. Um, reading the situation to assess the balance of invitation versus infliction of change is really key. And if it's the latter, be honest, get it done and return empowerment and autonomy to your teams as quickly as you possibly can afterwards, in order to rebuild trust anyway, back to leadership support. And this time from C-suite down, a huge win for us was a move to devolve governance and what we call product councils over to add to explain more.

00:15:57

Yeah. Uh, so the, the second intervention that I wanted to share, um, so all those next set, our focus was on principles. I also wanted to mention one very significant piece of process change that we made, and that was to funding. So previously technology investment had followed exactly the same process of building a business case and getting approval as any other capital investment that we've made. So in other words, the decision to build an app to help colleagues check stock would be expected to go through the exact same level of rigor as the decision to build a new supermarket or a new distribution center. It was also treated as being irreversible once that decision was made. So in DNC, we had around 350 detailed business cases going through the investment board for approval every year. And it won't surprise you that the result of that approach was a really high write-off figure where each year a number of projects would fail after spending all or most of their allocated budgets.

00:16:59

So under the banner of our simple devolved governance principle, we created eight product councils. And these are groups that are made up of senior technology, business and finance leaders who are given dedicated investments authority for a quarterly budget and a defined product portfolio. So each council, uh, presents a single paper for their entire portfolio on a quarterly basis, essentially asking for the funds to continue running the teams in their area, in pursuit of a defined set of outcomes. They then return the next quarter to report on progress against those outcomes and to request the next course is funding. So that got us down from 350 investment papers to 32. Um, but it also enables a far more strategic conversation at the top level. So rather, shall we build this thing? Yes or no. The most senior leaders in our organization were instead discussing, should we continue to invest in this portfolio when we've not seen a return over the last two courses, you can imagine that this created bar more accountability, and then a level down the product councils as many internal venture capital funds with their allocated budget, it's up to them to decide which bets to fund in order to best achieve their outcomes.

00:18:19

And this approach led to a massive reduction and the rise of because unsuccessful investments were stopped much more quickly, and the division produced a net positive return on investment for the first time, moving from a net multimillion negatives and multimillion positive.

00:18:39

When we look back now, we can see so much of this operating framework has stuck and is visible today. Not least the radical change, the way investments are governed. We're no longer funding projects, but stable cross-functional product teams focused on delivering business outcomes. Our principles led operating framework has enabled a huge amount of positive change to emerge at a grassroots level in each of our teams across our product families. During this time we learned that local transformation scrums were a great way to be inclusive and ensure our new operating framework landed with context. We also learned how critical leadership support is to helping enable transformation to happen. However, we're not done yet far from it over the last few months, we've been preparing for our next big structural change, which is called end to end product life cycle management. We hope this will be a huge enabler for our teams to continuously improve outcomes through broader and deeper adoption of dev ops three years on from the launch of our operating framework and a year after the creation of Sainsbury's tech, which is a single technology organization to serve all our brands, including our GOs nectar habitat and Sainsbury's bank, we're taking our next big step end to end product lifecycle management.

00:20:05

This change addresses our last significant functional silo by bringing accountability for support and maintenance of our products into our engineering families, our service and operations domain shrink significantly down to just service desk, major incident management and service assurance and reporting. It's probably just 15% of its size now.

00:20:29

Yeah. And this is a great example of a change that was originally initiated by the transformation coaching team who recognized that a large number of different groups across the division were experimenting with DevOps ways of working, but then there was no mechanism in place for them to learn from each other, but by creating a DevOps community of interest, we brought the different groups together and discovered that the number of teams who were owning what they built was even larger than we'd expected. And also that all these teams were facing very similar challenges where the organizations structures or processes when supporting them. So we reflected this information up to our leadership team and that experiment was proposed to try to resolve the issues. So what we did was take a single domain of our organization who volunteered also just in our area, their structures and processes for a set period of time to try to resolve the impediments and to explicitly support teams to own what they built for the long term. After six months, the results were really stark. The time it took to resolve incidents fell, our rate of change increased. Our support costs fell, and our colleagues felt more engaged. And this was an effort to give confidence to senior leaders that we should put changes in place to enable this way of working more widely.

00:21:52

The move to end to end product lifecycle management is a big, bold new for us who knows what the future holds. Of course, we'll only be able to look back and see if it's the big DevOps, enabler and unlocker of value for our business, which we hope it will be. Sure. What are your thoughts on the brave new world of each week PLM?

00:22:13

Well, I certainly brave, uh, and I'm really proud we're taking the plunge across all of Sainsbury's tech with eatery PLM, even down to the more traditional old-school areas, such as infrastructure, networks, integration and tools for the job, uh, engineering things, managing the full end to end, uh, delivery and operations of CapEx and OPEX across every tech product is by no mean feat in a large heritage corporate like I was, but we can see already the opportunities to streamline and eliminate the waste and pain or previous ways of working could bring. We told this with our cloud platform teams 18 months ago when delivery and operations teams were separate work into very different goals and forever each other's throats. Um, by moving them all into one team under one single threaded leader, the antagonism virtually disappeared overnight, uh, diverse goals became shared goals with equal focus on value and prioritization of new work and keeping the lights on.

00:23:11

We were clear what we were trying to achieve in this example. And we haven't looked back, you know, transformation is hard and it's slow. And in most cases it's more evolution over time than transformation, which is ideal actually, but it still brings with it uncertainty and worry for those that fear change to help with this. We tried to focus on at all times on providing clarity of purpose so that people felt reassured. They knew where they stood and what was expected of them with that clear purpose we put alongside it, clear accountability teams collaborating effectively as teams, not collections of that's, what our story is about, but ultimately both teams and individuals need to know what they're accountable for. One of the biggest undermining things in our entire journey has been the T turf wars that can break out. If TMA over here is delivering investment B in product C over there. TMX is landing solution, Y which takes product C into an entirely different direction. My council snuff out uncertainty by hand, delivering clear purpose and accountabilities as soon as possible, and then be ready to support as needed as your teams head out to make the new worlds their own.

00:24:24

Hopefully we've given you an insight into some of the things which have helped a 150 year old grocer with a very traditional, mostly outsourced it department transform to the extent it's been recognized for being the best online supermarket. We've told you how we have had much greater success. Once we started to be inclusive about transformation and inviting everyone to participate, we highlighted that brave supportive leadership was the critical factor, which has helped transformation stick. We also explained that we looked to cultivate bottom up, grassroots change as much as possible. However, there were times when structural change was essential to creating deep, long lasting transformation.

00:25:09

So our advice for all leaders out there with a desire to transform their businesses is to have the courage to own your own transformation and make sure you go first and set the example for others in your organization to follow by being humble by listening, by being transparent, and by showing that you are willing to evolve to,

00:25:29

It's not easy, but owning your own transformation, you can go at the pace that's right for you. Bring your colleagues along with you, and you can make the decisions that are right for your organization, rather than trying to copy you mimic or adopt an operating model that's been designed for some other company. Hopefully some of the nuggets that we shared will make your journey of continuous improvement. Easier changes is really tough and takes time, but the sooner you start, the sooner you'll reap the rewards. So good luck.