The Sainsbury’s Story

The Sainsbury's story started just over 150 years ago when John James and Mary Ann 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 skill set. Despite that history, earlier 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.

Sainsbury's employs 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 be of interest to the DevOps community.

I'm Nick Poulten, 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 Lloyds Bank, and it seems like a long time ago now, but my background was in project and program management.

And I'm Ed 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 domains. Before that, my career was mostly in product management at smaller technology organizations.

And hi, everyone. I'm Stuart Richards. I'm 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, and modern workplace platforms across the Sainsbury's business. My aim today is to interject the 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 Sainsbury's story applies.

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 change is 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's world.

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.

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 IT 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 in 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 an expensive consultancy in to help us modernize? Well, we're pleased to say we didn't. We did it our own way. Our leaders were brave and committed and owned the solution 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.

Sure. 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 first big push on transformation followed what, in software, I'd call a strangler pattern. If you're not familiar with the strangler pattern, it's a method for incrementally moving away from legacy monolith systems towards modern architecture. You build the new system slice by slice, slowly substituting features of 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. We worked in a lab in the basement of the office. We hired new people to work in that division and sold a vision of a modern technology organization with a startup-type culture. And then we just aimed to move stuff bit by bit from IT and into digital.

But we found that this kind of approach just didn't work for us. The strategy alienated the people in the old IT division who felt that they weren't getting the same opportunities as those who were working in digital, and that resulted in all sorts of cultural clashes.

The beer fridge incident is probably a good way of illustrating the kind of cultural issues that we faced around that time. So this was where, after months of insistence, the engineers who were working in the digital lab got themselves a beer fridge for Friday drinks. 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, there was just total uproar. I guess partly driven by jealousy, but also probably by a sense that it's just not the kind of thing that Sainsbury's does. It was culturally incompatible with the rest of the organization. HR got involved, and the fridge got removed. I think this just illustrates the mismatch of expectations that we had at the time between different groups.

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 literally around 100 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. That kind of makes DevOps impossible.

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 clear accountability for actual outcome delivery. 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.

So in summary, the key lessons we learned from those early wrong turns 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 just mean the way we were organized. It also meant changing some of our critical processes which were constraining us.

Yeah, that's right. So the thing which really generated some momentum and was a huge unblocker for us around that time was to flip our organizational structure from functional to divisional. So we regrouped ourselves into cross-functional product families, which each looked after a portfolio of products aligned to a particular business capability, 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 piece of change that I've seen in my career. Almost overnight, groups and individuals who'd been actively working against each other, like the engineering and architecture example, were suddenly working together with shared purpose. It's a great example, I think, of Lehman's fifth law that culture follows structure.

So this structure change enabled the beginnings of a long drive to move from a project-centric to a 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. We wanted to share just two of the most impactful of those.

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 whilst 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 context which existed in our division, from groceries online, mobile apps, supply chain and logistics systems, HR, finance, digital workplace, and cloud infrastructure.

In order to adopt the new framework, and taking on the previous lessons learned, each product family was invited to create a transformation 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 with context for those receiving it. However, transformation scrums weren't successful everywhere, and the critical ingredient which appeared to make the difference was, unsurprisingly, leadership support.

Now, Stuart, you had some comments to make around the role of the leader in the Sainsbury's story.

Yeah. The role of the leader's key, as like it or not, colleagues through the organization will take their cues from what you say and how you behave. 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 newly hired coaches. No one's looking to coaches for cultural cues and role modeling. It's the leaders who need to show up here, really.

Where you've got leaders who are still diving into details to lead or rescue a situation, or are 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.e. at its beginning, 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. 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 by Daniel Coyle, and Amy C. Edmondson's brilliant The 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 am 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. We found openness from leaders went a long way to taking people on the journey. Sharing where you're 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, 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 this 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 laggards may never get on the bus.

Of course, you need to do what you need to do with the laggards, but helpful, 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.

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 Ed to explain more.

Yeah. So the second intervention that I wanted to share, although as Nick said, 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'd make. 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 the decision was made. So in D&T, we had around 350 detailed business cases going to 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.

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 investment authority for a quarterly budget and a defined product portfolio.

So each council 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 quarter's funding. So that got us down from 350 investment papers to 32, but it also enables a far more strategic conversation at the top level.

So rather than, 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 quarters? You can imagine that this created far more accountability. And then a level down, the product councils act as mini 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.

And this approach led to a massive reduction in the write-offs 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 negative NPV to a net multimillion positive NPV.

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 to 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 learnt 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 lifecycle management. We hope this will be a huge enabler for our teams to continuously improve outcomes through broader and deeper adoption of DevOps.

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 Argos, Nectar, Habitat, and Sainsbury's Bank, we're taking our next big step: end-to-end product lifecycle management.

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 shrinks significantly, down to just service desk, major incident management, and service assurance and reporting. It's probably just 15% of its size now.

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 that 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 of these teams were facing very similar challenges, where the organization's structures or processes weren't supporting them.

So we reflected this information up to our leadership team, and an experiment was proposed to try to resolve the issues. So what we did was take a single domain of our organization who volunteered to alter, just in their 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 enough to give confidence to senior leaders that we should put changes in place to enable this way of working more widely.

The move to end-to-end product lifecycle management is a big, bold move 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. Stuart, what are your thoughts on the brave new world of E2E PLM?

Well, it's certainly brave. And I'm really proud we're taking the plunge across all of Sainsbury's Tech with E2E PLM, even down to the more traditional old-school areas such as infrastructure, networks, integration, and tools for the job. Engineering teams managing the full end-to-end of delivery and operations of CapEx and OpEx across every tech product is no mean feat in a large heritage corporate like ours. But we can see already the opportunities to streamline and eliminate the waste and pain our previous ways of working could bring.

We trialed this with our cloud platform teams 18 months ago, when delivery and operations teams were separate, working to very different goals and forever at each other's throats. By moving them all into one team under one single-threaded leader, the antagonism virtually disappeared overnight. Diverged goals became shared goals with equal focus on value and prioritization of new work and keeping the lights on. We were clear what we were trying to achieve in this example, and we haven't looked back.

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 hard 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 individuals. That's what our story is about. But ultimately, both teams and individuals need to know what they are accountable for.

One of the biggest undermining things in our entire journey has been the turf wars that can break out if Team A over here is delivering investment B in product C, but over there, Team X is landing solution Y, which takes product C into an entirely different direction. My counsel: 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 their new worlds their own.

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.

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 too.

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, mimic, or adopt an operating model that's been designed for some other company. Hopefully, some of the nuggets that we've shared will make your journey of continuous improvement easier. Change is really tough and takes time, but the sooner you start, the sooner you'll reap the rewards. So good luck.