Heather Mickman

Good morning, everybody. And thank you, Gene. That was a really nice introduction.

We're really excited to be back here at DevOps Enterprise Summit this year. It was such an incredible conference last year. It was fun to tell our story and connect with other enterprise IT shops to share learnings and, well, honestly, war stories as well with other large IT shops that are going through similar transformations.

I'm Heather Mickman. I lead the enterprise API integration and cloud engineering team at Target. I've been working in tech for almost 20 years, have worked across all parts of IT from support and ops, security, enterprise architecture, and of course, software development. And I do work with mainframe as well. Less now than previously. And I'm here with Ross Clanton this morning, who leads our engineering practices across our IT org. Ross has been at Target for about 17 years and has worked in many parts of the IT organization as well.

We both have a shared passion for DevOps and driving change across our IT organization. It's been a really fun, though often challenging journey over the last three. Actually, I think we're approaching maybe four years that we've been pushing this change across Target.

What we're going to talk about today are the different phases of driving DevOps and rebuilding our engineering culture at Target. We have started and have made some really great progress starting to shift a large legacy enterprise delivery machine to be a more modern, nimble, agile technology team.

Now, last year, we talked about the early days of this change. We were really operating as skunkworks, small change-agent teams off to the side, but we've made some really incredible progress over the last year, and so that's what we'll talk about today.

Change slides. There we go.

Before we dive into that story, just a little background on Target. I'm going to assume that most people are familiar with Target. Yeah? Quick show of hands. We're one of the largest retailers in the U.S., just shy of 1,800 stores. We've been around for 53 years. And we're also the second-largest importer in the U.S. and have 38 distribution centers.

We have pretty huge scale from a brick-and-mortar store perspective, as well as a large online presence. We have a really massive supply chain and lots of technology. It takes a lot of technology to make that happen. We have hundreds, actually probably thousands, of applications to support our business.

In addition to three data centers, we also leverage large telco data centers, and we have a growing presence on a public cloud provider as well.

In my job, I'm accountable to two groups of people: Target guests and Target engineers.

First, Target guests. At Target, we call our customers our guests, and our guests are at the center of every decision we make, whether it's creating a new experience to make shopping even more fun, or just how I'm prioritizing work on a daily basis.

Now, the second group of folks that I'm accountable to is our engineers. Target really lost sight of the importance of engineering years ago. And we are a technology company, and so we can't be successful if we don't have the engineers within our IT organization to make that magic happen.

It really is our commitment to those two groups of people behind our passion for DevOps and rebuilding our engineering culture at Target.

Now, saying that I have commitment to both our guests and engineers is kind of an easy thing for me to say, but it was really, really hard to be an engineer at Target. Some specific complexities we faced were culture. We had outsourced and offshored our engineering work. Technology was really treated as a commodity. And lots of big implications of that. Probably at the top of the list would be just loss of IP, lower-quality solutions. We just really didn't own our technology work.

Now, we also had a culture of, when something breaks, we just would stop changes. And I'm sure probably many in the audience have that same reaction as well, and same kind of knee-jerk, what do we do when we start to have lots of meltdowns within production?

But then what that starts to do, the implications of that are pretty big. If we're always freezing production, that means we're now pushing our changes in big batches, and that kind of makes the problem worse. We see even more breakage.

Secondly, Target's IT organization is incredibly complex, or was incredibly complex and difficult to work in. There were just lots of silos, and we literally would have silos within silos. Just to get a server provisioned, as an example, that would take 10 different teams to make that happen. So imagine. That's just provisioning a server. Imagine what it would take to actually build an app.

And there just wasn't end-to-end accountability because of all of the different handoffs. It was awful.

Last but not least then was our system complexity. I mentioned we've been around for 53 years. And the way that we had been operating in that project mode versus end-to-end system accountability just meant that over the years, we have built up a ton of technology debt.

We knew that we had to overcome these issues: the loss of team member engineering. We had a lot of zombie processes and projects that just needed to be removed. We had to break down silos, and we needed to move more quickly. So we had a lot of work to do, and we knew we had to start doing something different.

