Host Intro (Gene Kim)

I'm so pleased that the next speaker is presenting. Vivek Gupta is the VP of merchandising technology at TJX.

You may not know TJX by name, but their brands include TJ Maxx, Marshalls, HomeGoods, Homesense, Sierra in the United States; Marshalls, Winners in Canada. They operate over 4,500 discount stores. They are number 75 in the 2022 Fortune 500 list.

I had my first interaction with Vivek years ago, and he hinted that something very amazing was happening within the TJX organization. I'm so pleased that he's able to present, especially as TJX has a reputation about being quiet about what they do. Here's Vivek.

Vivek Gupta

Thanks, Gene. Good morning, everyone. Great to be back here in person.

Let me start off by thanking the programming committee and IT Revolution for giving me this opportunity. I have looked at this stage many times in previous years for inspiration and validation, so thanks to many of the speakers who have come before me. Thanks to this community. I know a lot of you have interacted with me on LinkedIn, so unbeknownst to you, you have been part of my journey that I couldn't walk you through.

I'm also going to mention that I'm humbled to be representing the work of our technology organization. This, as you will see, took a lot of leaders and my colleagues leading the efforts. Again, I'm very humbled.

Let's kick this off by giving you a quick overview of who we are, like Gene mentioned. We are the leading off-price apparel and home fashions retailer in the U.S. and worldwide. We have many brands. In the U.S. we have TJ Maxx, Marshalls, HomeGoods, Homesense, and Sierra stores. In Canada, we have Winners, Marshalls, and Homesense. In Australia we have TK Maxx. In the UK and Ireland, we have Homesense stores, and in the UK, Ireland, Poland, Netherlands, Austria, and Germany we have TK Maxx stores.

4,700 stores. Nine countries. Approximately 340,000 associates. We are ranked 75th on the Fortune 500. We have five e-commerce properties as well, so you can shop at tjmaxx.com, marshalls.com, homegoods.com, sierra.com in the U.S., and we have tkmaxx.com in the UK.

If you have shopped our stores, we do some amazing work: amazing customer experience, amazing treasure hunting, great merchandise, exciting prices. How do we do it? We have real brands. We don't do promotional pricing. We have fantastic merchandise and amazing prices every single day.

We are very smart shoppers. Our buyers are opportunistic and entrepreneurial. They buy all over the world, and we have never the same selection twice when you walk into a store, so you'll find something new. We have multiple trucks landing at our stores within a week. Sometimes our store managers don't know what's in the truck until they open the truck.

There is no one way we buy. We probably leverage all different kinds of buying methods. We buy cancellations. We buy closeouts. We have stuff manufactured for us. We design stuff for us. We operate our stores with amazing flexibility. We don't have walls between categories, so we actually flex our categories within the store based on customer demand. We have a no-frills approach, and we pass all those savings to our customers.

I've been in retail for better than 20-plus years, consulted and worked for very large retailers. The way we do things at TJX, the flexibility of the model, the agility of the model, just blows my mind. Personally, from a household perspective, we are all Maxxinistas. I'm pretty sure there are some of you out there.

Quickly about TJX IT and who we are: from an IT perspective, we have a global function and we support all of that. We support 1,800-plus business solutions that support our business and enable our business with all those typical capabilities that you'll find at a retailer. We support our business and growth in areas like opening potentially new markets, banners, channels, and many large initiatives.

We do have a very robust, industry-leading technology ecosystem. Because we are the leading off-price retailer, our business model is very unique. We have to support that with a leading ecosystem of technology solutions that have grown with the company and supported them through incredible growth the last four decades. However, in 2016 we realized that we needed to continue accelerating our technology journey and keep pace with the anticipated growth that the business was seeing.

As a result, we embarked on this incredible journey that we call Evolve IT. This was the initiative to modernize the way we do IT. I like that term Evolve IT because evolution or evolutionary adaptation is probably the oldest continuous improvement process, and that's what we wanted this journey to look like: that continuous improvement mindset and approach to change.

