Jakob Knutsson

So, warm welcome to this session by the H&M Group. My name is Jakob Knutsson. I'm here to talk about how we're integrating our business with tech. We're going to break down the importance of incorporating tech into the DNA of our business, and how tech is fundamental in everything we do.

We're going to talk technology, cloud, culture and community, developer experience, and tech standardization. We've created a brand-new product organization where we explore new ways of working, where we have a customer-focused mindset, where we embrace our strong values and release the power of people to really innovate and develop products that are giving our customers meaningful impact all over the world.

But who are we? The H&M Group consists of multiple brands, making it possible for customers around the world to express themselves through fashion and design and to choose a more sustainable lifestyle. We create value for people and society in general by delivering our customer offerings and developing that with a focus on sustainable and profitable growth.

H&M Group was started in 1947, when the first H&M store was opened. It was the result of testing a lot of different business ideas and, of course, a wish to build something great. Our founder, Erling Persson, was unafraid of failure, inspired by success, and driven to create customer value. So he tested idea after idea before H&M was born. The journey from small beginnings in a Swedish town called Vasteras to the company we are today is one of growth, and also of trying to keep things simple, using a lot of common sense, and doing great things for our customers. It's about opportunities captured. It's about lessons learned. Pretty much things all tied to the DevOps cycle.

I don't think that anyone could see how much the world would change since it was started. But I think the H&M values have guided us and helped us navigate in these changes. We started our first online store already in 1998, and now have around 5,000 stores worldwide and are available in many, many online markets.

Last time we spoke, the pandemic had hit, and we've all now gotten used to online events. So I'm presenting from my home office today. We're slowly going back, trying to keep it safe, to our offices. But we all know the future is flexible, especially working in tech.

In 2020, just before the pandemic hit, we had started one of our largest transformations. We merged our business development with our IT business functions and created a product organization, which we call Business Tech. We now have over 350 product teams that have end-to-end responsibility for their part of the value chain. And we did this almost fully digital, since we all know what happened in 2020.

Why do we need to continuously evolve? Well, of course, as the world changes, retail is rapidly changing. We're now living in the age of software. We don't see ourselves as primarily a software company. We're still a design and fashion company, but we must master software at scale. We see a lot of changed customer behaviors. We see a completely changed competitive landscape, and so much innovation is fueled by tech. It has changed how we consume, how we listen to music, how we do last-mile transportation. It has changed so many things in our lives.

Going back to Business Tech: why did we start a product organization from the start? We wanted to focus on both customer and business value, and saw that tech is a fundamental building block. We formed Business Tech around both getting up our speed, being able to respond to changing demand and expectations, and the focus on bringing great customer value.

When establishing our product organization, we wanted the teams to have end-to-end responsibility, for them to be multi-competent, and to be able to handle everything they need for their part of the value chain. We talk a lot about aligned autonomy and autonomy, pushing a lot of the decisions to the teams. They know best what's right for their product. Of course, we want them to use DevOps practices. Being such a large enterprise and engineering organization, how do we communicate which directions we are going? We've implemented objectives and key results to guide us along the way.

With all the principles, we also have a strategic direction. I mentioned objectives and key results: where do we take aim? What is our North Star? What's our goal? Where should we go in the future? Along with that, we have some prioritized focus areas: what's most important right now? Where do we need to focus?

Jumping back to our principles, in our tech landscape, or when establishing our digital business model and capabilities, we want to be customer-centric. We want to be open and composable, and really leverage reusability when possible. We want to be agile, fast, respond to change, and be able to release on demand. We want to be data-enabled and intelligent. We have so much information flowing through all our platforms and systems, and we want to be able to leverage that data to take data-driven decisions. And, of course, we want to be secure and global, bringing the best experience to our customers wherever they are, in a safe way, to safeguard both our customers and our brand.

Looking then to the role of core engineering, enterprise architecture, and platform teams in a product organization: what role do they actually play? As I try to define it, our job is to provide our teams with the right technology at the right time. So having the right tech at their fingertips when they need it. We want it to be in a standardized way that's secure and easy to use from the get-go and at the start. Of course, that means looking into golden patterns, how we develop things, and other types of Lego blocks which you can use to build your applications and services. And we want to really focus on having a great developer experience.

If we zoom in on having the right technology at the right time: we've been on a cloud journey, as I've talked about in previous sessions, for the last couple of years. To enable providing tech with autonomy and self-service, we've taken a bet on cloud. We say that all of the H&M Group should run entirely in the cloud, supported by an organization that can build effective and secure cloud solutions using DevOps practices. We're well into our cloud journey. We had a one-cloud strategy that has served us really well these last couple of years.

Now we have taken a step back, assessed, and we want to provide the best of breed, the right tech at the right time. So we're constantly improving and setting our direction. With that, we have actually now gone multi-cloud.

What does that mean for us? We get access to more types of capabilities. We get faster time to innovation, since the different cloud providers innovate at different paces. And it's a mitigation of lock-in risks. There are so many other types of benefits: compliance, resilience, access to more geographies, talent attraction, et cetera.

With multi-cloud, we still default to a single cloud, but choose the right cloud for the right type of services. We look at, of course, the technical fit, but also the surrounding gravity of the applications and landscapes to find the best fit for that type of solution. We use conscious portability. We try to talk about tech standardization, and I will expand a little bit more on that.

Of course, with this kind of technology and strategy, there come a few challenges. As I mentioned, landscapes and data gravity need to be considered when deciding where an application will reside. We know that cloud-to-cloud traffic patterns will be more and more common, and that both publishers and consumers of events and data will reside in both clouds. To guide our organization, we've worked on a workload placement framework so that they can find the cloud with the best fit for their particular service. As I mentioned, it's not solely based on technical fit. There are so many aspects that need to go into these types of choices.

