Hello. This particular lesson is going to be focused on common patterns in enterprises and building a culture of continuous learning. It's based on my personal journey as I've continued to get more exposure to DevOps and lean methodology throughout my career. So, first, a little bit about me. I've been in the technology industry for over 20 years. I started as an infrastructure engineer at two different startups. I moved to Nordstrom and worked there for about 14 years. I started as a security engineer in infrastructure. Then, I moved into various operations roles including some leadership roles in operations. While there, I started moving into more development roles. Starting with HR finance, like our Oracle HR finance application. Then, moved into engineering roles for our customer facing teams. These teams were called things like our mobile app team, our web team, our in-store technology team, loyalty, personalization and marketing. Additionally, featured some of our core commerce capabilities around content management, digital asset management and search. After 14 years at Nordstrom, I took a role at Starbucks as their VP of retail technology. That was a very exciting role because I was accountable for a global point of sale footprint. I had not had the opportunity to work with a global company before, and that presented some interesting and fun challenges. The scale of operating a POS that requires very quick service, in particular, was an exciting challenge. I also had direct exposure to how we made our mobile order and pay experience come to life in the store. It was integrated into POS and my team had accountability for some technology that we built in the store to provide transparency to the order queue for the store employees. I left Starbucks to take a role at Nike as the VP of digital platform engineering, which is my current role as I'm recording this. This position is much closer to the scope and accountability of what I had when I left Nordstrom, but on a global level. So, I'm accountable for all of the core commerce capabilities, our in-store technology, content management, digital asset management and consumer data. Basically anything we're doing with personalization and membership for our Nike consumers. In all three positions, I was involved in our digital transformation as we started to adopt new practices around DevOps and Lean. I'm extremely passionate about Lean and continuous improvement. I also frequently give talks at conferences about continuous learning and I really strive to be a lifelong learner with a growth mindset. In this video, I'm going to give a quick tour of the highlights of my journey related to the topic of this lesson. Through the first nine years of this journey, I focused on being part of an organization that was primarily optimized for constant efficiency. We had an annual planning process. We funded projects. We mostly bought applications and installed and integrated them with our existing platforms versus building our own technology. Our life-cycle during that time was primarily waterfall. We had many shared services across the organization. I was part of several of those teams across the years because most of our infrastructure teams were shared service teams. Our releases were big batch, often happening about a year to 18 months after we kicked off the project. During that time is when I learned that having a structured method and framework for managing budget, quality, scope and timelines was extremely beneficial in that context. We had a very mature software development lifecycle or SDLC with clearly defined roles and responsibilities. Everyone involved knew what it took to get a project funded and delivered. We had very high success rate steel across all those dimensions. However, I learned that success by those criteria didn't always equal delivering customer value. For example, we were rewriting our customer relationship management software package, and it took over two years to deliver. By the time we delivered it, we had missed an opportunity to have it be a mobile first application. Almost immediately, we had to start adjusting course and figure out how we could make that happen. Also, our production support teams were not set up for success. Our model operated with silos where production and operations would get the handoff from the development teams. They would own support going forward without a very good feedback loop into the development organization. That was primarily because we ended a project, we typically ramp down the entire team and then we'd move on to the next project. We often had a small team dedicated to the ongoing support but again they were not set up to provide any feedback to dev teams that could help make their lives better. Having end-to-end outsourcing though was a great model for this environment. We could scale up and down with a high degree of flexibility. So, having that as an option was a really good tactic. It made it easy to staff a project team and also allowed us to support production at a very low cost. What I learned for the first 10 years is that optimizing for cost in a retail organization is very common. Buying packaged applications and having outsource team support those applications was also very common. I also learned that having functional teams specializing in certain areas made sense. Clear lines of accountability existed, and it was very clear what you were and were not accountable for. Processes were well-defined and followed exactly as intended. There was not a lot of focus on improvement activities or challenging the status quo. So, now, I'm going to bring you into 2011. 2011 was a pivotal year. In 2011, our board made a strategic decision that we were going to have digital become our primary growth engine. Here's what that meant to me, my peers and my teams. We needed to stop optimizing for cost and start optimizing for speed. So, it shifted to being all about speed devalue. But the only adjustment that we made to how we got the work done is that we said, we're going to start doing agile. I put agile in air quotes here because we really didn't follow the agile manifesto to the letter. We didn't engage our teams to understand what might be the best way to deliver. Instead, we as a leadership team went ahead and decided with the new roles and responsibilities we're going to be. But I learned a lot during that year. For starters, I learned that we should not have just prescribed the agile methodology. It's not designed to be a one-size-fits-all approach, but rather it should be team driven. We should have focused more on outcomes, but we were still focusing on our traditional success criteria around scope, schedule and budget. You can't just send everyone to agile training, give them new titles and move on. It simply doesn't work. We had a lot of challenges with helping people transition from traditional roles like business analysts and do a product owner or product manager role. Dealing with those challenging transitions taught me that it's important to understand what is needed and make sure that the right people are in the right roles. The other thing we learned is that critical roles should be filled with employees not contractors. So, we had a lot of contractors in the organization, and this was our opportunity to move away from that model and make sure that we were putting our employees in critical roles. Even then, we still had a lot of silos, and those silos were keeping us from the speed and the adoption that we needed as an organization. So, then came 2012. During the course of that year, we made a decision to take one of our teams in the organization and try a few experiments. We decided to pick our mobile app team because we had outsourced some of the delivery of that app, but we knew we wanted to own it. With the mobile app team, we felt that we could experiment with a minimal amount of disruption, while also learning a lot. We made a lot of changes to how we were getting work done. We moved away from funding projects to funding programs. We decided to build versus buy. We started applying concepts around continuous flow. So, rather than writing requirements and handing them to development, then handing them to QA, then handing them to someone to deploy, we focused on breaking our work down so that we could maximize speed devalue. We transitioned to a single backlog, which may sound minor, but this was our first iteration of taking all work that the mobile team needed to do and having it be in a single backlog. Prior to this, we had an operational production backlog, a feature backlog and a targeted backlog. Instead, it just became one backlog and we started talking about work is work, which I talked about more in another lesson. We also conducted a value stream mapping workshop. So, we could clearly see where the bottlenecks were in our flow of value to our customer. That helped us to remove silos. We were able to identify that by having silos, we were creating bottlenecks to speed. Then we started implementing smaller releases. We rwee moving to where we could release on-demand. We were leveraging data and metrics, while being very transparent with our stakeholder community about what was working and what was not. That year I learned that picking the right leader was critical and that we needed to provide air cover for that leader. So, we pick someone who had a growth mindset. Then when he identified areas that he wanted to improve, as a senior leader, I provided air cover to make sure that he was able to try those things and learn. Operating with transparency and focusing on outcomes, built credibility and trust across our stakeholder community. We were using data to drive decisions and that helped with our speed of decision-making. I learned that it's very important to challenge the status quo and be persistent. You'll have setbacks along the way, but having a way to continue to make progress is very important. We let the value stream map drive the changes, which allowed us to have fact-based conversation about what was working and what was not. We also maintained a strong focus on Lean and being empathetic to employee needs by trying to get a shared understanding of everyone's role in the value stream and figuring out how to help transition to a different model of delivery. I learned so much over that time, but really the focus on how to optimize for speed devalue, was the most important thing I learned. Shifting to that focus versus cost, was an extremely important discovery. Then in 2013 and 2014, I started to get more exposure to the DevOps Community. We did additional value stream mapping pilots within the organization. By then, we were doing a lot more program level funding, which was great. We had also made the decision that we were going to build for any of our customer experience areas. We identified some value stream pilots and we chose them very intentionally. We picked a team that was running an implementation of a package software application that was used in our restaurants, it was the point of sale system. Then we picked a team that was a build team. They were building their own product around order management in our retail stores. That was done intentionally to demonstrate that Lean and value stream mapping can apply to customer off the shelf applications, as well as to product-focused teams. So, we started to have more product teams. We were able to remove some of the silos, but we did have a bit of a setback into still having big batch releases and not leveraging data and metrics as much as we could. During that time, I encountered a lot of skeptics. I kept hearing phrases like, "DevOps is the new agile, Lean does not apply to software delivery." Well, of course, it worked with the customer mobile team, they're a unicorn. So, I spent a lot of time listening and trying to figure out how I might be able to influence the skeptics and that required reaching out for external help, bringing in other peers in our industry, and external thought leaders around how to do this. That helped with acceleration and sustaining the momentum. We also realized that we needed senior leadership engagement and having clear ownership and accountability. It wasn't enough for this to be grassroots at the team level, we really needed those senior leaders involved too. When value stream maps were first introduced into the organization, everyone wanted to be trained, but I was passionate about making sure that we trained only the teams and leaders who had accountability for those value streams first. That way, we could learn and adjust before we scaled it across the entire organization. Also, being able to take a greenfield approach to how the team was organized, really helped us as well for speed devalue. In 2015, it was all about scaling the value stream mapping workshops and also having a focus on cycle time. We chose cycle time very intentionally because it was within our control. It was the time starting from when a piece of work is ready for a developer to pickup to when it was in our customer's hands and could be consumed. That was our definition that we used. We were determined to let our value stream map be the way to capture the current condition of cycle time across our teams. During this phase, I learned that performance, resilience, security and telemetry are features. We'd still been in a mode where even though we had a single backlog for a team, we still were not seeing prioritization happening for things that were not considered revenue driving features. So, having a way to quantify and prioritize these non-functional capabilities as features was extremely important for us. We also realized that all work needed to be visible. We couldn't have work being done in the shadows. In order to truly know our cycle time, we needed to have all work visible across the team. You can't fix what you can't measure. So, unless you know your cycle time, it's hard to improve it. We also set work in process or whip limits so that we could maximize our flow and it varied by team. Some teams would have a whip limit of two, some would have a whip limit of four, but all teams were assigned a whip limit of some sort so that they could maximize flow. We ended up gaining trust and credibility from having a more predictable delivery model, we minimized dependencies because we were able to make those visible and see them. When we could build APIs or other ways to minimize those dependencies, we did that. We also aligned our capacity to our most strategic priorities and co-location was critical. Having our design, product and engineering partners all in one location was extremely important as we started to leverage this model. Then in 2016, I joined Starbucks in a senior leadership role. This was extremely interesting, because at Nordstrom I'd grown up as an individual contributor and then eventually ended up in a senior leadership role. In this case, I came in as a senior leader. When I first got there, I focused on the first 90 days framework. That helped me with pace and focus so that I could listen to learn and see what the team had already been focused on. I was extremely excited to learn that they already had a value stream map and they had already started to adopt Lean within the PLS team. I also learned that having a strategic alignment is extremely important. At Starbucks, we had a structure and a framework for maintaining strategic alignment with our stakeholder community. We also had a lot of tolerance for starting small and prototyping and then scaling. For example, my team worked on a product to help with transparency to the mobile order Q. We started prototyping with one store and hard coded that into the software. When we decided to go from one store to 2,000 stores, we were able to get the support to do the work that was required to build the software at scale before we started rolling it out across the thousands of stores. We also focused a lot on understanding our capacity and knowing where capacity was going across the teams. I believe that the number one constraint in any environment is engineering capacity. So, if you can focus there first by identifying and starting with operational work, do it because that work is non-negotiable. Your team will always need to provide capacity towards operational work. So, starting there allows teams to allocate the appropriate amount of capacity, and also to know they have leadership support to always focus on operational work. Having strong leadership support and accountability for strategic prioritization was critical. The decisions made at the strategic leadership level, helped our teams go faster, because they weren't needing to have prioritization, reconciliation at the team level. We had it at the strategic level first. So, now that I'm with Nike, I again leveraged the first 90 days approach and that has been very helpful. I'm recognizing patterns. I see many similarities and all three organizations I've worked for, around work visibility and prioritization, knowing cycle time and tracking how value flows to the customer. The need for all of these was recognized across all three organizations. Teaching and sharing knowledge remains important. I've consistently tried to share what I know and bring in external experts when needed to help my teams learn. Now, our Lean journey has started at Nike. Although I haven't been with Nike very long at this point, we have already started value stream mapping with six teams, and we've completed those and our teams are actively experimenting against the value stream. I mentioned my passion for Lean and continuous learning. The reason I am passionate about this is that both start with people, and people are the most important component to any organization. It's really about asking important questions like, "How do you maximize customer value? How do you eliminate waste? How do you make sure you are treating people with respect?" It's also about improving over time. There is a step-by-step process called the Improvement Kata. It comes down to knowing what your current condition is, and where you want to go, and then iterating towards that. We've heard the term "fail fast". I prefer to say "learn fast". Sometimes, talking about failing fast creates a bit of a negative tone. So, I talk more about the speed of learning. I think it's very important to create a learning culture. We do that by substituting "fail fast" with "learn fast" and asking questions like, "How can we create a hypothesis and measure against that? How do we get feedback early and often? How do we set up our Plan-Do-Check-Act framework? I am also extremely passionate about outcomes, and having teams focus on outcomes instead of outputs has been one of the strongest ways to adopt some of these practices. Here are a few examples from my journey. At one point with Nordstrom, we had our mobile app team become an app rating team. So, rather than coming in and identifying as the mobile app team, they came in, and identified as the five-star app rating team. Every day, they did work that was going to get them to the five-star app rating in the Apple Store. Another example, rather than looking at POS server availability, we started looking at metrics, like transactions per hour, because that was actually a better indicator of the health of our product. We really were trying to move away from a situation when a customer tells us about an issue with one of our experiences to us figuring it out first. We leveraged mean time to detect, and really getting that systematically. In addition, we moved away from two-week sprints vocabulary to understanding lead and cycle time as the true indicator of success. Some of these outcomes are discussed in the 2017 State of DevOps Reports and have really given me the ability to shift the dialogue to something more meaningful. Also, talking about business outcomes gives teams line of sight to understand why they are working on what they are working on. Here are a few of my leadership principles that sum up what I believe in as a leader. I believe in honoring and extracting reality. This is something that I've focused on over my years. If I'm a senior leader, and I'm not willing to honor reality, then my team is likely not going to give me reality. If I'm not creating an environment where they feel safe giving me that reality, then I'm not going to be able to extract it. I also think it's vital that leaders understand the work. There's a Japanese term used in Lean referred to as Gemba, that means "go and see". Often, I need to tell other senior leaders that it doesn't mean "go and tell". It doesn't mean to micromanage the work. It means, show up in a way where your team knows that you care, and they know they have the support from you to problem-solve. I think it's a leader's role to provide strategic prioritization, focus, and discipline. It's important to empower teams with intent, context, and accountability. It's one thing to say you're empowered, but if you don't have the context, it's hard to be accountable. I believe it's important to lead by example and have my actions match my words. There are also a couple concepts that I believe in when it comes to operational work. The first is that human error is never a root cause. If there is an incident or an issue described as human error, I don't think that is helpful. Calling something human error does not create a safe environment for teams to talk about what actually happened and how they need help. Usually, something in the system broke down. So, if the focus is on, how did the system breakdown, then I think you get to recommendations for improving the system faster. Besides, it's rare that any issue can be traced back to a single root cause. We work in complex systems. So, the thought that you can get to a single root cause really is a fallacy. In fact, there are contributing factors whenever there is an incident, and there will likely be multiple contributing factors. I also think it's important to be a lifelong learner. I'm trying always to learn from others, find ways to continue to learn, and sharing what I learn with others. That's actually the main reason I'm doing this online course in the first place. Wrapping up, I believe that at the core of everything, people are the organization's number one asset, and all people should be respected. While every organization is different, there are common patterns. Lean and continuous learning are critical to success, and leaders need to evolve. I encourage you to check out the resources I've linked to that are found throughout this course. Many of which are resources that I've used throughout my 20 years to keep me learning and understanding what's going on out in the industry. I hope some of my insights in this video and course have been of help to you no matter what point you are at in your professional DevOps journey.