How did we go about it? What was the scope? We came up with these puzzle pieces. Obviously, this is a DevOps conference, so I'll start with DevOps, but as you can see that was not the first piece of the puzzle. I had great experience with DevOps coming off Nordstrom, as you have already heard in these conferences from Courtney, and definitely wanted to start there.

But what we realized was that we had other pieces of the puzzle missing. The very first one: we were still doing projects. How do you do DevOps with long-standing product teams and ownership if you are still doing projects? For that and other reasons, the first piece of the puzzle for us was moving to a product-team mindset and organization.

Once we did that, there was an immediate impedance mismatch with product teams and waterfall. Obviously the next piece of the puzzle became an agile transformation, because we were still doing projects the waterfall way, and now that we had product and agile, we had to deliver every two weeks.

We couldn't be releasing every three months or weeks. We couldn't be regressing for days and weeks when we do releases in the waterfall model. Now the automation, the operational mindset, and operational excellence all fit into place, and DevOps became the third piece of the puzzle.

Then we looked at all of this and said we need a platform that has flexibility in it, agility in it, and innovation in it. As a fourth piece of the puzzle, cloud became the strategic piece. We were already in cloud, to be honest. We had a lot of SaaS solutions, but this was more about how we strategically adopt cloud as part of this strategy.

Then we looked at this lot of change, and some of us who had gone through this change realized this was going to need a lot of change in mindset, change in approach, change in how we do things, talent basically, and culture: a cultural change. We call that engineering culture. That became the foundation for all these different change initiatives.

In theory, we had our framework, all our tracks, and if we did all this, we would realize the value proposition that we had come up with for the organization.

How did we approach it? I'll talk about the top-down, bottom-up, and middle-out approach. True to TJX culture, we focused on our associates. Our employees are called associates internally, and we empowered them and brought them along for the change because this was very large.

We definitely needed top-down support. Our CTO, Andy San Filippo, was a huge champion of this. Our strategy SVP, Brian Rodrigues, owned and sponsored it. Our CIO bought into this. He took it all the way to the board. We still report our progress to them. This kind of executive support was really necessary because we knew we were going to go against longstanding structures, processes, and things that required that level of support.

We kicked this off almost five years ago. We had a leadership offsite, and I invited Gary Gruver, whom some of you know, to speak about DevOps and digital transformation, and we introduced this framework to our entire leadership team.

The next piece was bottom-up. I was in one of the birds-of-a-feather sessions and talked about radical empowerment. Literally, from a ground-up level, we engaged the engineers, the product owners, and the scrum masters. They were part of this change. They were involved in refining the why, but they were also part of defining the what and the how, owning that change and making it happen.

Instead of a frozen middle, or the next level of leadership, we had very active middle management. They helped us refine most of that vision on what that framework looked like, helped define the what, helped lead the change as workstream leads, and implemented it in their own areas. We brought everybody along for this, and it had to be done that way.

We had our HR partners and change and communication partners. To be honest, they were amazing through this. They made sure the overall change was fair and thoughtful, the communication around it was consistent and clear, and the change itself was impactful and sticky.

It took a village. Everyone contributed. There isn't this rebel-and-empire story. I think all of us were a little bit of rebel at heart to improve the things around us. Our CIO Mark is a great fan of Star Wars in any case. This was our approach.

If I said this was beautifully laid out five years ago and we had this picture, I would be lying. This kind of organically happened, and at some point we reflected on it and made sure this became a framework on how we do IT.

Again, great vision, but like Edison said, a vision without execution is hallucination. How did we do? I'll walk you through the progress we have made and some of the key learnings for each of those puzzle pieces. Fair warning: each one of those pages and slides could be a talk in themselves. I have tried to stay very high level.