That's kind of the story. That's a setup to where we started Target's DevOps journey and the rebuilding of our engineering culture.

What we have seen over the last three, four years are kind of four stages in our journey. And we didn't plan these stages, but as we've reflected on what we've seen over the last four years, this is how it's kind of unfolded.

First was enabling our change agents. And those change agents are important in the early days because they can demonstrate success, which then helps to start growing a grassroots movement where more and more passionate folks start to get bought into the different changes that are being talked about. And then that got us to our top-down buy-in. That was super important. And that actually sped up a lot this year as our new CIO, Mike McNamara, started.

And now we're in the scale-it phase, right? Trying to figure out how we start taking these different changes and roll them out across our organization.

I'm going to talk about my team as the early change agents and also about growing the grassroots movement. And then Ross is going to talk about gaining top-down alignment and how we're starting to expand across our large IT organization.

More than four years ago, Target realized that we really needed to step up our game in our multi-channel guest experience. But that was really hard for us to do because a lot of our core data was locked in legacy systems, right? I mentioned the mainframe, right?

And it would take three to six months of work just to develop integrations to get at the core data, and that's because there are multiple sources of truth. Our dot-com online systems were separate than our store systems. There were different data structures, different data owners, and of course, lots of different priorities.

Then even when we could get at that data, it would be many, many months of manual testing to ensure that we weren't impacting critical business capabilities, because even small changes could result in problems across the ecosystem because there were so many unique point-to-point integrations in a very tightly coupled architecture.

Now, I touched on the complexities of our delivery model. It was really project-focused. Many different teams specializing in just kind of one part of the waterfall delivery models. So our BAs would gather requirements, and that would be handed off to a tech lead to do the high-level design, and then that would be handed off to the different centers of excellence to actually do the development work, and then handed off to the testing team, then the packaging team, then the deployment team.

It was complicated. There were easily 20, 30 different teams that would need to be engaged, all of which had conflicting priorities. So that meant heavy project management, lots of coordination was needed to figure out those dependencies and the handoffs. So it really felt like our development was more an exercise of waiting in different queues rather than delivering results and getting stuff done.

Around that time, I was leading a team charged with a strategy to build APIs to expose our core data like product information, store locations, inventory availability, the kind of data that you would imagine would be important for a retailer.

And that was really exciting, right? Because now instead of spending three to six months developing integrations to just get store location information, operating hours, whether or not there's a Starbucks in a store, teams could just reuse our locations API.

When Instacart started local grocery delivery in some pilot cities across the country, which by the way, is amazing. If you haven't used it, I highly recommend it. They could quickly partner with Target and just use our products API to get the products information, availability, and pricing.

Makes a lot of sense, right?

But one thing that we knew in addition to building these APIs and exposing that core data, it was really important to challenge how we were doing our work because we wanted to be able to deliver new capabilities in days and not months. And we also needed to ensure that we could scale these APIs because we knew that they would be highly reused.

And I also knew that I couldn't build the kick-ass software engineering team that I wanted to if we were operating in our traditional delivery model, where team member work was more about managing contractors than it was about actually building technology solutions.

So we started talking about Agile, not Waterfall; having our team members do the engineering work, not contractors. We insisted on full-stack ownership so that queuing and waiting was decreased, and we actually had control of our ecosystem. And we brought in more modern development tools, things like GitHub, Jenkins, and Chef.

Now, a couple years into the building of these APIs and the platform to expose and manage them, we also needed to start bringing in technologies to give us the scale that we needed. Things like Cassandra and Kafka to keep up with the growing volumes.

So as we brought in these tools and technologies, they weren't blessed by the enterprise process. In fact, when we asked for permission, we were told no, but we did it anyways because we knew we needed to.

Our API platform and APIs. Looks like we're missing some of the data up there. Our platform and APIs have scaled as the speed of new guest experiences continue to grow. We have more than 90 APIs with monthly volumes of more than 17 billion.

This time last year when I was giving the same talk and had some of these similar metrics, I'm sure that will be shown here shortly. Click. There. There we go. That's right.