We talked about the right technology at the right time. Now looking at tech standards and guardrails: how do we actually make 5,000 engineers effective? And how can we make our tech landscapes more homogeneous? We focused a lot on speed and innovation and being able to capture ideas when we established and started our cloud journey. That was our main focus. Now we're looking into how we can better and better optimize and standardize to improve both engineering experience and efficiency.

We think that tech standards and tech standardization allow us to move and innovate faster, with better results and higher efficiency. We're doing that by aligning our standards and engineering practices. We believe that our product teams should focus more on building the differentiating features for our business, and less on things that can be common across our landscape and teams. We also believe that a fragmented technology landscape and unaligned engineering practices increase the cost of both building and running services. It exposes us to more risks and decreases speed and productivity.

We also think that we should invest more in our learning culture for engineers, establishing and developing our learning paths and aligning them with our tech standards and golden patterns. These types of practices and standards are not only for our in-house engineering capacity; they also apply when we use partners.

A little comment on autonomy and alignment versus tech standardization: I think it's easy to get lost when defining principles and guidelines. But staying true to our values, we should keep them simple, to the point, and clear, with the goal of helping our teams and business achieve success. We also balance creativity, experimentation, and team autonomy. But we believe it's important to align on what are firm principles. Team autonomy is not all or nothing. By being clear on engineering practices and standards, we are defining what type of engineering and tech choices and autonomy we give to our teams.

An important part of taking these strategies, philosophies, and principles, and making them part of our community, is of course building culture and building a community. As I mentioned, we want our teams to have end-to-end responsibility for our products. We want to see a culture of automation and paying off technical debt. We want them to learn from failures, both others' and their own. We want to have a smooth, delightful, and great developer experience. We want composability and standardization so that it's clear what's out there, what's easy to reuse, where to start, and where to focus on business features. We want our strategies to be easy to understand, and for people to know where to reach that information. Everything in this is to enable a constant flow of value.

Looking into how we started building our community, we started doing a lot of knowledge-sharing sessions and events. We invited people to forums and hack days, and slowly started to spark that curiosity when it came to cloud, APIs, AI, and data. So we started building that community. When you start, you need to be really approachable, and out there to help and guide.

One way we did this was to establish an engineering or developer portal, where we have documentation, guidelines, and guardrails. We have our how-tos, patterns, and practices. But it's not only a portal. It's communication channels and threads. We now have our tech conference for the second year, where we're so proud that Gene came and did a session. Super thanks for that. So grateful. We also have adopted the tech radar concept to see where we should focus our energy and where we should sort of hold. All of this is community driven.

One thing I want to highlight, and I think I've mentioned this before in many of the sessions, is that one of my favorite channels in the TechSpot community is the Absolutely No Idea channel. Where do you actually turn when you don't know where to ask? There are so many questions going into this channel, and people are just jumping in to help and answer. It's so vibrant, inviting, and funny. A great community.

Looking into building a great developer experience, and looking into why you would want to use DevOps practices: these are facts and figures that you all know about and almost know by heart, I would guess. We know that the software delivery elite performers, if you want to call them that, the ones that are doing really, really good, are faster, deploy code frequently, have a lower change failure rate, and are faster to recover from incidents. So we of course want faster time to market, better customer satisfaction, and we know that it also affects the results.

When we're talking about software delivery at scale, what do we mean? It's about engineering excellence: providing the tools necessary, with patterns, so that we can achieve excellence, and providing the right tech, of course. When it comes to composability and reusability, we want to have those components in place. One way to achieve that is that we're working a lot with inner source as well as open source. When it comes to inner source, it's about keeping our repos open so that we can actually go in and look and learn. It's not so much about other teams swarming and making pull requests in your repo. At this point, it's more about looking into and learning. But of course that happens as well.

With that, we want to have a learning and collaborative engineering community where you can reach out and get help, or get the pointer in the right direction where you need to. And we want to get our software out in a secure, stable way, getting an effective development lifecycle and supply chain in place.

If we look at this from an end-to-end perspective, these are just questions that we ask ourselves daily, and then can also look into: are we actually living up to this? What do we need to change in order to answer these questions? This is looking at both the onboarding of new engineers, how to make them effective from day one so they can touch code as early as possible and know our strategies, all the way to running the applications, and then both evolving and achieving excellence as well as promoting and recommending H&M, and believing that this is actually the place to be if you are an engineer.

Looking into challenges: we are in a global competition for talent. We constantly need to revisit and look at how we create aligned autonomy for 300-plus product teams, and how we know that we are progressing. We can look at the DORA metrics, but how do we know that we are moving in the right directions? It's hard to measure on enterprise scale. Establishing tech standardization and engineering practices is also somewhat of a challenge. I think we're doing great things and moving in the right direction, so it's all about adapting and learning as we go, involving the community, and bringing the total knowledge into the enterprise body of knowledge. We know that there is constant change, and we need to constantly develop our people. So that's some of the challenges we are working with.

We are embedding digital and tech in everything we do. We believe that we need to continuously evolve our digital, tech, and data capabilities, develop our people, and, to be relevant, we need to be customer-centric, driven by data, and really empower our colleagues. We're not here to serve the business, but rather to solve problems for our customers in ways that serve our business.

I want to thank you all for listening and end the session with a quote from our founder, Erling Persson, that was relevant back when H&M was started and still is today: the secret of our success, there is no secret. The industry is so dynamic that it's absolutely necessary to constantly renew yourself and have a flexible mindset.

With that, I want to say thanks, and I hope you enjoy the rest of the conference. I will listen to as many sessions as I can and try to really absorb and learn. Have a great conference. Thanks. My name is Jakob Knutsson. Bye.