Starting with product teams. At this moment our entire IT organization is now organized as long-standing product teams. We have platform teams as well, which are organized as product teams. We have redefined our traditional job families and expectations as part of that: product-management job families, delivery job families, engineering job families. We reorganized that. We had to reset expectations around competencies and expectations.

The big piece was budgeting. Budgeting has now evolved to funding long-standing product teams. It's flexed based on business priorities, but we do have these long-standing product teams that are assured funding every year. Most importantly, we engaged business partners with shared ownership and stewardship of the products.

Key learnings in this: we had long discussions around how to align the product teams. We landed on business capabilities, not value streams. Value streams are silos within business units; business capabilities go across business units.

The second piece: organizational dynamics and talent was the hardest part of this change. Radical empowerment. I'll give you a quick story. I did a small reorg last year trying to align to product teams. We worked with leaders to lay out the vision for that and what the new product teams would be. But instead of going into a room and moving people around, we went back to the teams and asked them to self-select where they would want to land, and we honored every request.

We had 50 people change managers. One of the smoothest ART changes I've ever done. They stepped up. They owned the change. They didn't just move the org side. They reconfigured the scrum teams, the ART, the PI cadence. Our associate engagement went up after the reorg, and we didn't drop any of those business deliveries and milestones. That is practical empowerment in action.

Budgeting continues to be a challenge. We are a publicly traded company. We have obligations around financial reporting, things like capex and opex and other things. We have a great IT finance team that helped us figure it out and balance the two. We still meet all of our obligations, obviously, but still do that with long-standing product teams.

Agile. I'll be quick. The clock is real. Our entire value delivery is organized as agile teams. The Scaled Agile Framework has been adopted across IT, so this is across, no exceptions anywhere. We are delivering value to business at the cadence they want. Sometimes it's two weeks, sometimes sooner, but it's aligned to what they want.

Very high-level key learnings: don't just go through the motions. Focus on the outcomes, both for agile implementation as well as SAFe. We needed a layer of coordination. There were things like Brexit and landing a new e-commerce site and channels that need coordination across product teams, and I think SAFe helped with that.

You need to focus on doing and being. Success is going to be in the middle of that, especially since you are moving from the old ways to the new ways. The way I define doing is, check, we are doing a daily stand-up, versus being: did you need to do the daily stand-up? Did you get the outputs and outcomes you intended from the daily stand-up?

DevOps. From a progress perspective, we have established enterprise DevOps platform teams. We have an internal model of platform teams. We use the three Es: engineering the platform; enabling the product teams and developers to onboard onto that platform, preferably through self-service; and evangelizing, basically talking about the benefits of the platform, owning training, certification, and internal communities about that.

The other thing we learned is balancing standardization across the enterprise versus empowerment and choice. The example is we have a fast-lane product: a set of standard tools that everybody can quickly onboard into. We have standard tools for key capabilities like version control and static analysis, versus different IDEs, different development frameworks, and different testing frameworks. So it is finding the balance between the two.

Implementing telemetry and monitoring for new and existing applications: new applications are easy. Existing applications, those 1,800-plus, were very hard, going back and retrofitting everything to the new DevOps standards, and still something in progress.

Learning: start with the problem. DevOps can be anything and everything, as all of us know. Start with the problem you're trying to solve for each team, and then focus on what you want to do, because you can't do everything. Explicitly enable that feedback from production into development, moving the wisdom of production into development. Look at things like FMEA analysis and threat modeling and move it left, bringing it to the developers as much as you can, and building shared accountability between Dev and Ops leaders if you have different leaders doing that.

Cloud. From a cloud perspective, we now have a cloud-first approach as part of our application strategy. We have established enterprise cloud platform teams similar to the three Es. We have adopted a public cloud platform, and for cloud-native applications we have established an internal platform called Zarvest that speeds up onboarding for new product teams and ensures minimum governance for public cloud as we go along.