The traffic that I talked about last year was 1.5 billion per month. So the jump to 17 billion is obviously pretty significant for us. We do more than 80 deployments per week across our stage and production environments. And the NPV on this investment has been really amazing.

And I don't know about you, but every time I come to work with my finance partners and go through that budgeting process, it's an exercise. But they love when we go through our yearly planning cycle with this because it's a really easy story for us to tell.

These APIs have enabled many internal and external capabilities. I'm sure it will be shown shortly. Yep, there we go. Things like, I mentioned Instacart. We also do curbside pickup. The ability to buy online and pick up in stores are enabled by these APIs, as well as store fulfillment of online orders. Cartwheel as well, and Rich Pins on Pinterest.

Anyways, I won't go through all of them. There's a few listed there. And we continue to see more and more growth. So digital sales were up 42% last holiday season, and we saw a rise of 30% in Q2 this year as well.

And by our peak holiday season this year, more than 450 of our 1,800 stores will help fulfill online orders, up from just over 140 right now.

So our APIs and platforms have continued to scale, and we need to, so that we can continue to support the awesome strategy that our business teams continue to come up with. We're investing heavily in technology because we know we need to. This year alone, Target will spend more than $1 billion on technology because we are a technology company and rebuilding our engineering culture committed to DevOps.

So that's my story of a team of passionate change agents delivering results to demonstrate success. But that change needed to start happening across our broader organization, not just in pockets. We needed to start a grassroots movement. So that's the second phase of the Target DevOps journey.

And Ross and I talk about how we think about that phase starting was, I leaned over the wall one morning, the shared cube wall that I had with Ross, and I was like, "Hey, what do you think about co-sponsoring an internal DevOpsDays? I just read about one that ING did, and it sounds pretty cool."

He's like, "Yeah." So we did. We made it happen.

And we didn't know who was really going to show up to our first DevOpsDays event. Was it just going to be us and a handful of people? And so we were amazed when more than 100 people showed up to our first event. Because we were still in the early days then where when people would hear the phrase DevOps muttered in the hallways, they would roll their eyes and walk away, or nobody wanted to talk about it, right? It still seemed like something that only Silicon Valley web companies could do.

We also started pairing an automation hackathon with our DevOpsDays. And so that was great because it was a day where we'd get our engineers together and start talking about helping everyone understand what is infrastructure as code, what is a CI/CD pipeline, how do you automate test cases? So it was a great way for engineers to sit side by side and share and learn.

Something else that's really important to our story is starting to connect to the larger technology community. Historically, that's not something that Target IT has done well, but that's changing. We brought in amazing external speakers for our DevOps event. All of the folks listed here, and it's been amazing to have them come and talk to us.

We've also created a lot of fun branding around our commitment to technology. I even have my May-the-Force-be-with-you socks on right now. So rebuilding our engineering culture also meant that we needed to rebuild our technology brand.

We started a tech blog. We knew we were doing amazing engineering work, and we wanted to tell the world about it. So you can check it out at target.github.io. We contribute to and we use open source. We're speaking at conferences. We host a ton of local meetups in the Twin Cities. And of course, we brag as much as we can on Twitter.

We now have more than 975 followers. You can see that graph on the bottom there. Nine hundred and seventy-five followers on our internal community, and we've hosted six internal DevOpsDays events. The last one was actually just last Thursday.

So our grassroots movement has continued to grow, and we knew it was now time to start getting our senior leadership team bought in. So Ross is going to describe how we built the top-down support and started scaling.

Ross Clanton

All right.

So when we were here last year, we were still kind of in this bottoms-up phase. We were just on the cusp of really starting to focus top-down, and that's really what happened this year.

So in 2015, we kind of entered the year with suddenly a lot of executive attention. They saw some of the wins that some of these early adopter teams were having. The momentum was building bottoms up. And we actually moved into kind of a transformation that Target's been going through, and DevOps and Agile became really core pillars or goals that we baked into how we're changing our organization, and we suddenly got a lot of attention from the top.

