 So as Rob said, Matt and I are going to co-present and we're going to talk about what it's like to work in an environment where you're really in kind of two states. You've got future modernization efforts underway and then we have our existing capabilities which we still have to improve and support. So I'm going to go over this really quickly because hopefully most of you are from the Northwest so you probably already know about Nordstrom. I'm going to ask the question that I asked, how many of you are customers of Nordstrom? Awesome, I love it, thank you. So here's how we think about the properties at Nordstrom. So we have our full price offerings which are really our full line stores, Nordstrom.com website, our full line mobile apps. So we've got an iPhone app and an Android app. So that's kind of the full price component plus we acquired a company called Trunk Club. This is a pretty cool offering, essentially you sign up, talk about the style that you prefer and then a trunk gets shipped to your house. Hopefully matches your style and you keep the merchandise and we launched that for women in the fall of last year too so you can do both. And we opened stores in Canada this year for the first time including Vancouver which is a beautiful store so if you get a chance to go up there it's gorgeous. Then we have our off price offering which is our rack stores, Nordstromrack.com and then Holtlook which is kind of a flash sale capability in the digital space as well. So as you can imagine in most retail organizations technology is a strategic enabler. So for us it's all about speed, reliability and really taking our in-store experience when you shop our stores, it's very high touch, having that show up in the digital context as well. So extending that experience into the digital space. It's kind of the flip in the digital space, we're very convenient, free shipping, it's very easy to shop our digital properties. Not so easy to do that in the stores. If you go in the stores you want to do a quick return or exchange, it's not super seamless. So kind of trying to bridge that gap between digital and brick and mortar. And reliability is also a focus for us. So I'm going to ask Matt to come up here, where's Polly? Is Polly here? Polly! Hi! Yesterday you had made a comment in your presentation about finding an example of where product management and kind of development and engineering have kind of a high-performing relationship. So I'm super excited because Matt's going to talk about this case study which is a really good example of where that bridge has been connected. Sorry I'm like 10 feet tall, let's see how this works. Awesome to see you. Such a great turnout here you guys, really excited to see you all here. So like Rob said, my name is Matt Hornsby, I am a principal engineer at Nordstrom and I was working for about the last year and a half on modernizing a big portion of the Nordstrom website. This is the product page where all of our purchases go through. It's where everybody goes to click on the button to add things to their shopping bag and so it was a big undertaking. We went from a very kind of old and crusty legacy system and modernized it. So I know what you're thinking, he doesn't look like an engineer or a manager. He looks like a male model, I know. What can he tell me about DevOps? I get that almost every day that question. Actually I just bought this shirt for this so this is not. This is what working at a top fashion retailer does to you. It breaks all the engineering molds and stereotypes. So I haven't done this presentation with Courtney, this is the first time so I may go a little off script here but I'm going to try to keep it on track here. Like Courtney said, there's a lot of technical stuff that we can talk about here and I would be happy to go into any questions that you have. I'll be here, we can do some Q&A, I can also talk to you guys after the fact. But one of the things I really wanted to spend some time talking to you about was a little bit of the journey that we went through but really not so much the technical aspect of this. I found that the technical part of getting a DevOps movement going on a team is actually the easy part. The hard part is the people. The hard part is getting the team functioning properly. There's a secret sauce that when it comes together, it is really powerful and it's really amazing to see and we had a good case study on this and transforming this product page. Reveal, all right, here we go. So as you can imagine, Nordstrom's website is pretty, there's a lot to it. It's been around since, well, like the dawn of the internet. If you went back, you can look at the way back machine and you can see Nordstrom's website in 1994. It looked pretty awesome by 1994 standards. Not so amazing in now, today's standards, but it's been around for a long time and we've built things over time and we've had a lot of legacy stuff creep up over the years. This was a website built on classic ASP and it's gone through a bunch of machinations to get it up to where it is today, which is still in a hybrid state. So one of the challenges that we had here was how do we take this and make it take parts of the site? How do we find some success in modernizing the site in a way that we can actually sustain and that doesn't completely bog us down and make us throw our hands up and give up? So this is sort of a long quote, I won't make you read all of it. But this is one of my favorite thoughts by Christopher Alexander. One of my favorite set of books, he wrote a timeless way of building and a pattern language and a couple of other ones there. But this really sums up the aspect of how we went about doing this. And really what he's talking about here is you need to have regions that are able to be self-governing. You need to be able to carve off boundaries around things so that people can solve their own problems. So that teams can solve their own environmental issues. And what I love here is he mentions that if there's just arbitrary communication patterns, arbitrary ownership over things, it makes it almost impossible to solve problems in a regional effective way on teams. So one of the things that I find really interesting about this is how many of you, this has been sort of a topic that's come up a lot recently. How many of you are familiar with Conway's Law? Okay, most of you. One of the things that's interesting there, Conway's Law essentially was an observation that was made, I think it's been around for a while, at least 20 years. The thought was if you have a company or a team that is designing something, it doesn't have to be software. But if you're designing systems, you are bound to create systems that mirror the communication and political structures of the teams themselves. So the idea is if you have really siloed walled off teams that don't talk to each other, they're gonna create software that is really siloed and walled off and doesn't talk to each other. The old joke is like if you have a team that creates a compiler and there's three different teams working on it, you'll end up with a three pass compiler, right? So if you look at some of the companies out there, you can see how this takes place. And I think most people have seen this in practice in their day to day lives. If you look at something like Facebook, they don't really have a hierarchical structure, they have sort of a network of people, a social graph, if you will, inside of their company. And so if you look at their software, it's really based around that. It's based around the social graph, the social network. Everything talks to each other. If you look at, if you go on Facebook, there's not a lot of cohesion in the functionality on the site. It's sort of all a whole bunch of things, and it's all based around the social graph. And if you look at something like Apple when Steve Jobs was still alive, it was like, you would look at it and it was sort of the graph would be there's a circle of a whole bunch of people and then Steve Jobs right in the middle and everything went through him. And so you see that in an Apple's ecosystem and in their applications. Everything is very walled off and walled guard and all of that stuff. So this is super important and Conway's law, you can put it to use. It's not just an observation, it's not just like an office space moment where it's like, haha, that's, yeah, we've all seen that. You can make this work for you. This is the thing that is so powerful about it and this is what we did on the Nordstrom website. And I've taken teams before and split off sub components of teams and actually move them to different parts of the building when I wanted to build software that was very cohesive and I wanted it to be walled off. So you can do this and it's really powerful, just the fact of moving people somewhere else, just down the hallway or to a different floor or a different part of the building can be really powerful. Let me make sure I'm not going on too long here. So this is a very powerful aspect to getting sort of the DevOps movement and culture working. You have to give teams the ability to make local decisions. Wall off the teams if you can. Give them something that they have 100% autonomy on. It gives the team's freedom to not get bogged down and not, in our case, not get bogged down in the quagmire of our legacy system, right? So we had a lot of different stuff going on. And if we had to worry about all of the other pieces of the puzzle, we never would have gotten anywhere on there. So the team had nearly 100% autonomy, like soup to nuts. They built out their own pipelines for deployment, their own CICD pipelines. We built it off on go and were mainly Windows based for what we were doing. So a lot of PowerShell, a lot of CloudFormation stuff for AWS. But they built it out. And we had, this is an interesting phenomenon, because we had a lot of different teams working in this space and running alongside each other, sitting next to each other in some cases. And they were doing things differently. We had the team I worked on built out their own pipelines and their own automation. We had teams that were sitting next to us doing their own thing, doing it a slightly different way. And having that autonomy built the culture of the team in such a way that they felt empowered to do it all, to do everything and to own the fate of the software. So part of this was also an emphasis on continuous improvement for the team. So they owned all of this. They owned the delivery. They owned the automation of the pipelines. They owned when they deployed things to production. And one of the key things that we were looking to get away from was a very painful, lengthy, five-week delivery cycle. And it's kind of funny, because if we went back four or five years and we said, man, how often are you delivering, you're delivering every five weeks? That's amazing, right? Teams were deploying things every few months, every six months. And yet, here we are today talking about doing multiple deliveries a day. So the path that we went down was we broke away from a five-week delivery cycle, very heavy with process to delivering on demand, feature by feature, flowing through a pipeline every day, multiple times per day. So some of this I covered, I won't go into it too much here, but we treated, we moved away from sort of a centrally managed team to ownership on the team of everything, all of the delivery and also support as well. So no more offshore support, no more centralized support team. We owned it all. People started getting paged as soon as we went live with this. And that was also another one of the really key behavioral shifts here. Once you put this responsibility and accountability on the engineers writing the code, there is a very definite shift in the cultural behavior of the team. And that's another one of those things that is just so key in building out a delivery team, a DevOps team that is high functioning. So that was one of the key things, just that accountability. We gave the team a lot of autonomy and never said no to anything. And in order to build in this sense of continuous cultural improvement, we gave the team as they were on their support rotation. We had a one week support rotation that the engineers would take. They weren't expected to do any work for delivery during that one week period of time. And they were given the opportunity to build a small improvement for the team every week, every time, every week we had somebody doing that. And it was a deliverable to help improve the team, improve the automation, improve our monitoring or alerting, make the team's life better. And so every week we had somebody rotating through that. And so after months of doing this, we just had this list of amazing improvements that the team was able to make. And it reinforced that culture of improvement and ownership on the team. One thing that Courtney mentioned, and I'll end with this. One of the most important pieces here was having a great relationship with our business partners and our product and program management. We had somebody on the team that we didn't have to go for, we didn't have to go talk to somebody in another building. We didn't have to schedule meetings. We had somebody driving our requirements and working with engineering on the floor, living in our area at all times. And that maybe was the biggest sort of secret sauce in all of this. It's having that relationship and having the person where you can go to them. And they represent the business, they're not taking orders. They are working with teams to drive the value. So that allowed us to go from a team that was about taking orders, taking work from the business, and having the team now start to deliver value on their own as an individual entity. Being able to now anticipate market trends, anticipate what our customers wanted, and build things out to try out those hypotheses all the time. And not even go talk to the business anymore because they were the business. They became the business customer and it really shifted the focus away from the technology and over towards how we deliver value to our business. So that's my really quick lightning talk on this. Again, if you guys have any questions about this, I'll be hanging out. And we can talk in depth about anything that you have here. And if we have some time for Q&A, I'll come back up and you guys can answer questions. So I'll hopefully answer questions, you can ask me them. So with that, I'll give this back to Courtney and she can take you through the rest of the journey. I'm gonna fly through a couple of these things. Just wanna touch on a couple of things that Matt said around behaviors and patterns. Our traditional behaviors in our environment were boil the ocean. So every time we would look at the website and we would say, we can't continue to have the five week release cycle, this legacy code base. We would say, well, we gotta rewrite all of it now. And what I like about the story and the path that we took with product page and really with our search program as well was carve it off, do something meaningful, learn from it, and then we can extend it further into the organization instead of trying to do it all at once. And the other thing around the product management relationship is the behavior was all about what's the next feature I'm gonna deliver. I don't care about operational excellence. I don't care about improving the system. I just wanna put the next customer experience out. And what I like about the team that Matt's a part of is that performance is a feature. Operational stability is a feature. So the product manager that's part of this team understands that, gives the team the capacity and the space to make meaningful improvements. And so it really takes that collective mindset in order for this to be successful. So I'm going to jump to, so it's wonderful to end up in the state that we have now with our product page. But we also have the existing capability that we can't ignore. So somebody in the audience that is very, very close to this journey that I'm about to tell. So Chad Curry, can you raise your hand? So Chad is going to, you're gonna do open space, right? Okay, so I'm gonna fly through this. But then Chad's gonna do an open space to go deeper on the second part of the story. This is really about taking this five week release cycle and picking a target condition of reducing that by 20%. So essentially taking a week out of the release cycle. And figuring out how to truly problem solve for that. Because when we started this journey, we had a lot of assumptions around what we needed to be doing differently. And Chad was really leading the team through the exercise of, let's make sure we're solving for the right thing. So we started with taking what we called our hardening portion of the release cycle. And this was two of the five weeks. And essentially the intent of this two week period was to prepare for deployment to production. But what it really turned into was extension of the development and test cycle. It was often, we were doing performance testing in the last few days. It was a gate to actually deployment. It was really painful. We had a bunch of exceptions because people weren't ready. So we would have these processes around approving exceptions. And everything within that two week period was extremely time consuming, mostly manual. And the actual production deployment would take multiple days with 24 hour shifts and hundreds of people. So our goal was, let's take a week out of that. Let's really get the hardening exceptions down to something meaningful. Let's take waste out of the system and I'll give a very personal example. I was required to approve these hardening exceptions, which really was a rubber stamp because I didn't really have details around what we were pushing. But the team would literally, they wouldn't move forward until I would say it was okay. So we just stopped it. It was like, take that out of the system and let's see how much we can actually, or let me say it differently. I think we thought we were doing some version of risk management and really there was no value in my approval being attached to these. And then we wanted to get the production released down to being just a day. So we could do it during the day. We could send people home and reduce the burnout within the team. So Ben talked about this yesterday, the value of A3s. This was really challenging to actually make happen. So back all the way up to, we kicked off a value stream mapping workshop. We pulled anyone into this workshop who had anything to do with this hardening portion of the release cycle. Mostly the people who actually did the work. Because we wanted to make sure that we honored reality. So we pulled everybody together, documented the process. I'm going to reference Chad again because we were going through this and Chad was, he leads this team. So he's up at the board, he's documenting the, he's putting the steps in the process and realize that he's not really the person who's actually doing the job. And he checked himself in the moment and said, I should have the person who actually does this work up here documenting it. So when Polly mentioned yesterday kind of that transition from middle manager to middle leader, I think Chad's a good example of recognizing that there is a lot of work that gets done within the teams. And the meaningful way to actually help them is to let them show the work and then figure out how to make it less painful for them. So I just think it's a, I thank him for that. Because it would have been real easy to just stay up there and kind of continue to document the process. So went through, did a small experiment, removed a bunch of waste, and then kind of, I would say, broke the team up into groups so that they could problem solve and do A3s on their own. And essentially, I mean the punchline is we ended up taking, well we got to our goal, we took the week out, so we increased, we have an additional release year, correct? Five additional releases year, thank you. I can't do math. Can't do math and I can't configure PowerPoint. So, and it ended up translating to two million, over two million dollars in savings of labor that we no longer have to spend on these releases. So it's a huge win and the team is going after another 20% this year. So this is a graph representing kind of what transpired and where we took the waste out of the system. One of the more controversial decisions that we made was performance testing was a gate to deployment and we would have mixed results. We'd get, you know, no go from our performance lab and then we'd find out that it was really environmental. Like there wasn't anything in the code, it was the environment and then we'd go anyways. Sometimes we'd have mixed results and we would go anyways. Sometimes we would have great results and we'd go and we'd find something in production. So it's like what problem are we solving by making this a gate? So actually kind of pushed perf testing to the left and said non-functional requirement, it should be part of our test cases that we're that we're leveraging. They should be automated, they should be running all the time and we're not going to have this big ceremony before we go live. So that was one of the big changes. So outcomes kind of touched on some of these and Matt touched on these too. It takes behavior change. It takes recognizing that the new shiny capability is absolutely critical to the success, but you can't ignore that you still have this existing, I mean 50% of our website is still running through this cycle and we still need to make improvements against it. It requires engaged leaders. Really changes how leaders show up. They need to be actively engaged in the work. They need to know what their teams are doing, not in a micromanage sort of way, but in a way where they can really remove roadblocks when the team needs help. It increases trust across all functional lines. The business trusts more, team trusts more, morale went up. It's like way more fun to be done at the end of the day instead of having to do multiple shifts. I mean Chad can share horror stories about trying to get people to fill out the coverage plan for the release, the two-day release. The team's really growing. They're learning improvement kata. They're learning these new behaviors and really like how do I do something small and meaningful and really move the needle and understand how to problem solve. So we're gonna, I think, move to questions and I should have done this at the beginning so you knew Matt's Twitter handle, but here it is now. But I'll have Matt come up on stage again and if you guys have questions, we'll take a few questions. Yeah, that's a good question. The question is, did we have to bring in new people or how did we go about taking the existing engineers and mature them kind of in this process? Is that, okay. This is one of the interesting bits of this. We did not build a team with this in mind. We took existing engineering folks on the ground that had been with the company for a long time. And we also sort of were in this interesting situation where we had a sort of hodgepodge of different types of folks. So we have a lot of people that we've got that are FTEs that came from different places in the company. I had engineers, testers, PMs all living in the same place. They didn't all report up to me. I think at one point my team consisted of folks that reported to like four different managers. But they were my team and we treated them as one team. I did basically all of their sort of the HR management types of stuff and treated them all as one team, even though we had maybe not the most efficient sort of reporting structure. They were one cohesive unit. So we had offshore contractors, FTEs, testers from multiple different parts of the organization, which if I were to start off and say, I want to build a team that's going to be highly functioning, maybe that wouldn't be the approach that I would take. But we were super successful with it anyways. So I think that some of the things I mentioned before about how you build the culture and how you wall the team off and how you treat them with complete autonomy to get the work done is really important in leading a team through this. I've worked in a lot of big organizations where the tendency is for the business to treat sort of the engineers as the doers and not the problem solvers, not the solutioners. Often we're come to with a solution in mind and thought of as, okay, here, implement this. You're an implementation team. And so actually one of the harder aspects to this was not just getting the team itself to focus on this idea and really embrace this idea that, no, you actually can do all this stuff. You don't have to ask permission. You can do this. That was hard. But what was also hard was more hard, I would say, is convincing or influencing the teams around us and things like program management and parts of the business that we're not used to that flow and having them think of us as being part of the solution. Engage engineering. I mean, what I always say is engineers are not people that you just bring in to implement a solution to a problem. Most of the people probably in this room and all the engineering folks that I've ever worked with have always been people that love problem solving. We just use software to do it because it's very malleable and it's applicable to so many different things. But bring engineering further up. Bring engineering and throw them at the problem instead of handing them a solution and then give the team autonomy to implement that solution. So this is how we move through. It's really a cultural thing. It's taking people that maybe didn't come into the company thinking they were ever going to work on a team like this. And building that culture and building the trust, building the team's ability to deliver on the things that are the most important thing. Courtney and I will be around afterwards if you want to ask some more questions.