Key learnings: make cloud part of your overall application strategy. Don't start with the cloud; start with the application strategy and then define where cloud fits into that. Have a deliberate strategy for public-cloud adoption. That whole service framework had security and everything built into it. Right-size the governance for scope and context. Optimize holistically: don't just look at the cloud spend. Look at all the values, the opportunity costs, the cost of development, and the innovation it brings along with it. Evaluate the need for a cloud business office depending on the scale of your spend and things in the cloud. You may need that. We have that. It helps.

Last piece of the puzzle: engineering culture. We scaled our engineering talent. We established modern engineering job families all the way to distinguished engineers. We focused on competencies and learnability, so we had to change the way we hire, incentivize people, and train people.

We established a community of practice with hundreds of engaged engineers. We have events every quarter. We have had some great speakers: Dr. Steven Spear, Adam Shostack, Dr. Nicole Forsgren, Helen Beal, and many more. We have a few folks who have been driving this. If you follow us on LinkedIn, there is Bala Madhusudan, our principal engineer, who has been driving a lot of these. We have senior engineering managers and others who support this, and you'll see a lot of it on LinkedIn.

We have improved developer experience. We heard the developers and we've been incrementally improving what they want and how we can give them a frictionless and great experience.

We published engineering manifestos. Engineering Manifesto One I made public as well on LinkedIn. You can look at that. Our CTO recently gave a mandate and manifesto about the right work the right way internally, and we talk about that a lot. It's part of our vision and culture and embedded into it.

Learnings quickly. It's a little unconventional for enterprise IT to do distinguished engineers or executive-level roles. There is some education that has to be done internally. We had to change a lot of organizational thinking and processes. A psychologically safe environment was critical.

Codifying some of the engineering mindset or culture is important. Culture can be a very vague thing. It could be anything and everything. Make sure you codify some of that with engineering principles, some of that manifesto and mandate, and leaders, not just leaders by title. Other leaders play a big role in it.

Key learnings: clearly communicating vision and explicitly defining the role and organization was a big piece of the transformation. We had to do a lot of that. Make intangible things tangible and actionable. We didn't have maturity models, but we did create some baselines and targets because we wanted to make progress and measure progress.

The key one here is don't outsource accountability. We had consultants, but they didn't own the change. They didn't lead the change. Our leaders and our organization led that.

Empowerment is called out. Incentivizing the target outcomes: incentives lead to behavior, behavior leads to culture. The cost of coordination needs to be balanced and outweighed by its benefits.

Results. What did we do? We have scaled our engineering talent with more ownership of our solutions and intellectual property. We are releasing value frequently to business. We have reduced overall technical debt and focused on product health. We have been able to support our business and their growth in diverse areas. We have a new set of stores in the U.S., Homesense. We have two new e-commerce properties that came up in the last few years, marshalls.com and homegoods.com, and then many other things: Brexit and other things.

As we've been making these changes during the pandemic, because we were already doing this for three or four years, it helped us react quickly. It helped us accelerate our digital adoption. The biggest thing I would call out is we built this organizational muscle around continuous change and that mindset of continuous change. It's more around that evolutionary adaptation: not change for the sake of change, but evolving to make sure we react to our environment.

Help from you. These are all continuing opportunities: budgeting; any learnings, inspirations, or validation you have around budgeting; overall continuing maturity; measuring DevOps, the DORA metrics, the flow metrics, product-health metrics. There are too many metrics. How do you baseline one and track it year over year?

Balancing speed to market with efficiencies: that's an ongoing challenge within the organization because we're a large organization. For some business units, it's about speed. For some business units, it's about efficiency. It's also at a point in time, so many of these decisions depend on that.

That's all I had. I will do a shameless plug. Processes and tools are nothing without people. All this required a lot of talent, and we are hiring. If you want to work for a great company, great culture, and be part of the exciting work that we are doing, please come and join us. We have offices near Boston, London, and Toronto, and we have a very flexible working arrangement as well. Thank you.