So much so that our executives, our VPs, would do town hall or huddle meetings to share how we were progressing through our transformation with the teams. And they were using the word DevOps so much that my team jokingly said we should make a drinking game out of it. We never actually did.

But if you think back to what Heather said, a year ago, people wouldn't even use the word. It was frowned upon to even talk about it, and now we were using it. It was like a daily conversation in the hallways.

So to drive top-down support, we started to... We have thousands of people in our IT organization. It's a massive organization. How do you scale things, and how do you look at how you're going to drive this change across the organization?

So top-down, we aligned with the ThoughtWorks CI/CD maturity model. We use that to start baseline measuring our different products across the company that are in our different portfolios. We set some goals and aligned some DevOps champions throughout the organization to help drive these practices within their spaces and be champions within their specific teams.

And then we also did something that I thought was great. We were so inspired by the conference last year. I know Gene shared my quote at the beginning, and we're like, great, we've got all this interest and attention now, but we have hundreds of middle management, even just in the IT organization, and a lot of them hadn't been exposed to this thinking, and they weren't exposed to what we get exposed to when we're interacting with folks out here.

So we decided to do our own little kind of mini DOES Summit inside Target, and we invited folks that we thought had really relevant stories based on where we were going. So you can see the folks we had there. Gene came in and keynoted. We had Jason Cox, Scott Prugh, Johnny Wooldridge, Courtney Kissler, and Nicole Forsgren all kind of made up this team.

We made a one-day event, and they essentially gave the same presentations they gave at the conference last year, but we were able to have all of our management in Target in our IT organization involved in that discussion and learning from folks. And that was a tipping point for us in our movement. We energized a lot of people, and suddenly everyone was coming to the table saying, "All right, how can we get involved? How can we help?"

So now we had to figure out: so that's top-down. Great. We've got the alignment. We've got support. Now, how are we going to actually scale this?

So that's a challenge. We gave this talk at Velocity a few months back, and I actually asked the audience, there was a few hundred people in the audience, who's figured that out? Like, who's figured out how to scale DevOps practices across a massive organization? I think two hands went up.

And I did get a chance to connect with the Capital One guys after. That was one of the hands that went up. You should talk with those guys. It's really impressive what they're doing. Topo's rocking it, so wherever you're at, great job.

But we knew that we had to scale these practices across a very large organization. So how are we going to go about doing that?

First, we had to look at our structure, and there's some structural changes that we've had to make. The model we're moving from, and we're in the process of this transition right now. Our organization was largely a COBIT-based, highly segmented model where you, Heather talked about it earlier, you had all these teams that had to come together to get anything done.

And we're moving essentially to a product and service model, very simplified accountabilities. People are accountable for their entire stack. We've established key practice areas within the organization, so think of skills that we want the entire organization to learn and apply in their jobs. It's a key role that I actually have.

And in our delivery model, we largely are shifting from a waterfall-based model that we applied to almost everything, where every unit of work that came into our IT organization was a project. That was the only way to get resources, to get money, to get anything done, was to have a project. And you'd have hundreds of projects. And it was crazy.

And so we've shifted to this product focus, and the models that we're largely embedding into the organization now, it's mostly Scrum- and Kanban-based models to actually do the work based on characteristics of what the team is made up of.

And then our technology modernization strategy. We have a lot of legacy. We have a lot of different tightly coupled integrations in our environment. For key strategic capabilities, we are very focused on moving those things to a more modern technology architecture. So API-based, loosely coupled architecture, lightweight tooling, self-service. We're trying to drive as much self-service into the organization as we can.

Things that are really optimized for cloud-based development and CI/CD practices. We're still working out how to apply this to legacy as well. Obviously, different challenges, but we are trying to get as much right with our modernization strategy as we can.

So great, we moved a bunch of boxes around. People changed reporting relationships. That doesn't actually change much of anything in terms of how people work.

So now let's talk about how. How are we trying to impact how our teams are doing work?

One of the first things we did is we started to converge some movements. We had a large Agile movement, and we had a large DevOps movement, and we were kind of loosely connected, but we weren't as close as we probably could have been. We converged those efforts, and so we're kind of driving those jointly as part of our transformation.

And we also started pulling in our organizational effectiveness organization to really look at how do we scale learning? And it's going to be a combination, it is a combination of traditional training experiences, but more focused on coaching and hands-on immersive experiences.

So we came up with an idea. This is one of my favorite parts of our journey right now. We created an internal incubator environment. Publicly, I'll often refer to it as like a transformation immersion center. We call it the Dojo. So the place you go to practice your craft.

The Dojo's huge. You could fit probably three or four of these rooms in our Dojo. And the idea is teams come to the Dojo with their real work. We have coaches and subject matter experts that work with them in a very immersive environment and show them how to apply new practices to get that work done. They typically are in there for a long enough period of time for some of this stuff to sink in.

There's a lot of activity there. We largely are trying to create what an engineering culture should look and feel like in the Dojo, and you can see pictures of the Dojo on the screen there. Our CIO is up at the top there. He's made multiple visits in. Gene's been out there. John Willis has been out there. It's been great to see some of the evangelists in the community out experiencing and participating in what we're doing.

So the Dojo really has three primary services.

The first one, and I've talked a little bit about these last year, they weren't as formalized as they probably are now. The most important one, I would say, is what we call challenges. And the challenge is at least a 30-day, sometimes we go longer with them, a 30-day experience where a Scrum team will actually come in with their work, and they work in the Dojo in a fully immersive environment.

They're doing two-day sprints. They're demoing every two days. We're teaching them all of these engineering practices, as well as Agile practices in terms of how they're doing their work. And we get them immersed long enough where they get comfortable working in that way. And then after the challenge is done, they'll move back out into wherever the team came from.

And then flash builds is something we did a lot last year. We do it a little bit less now, but think of that as one- to three-day events where the team is a little bit more competent coming in, and it's more of a way to collaboratively, quickly build a solution, build a product.

And then open labs is really open to the masses. And so we have twice a week, people can come down in the Dojo. We have all the SMEs there and available to work with them. And that's important because we want to be accessible to everyone. We can't put everyone through challenges. We tend to focus those on our more strategic priorities, and so we want to be accessible to everyone, but we can't put them all through the formal training.

So how do we actually prioritize demand?

The challenges, which is kind of the main service that we provide there, we do focus on our strategic priorities. We can run up to 10 of them concurrently in the Dojo. We have eight going right now, actually. If we don't have a capacity issue in terms of coaches or space, then that's great. We'll take in whatever challenge people want to do.

When we do start to run into capacity issues, then we focus back on those priorities. And so that's the formal way for folks to get in. And then informally, we encourage people to bring their friends down, come to the demos. We have an open demo lounge in the Dojo that everyone can see and participate in. Bring your friends down and take some WIP off someone's Kanban board even. It's great to kind of informally and organically grow that culture as well.

Results so far. The Dojo's only been up for four or five months, and when we started, we had one challenge going, and then we had a couple, and right now we have eight concurrent. We've done 14 challenges, six flash builds. We've had over 200 learners cycle through that environment.

And they've gotten all kinds of great results. I'm not going to read all this. Whoa. I'm definitely not going to read it. I'm not going to read all this, but the results people are largely getting are learning how to take what would take three to six months before and do themselves as an empowered team in minutes, right?

Building a full-stack environment. They can do that themselves when they come out of the Dojo. That would take three to six months previously. Learning how to work in a collaborative environment where everyone can contribute and merge code, and it's not one person's role in this big batch activity that has to happen at the end of some cycle. Learning how to work in that kind of highly collaborative environment where you're supported working with each other on these Scrum teams.

And we've actually put our executives, this is actually our CIO's idea, we put our executives through a hands-on DevOps workshop. And not so much... They actually pushed code for real. They wrote some lines of code, and this is our VPs, directors, CIO. We kind of fed them what they had to write, and it wasn't to teach them how to be good coders. It was for them to build empathy and understanding for how their engineers are supposed to work in this model.

That was huge. That was one of the best events I've seen with that group together. It was highly interactive. We were able to dive into some deep concepts with them. And it worked out so well, we're actually rolling that same workshop out across a lot of our middle management now as well, and so we're going to do multiple iterations of that.

And by the way, some of the things that have come through the Dojo, they are some very strategic capabilities. We've had our point-of-sale system in there. We've had inventory, pricing, promo. These are very, very important retail capabilities.

So what have we learned over the last six months?

One, MVPs rock. People have a tendency to plan for everything and want to boil the ocean. In the Dojo, we talk about the skateboard. I don't know if people are familiar with that diagram, but if you want to build a car and you want to show value along the way, build a skateboard, then a scooter, then a bike, then the car. Don't build a tire, another tire. Your customer gets no value out of a tire, right? And so getting people oriented around what it really means to build an MVP and continue to build off of it.

We've learned that a successful challenge needs a good charter. We were a little loose at the beginning, and it was hard to get alignment and commitment from folks at times because it is a big commitment to spend 30 days in this environment, especially when people were sometimes assigned to multiple things. So doing a more formal charter where people actually signed off their commitment was really important.

Don't overly focus on one area. When I started my organization, we were probably a bit infrastructure-focused because that's where I sat in the organization, and so a lot of our coaching was oriented around config management, infra as code. We've now expanded to cover more of the software engineering practices as well.

Befriend your landlord. And everyone I've talked to in a large enterprise that's trying to go through this type of transformation has challenges dealing with their space people and getting alignment on making a space that open and collaborative. It's amazing how difficult that can be. Take them on the journey with you as much as you can. I mean, at times, I feel like we were pushing pretty hard on them, but be friends with them. Take them on the journey.

Expect the unexpected. We lost one of our champions, a VP that was a big driver for this movement. That was at risk of setting us back. We had to regroup and make sure we didn't lose momentum.

And then ultimately, get comfortable with being uncomfortable. This is a big change for teams to go through, and it is uncomfortable. We have this sign plastered in the Dojo. We have all kinds of cool signs, but the get comfortable with being uncomfortable is an important one.

Where we're going. So we have a large captive center in Bangalore of employees, and we're trying to drive this movement across the entire organization. There's been a lot of great things happening over there from a DevOps perspective, but we're actually looking to formalize the Dojo there as well. So I might have more to share on that here later this year.

And advice for others. I'll go real quickly here because I think we're short on time, but don't wait to start. If you're thinking about how you're going to approach DevOps, what kind of transformation you're going to make, just start doing something. You can plan and talk about this stuff forever.

Be exclusively inclusive. And we say that kind of tongue in cheek, but when you're pushing for this kind of change, some people will feel like you're actually being exclusive because you're kind of challenging the way that they're working. You got to figure out how to pull everyone in close. Try to not make it the cool kids club, which unfortunately we get that label at times, and we're trying not to do that, but that's how it can be viewed internally within an organization.

Empower your change agents. If people are seeing challenges, they've got to be bold. They've got to speak up. If someone speaks up, others are probably feeling those same things, and they will join in and you'll get your movement started.

Unlearn what you've learned. This is hard. I've been four years at trying to build my Agile mindset and my DevOps mindset, and I'm still on that journey. For people that aren't really going after this as hard as folks like I am, it's hard. Executives have learned to think a certain way. They've gotten to where they're at because they've driven IT a certain way. Teams have been operating a certain way. You got to work on breaking that down.

And then connect in that broader community. This is a really powerful, supportive community. People actually want to help each other here, so tap into that and get involved.

And so what we're still looking for help with, this is our latest experiment on how we're trying to scale, but we still need to figure out how to scale these practices across thousands of people. That's a big challenge. So if anyone has ideas there, love to hear from you.

The other thing I would just say is I feel like we get a lot of credit for what we're doing in the community, but we're still just starting this journey. And I just want to make sure people realize that, that this is a long and hard journey. We're going at it hard. We're sharing our story as we go. We're doing some really cool things, but we got a long ways to go.

All right? Okay. Thank you so much.