Lead with Speed

Transcript

Kissler: My name is Courtney Kissler. I'm very excited to be here to talk about a topic that is near and dear to my heart, leading with speed. I'm going to share a little bit about the experiences that I've had at three large organizations, and talk a little bit about my personal journey as I've made the shift to focusing on leading with speed.

I've been in the technology industry a little over 25 years. I started in infrastructure and operations, and worked at a couple startups in the Seattle area, before I moved to Nordstrom. At Nordstrom, I started in security engineering and moved around in infrastructure and operations, wanting to continue to get closer to the customer. I moved into development roles. Eventually my final role there was leading our customer facing technology team, so digital apps, web, in-store technology, personalization, loyalty, essentially anything that touched the customer. Then after 14 years, I decided to take a role at Starbucks, leading retail technology. It was very exciting to get a global opportunity and to work on a basically POS at global scale. Anything that was inside the four walls of a Starbucks store, my team worked on, including integration with the mobile order and pay experience through the Starbucks app.

After that, I decided to move my family from Seattle to Portland, and I took a role at Nike, leading digital platform engineering. That entailed our consumer data platform, our content and digital asset management ecosystem, digital inventory and order management, our retail technology, our sneakers app. A handful of things that were part of our digital ecosystem. Then I moved into a role leading global supply chain and logistics, and also worked on the ERP implementation there. After that, decided to move my family back up to Seattle, and took a role as CTO at Zulily, which is where I'm at now. I started in January of this year. I've been going through the onboarding process, and really enjoying spending time with the team and getting to know the organization better. I'm super passionate about creating a dynamic learning organization and focusing on a generative culture. I believe people are the number one asset in any organization, and so I strive to focus on teams and people, and try to be a lifelong learner.

Key Learning

Every organization is different. Even though I've seen common patterns, or I've heard about common patterns, or anti-patterns from others that I know in the industry, you still need to understand the context in the organization that you're in. I'm a big believer in the first 90 days framework. I use that whenever I take on a new role, to really spend time listening, learning, making sure I understand where the problems are before I introduce change.

I'm going to back up to 2012, this is what I would call my 'aha' moment. We decided as a company at Nordstrom, that we were going to go big with digital. At the time, we had a digital presence, but it was not where we were focused. We made the decision that that was going to be a huge growth channel for us and that we were going to go big, which led to a shift from optimizing for cost to optimizing for speed. I call this my 'aha' moment because my entire career until that point, IT was really treated as a cost center. You're trying to drive as much efficiency out of technology. Most of my peers were in that same situation. It was, how do you drive cost and efficiency?

Why SPEED?

You may ask, why speed? One thing I learned early in my shift to optimizing for speed was there were a lot of myths or misunderstandings. What I love about this table that I have here is that there is a lot of industry data. This is from the book, Accelerate, and from the years of State of DevOps Report, and the research and data that demonstrates, when companies are focused on speed, and they're doing speed right, they are not compromising quality. High performing technology organizations can get both, but in reality, when you're doing speed right, you're not compromising quality. Focusing on lead time, understanding how long it takes to make a change. Really focusing on your deployment frequency. Percent change failure rate, and that's where if you're focused on this balanced scorecard, then you'll be able to see if you are not creating the right capabilities to be able to go fast, and also not compromise quality. I truly believe, and this is informed by my experience, that if you optimize for cost, you will not be able to deliver at the pace that you need. If you optimize for speed, you will still be able to gain efficiencies and cost savings.

Optimized For Cost

Just a little bit of the attributes of the organization when we were optimized for cost, so probably not surprising, annual planning. Most organizations have that. Actually, every organization I've been in does annual planning. We funded projects or programs, lots of buying, not much building. There were a lot of shared services. I think when cost is the focus, often there's a lot of centralization and shared service organizations that help with optimizing for cost. Lots of waterfall delivery methodology and big batch releases. Here's what I learned. Those structured methods were really good at managing budget, scope, and timeline. We also had a very high project success rate based on those criteria. When we really look closely at our delivery, we couldn't ground it in customer value delivered. We had feature teams, production support teams, operations teams. The production support teams weren't really set up for success. They couldn't get feedback back into the dev backlogs. A lot of the work they were doing was just repetitive tasks that could be automated, but they didn't always have the investment to do it. Outsourcing was actually a really good model when we were optimizing for cost, because we could get a lot of savings by taking certain work and leveraging an outsourced partner.

Nordstrom

Nordstrom. In 2014, I gave a talk at the DevOps Enterprise Summit, where I go into a lot more detail on this example. I'm going to share a little bit about what was going on then. Our customer mobile team, we were not moving fast enough. We were releasing twice a year, which just was not frequent enough to keep up with what we needed to deliver for our customer. We had a senior leader move in to lead that team. We hadn't brought that in-house, and we brought it in-house so that we could deliver our digital experience ourselves. That leader spent time being very curious, asking the team a lot of questions about what it took to deliver value to our customer. Essentially, he was documenting the value stream but he didn't call it that. He basically just asked a lot of questions and then turned around and shared with the team and said, did I get this right? It looks like we spend time on this or we had a handoff here. He made sure that he really incorporated the reality into that value stream. He learned that our lead time was 22 to 28 weeks. With all that data and information, he was able to then problem-solve with the team, and over time, about two years later, we were doing on-demand releases. It became a business decision around when we would deliver our features into our mobile experiences.

Some of the things that were done during that time, we broke down silos. We had a lot of handoffs. We had a QA team. We had a production support team. We had a release management team. We said, we want those teams to really be shared ownership of outcomes in order to deliver value to our customer. We brought the teams together and really focused on improving our lead time. We also had this thing we called a hardening sprint, which was essentially a timeframe between when code was supposed to be complete, and before it was delivered to our customers. What it became was extra dev time. What we found was we were actually having a lot of quality issues, because that sprint was not really being used to harden the release. What we found was the hardening sprint was really a risk management theater. It wasn't really achieving the outcome. Instead, we invested in, how do we build quality in early? How do we have ways to automate our testing? How do we understand the health of our features before we deploy them to production? Then we also created a single backlog, so instead of having features in one backlog, support and operations in another backlog, we said, work is work, we should be prioritizing all of this together. Resilience is a feature, so if we're having performance issues in the app, or high crash rates, they really should be prioritized right alongside the next feature.

Starbucks

Then I'll tell a Starbucks story. One of the things that I have on my first 90 days list anytime I take a new role, is to find out if the team has a value stream map. I ask that question, do we have a value stream map? I got back, yes, we do. I thought, that is wonderful. Awesome. What's our lead time? The answer I got was we have a monthly release cycle. I'll talk about why that was just a very interesting discovery to make, and then how we manage through it as a team. I gave a talk at the 2016 DevOps Enterprise Summit about the Starbucks journey. The main takeaway here is that lead time does not equal the release cadence or the release cycle. You would think, if I'm on a monthly release cycle, then maybe my lead time is 30 days. It turned out for us, our lead time was 84 days. That allowed us to then start to problem-solve, and say, how might we reduce that? What we decided to do is we took what we call the run ahead team, and we said, see how you can focus on the things that are contributing to the high lead time and see how fast you can deliver a feature into production. With high quality, and basically looking at it through that lens, they were able to deliver in 11 days.

That team basically broke down their features into smaller increments. They invested in the deployment pipeline, because there were some gaps in automation and ways for us to understand the health of the features. We also implemented a version of the Andon Cord. If you're familiar with the Toyota Production System, the Andon Cord can be pulled by any employee, stop the line if they see a problem. We did the same for our deployments. We'd have a visual indicator. I actually had a screen out when we were in the office where you could see and it would go red, if someone either manually pulled the Andon Cord, or an automated testing cycle pulled the Andon Cord. We would swarm and we would get the problem resolved before we would go forward with the deployment. We also introduced the DORA metrics. We started tracking our deployment frequency, our percent change failure rate, our lead time for changes, and our meantime to restore service.

Nike

At Nike, I give a little bit more information about this in a 2018 talk that I gave at the DevOpsDays Portland. When I joined the organization, most teams were using the Scaled Agile Framework to deliver software. I got asked early on in my onboarding if I would sponsor certification for more individuals to learn SAFe. As a counterproposal, I said, what if we took a handful of teams, and we introduced value stream mapping? We landed on five teams. We did value stream mapping workshops. This is the result of our product detail pages team's problem solving that they did after the value stream map. What they found was they had 33 steps in the process with 49 pain points. They were able to reduce from 33 steps to 22 steps. They took their delay time, which was the amount of time where basically, no processing is happening. Either you're waiting on somebody, or there's some delay in the value stream. They took that from 30 days to 19 days. This data was leveraged in a monthly review with our senior leadership team, and teams were encouraged to continuously improve and have the space to problem-solve against these pain points on a continuous basis.

Zulily: Optimized For Speed

Now I'm at Zulily. We are optimized for speed and learning. We have annual planning. Every organization I've been in has annual planning. We are focused on, how are we going to minimize burden in the teams? Burden exists everywhere. It is like, how do we continuously invest so that it's easier to deliver value? We have a lot of dependencies, even though we are hyper-focused on speed and innovation, for most of our strategic initiatives, it takes multiple teams in order to deliver that value. How do we focus on making that as friction-free as possible? One thing that we have started to leverage is technical program management, as a discipline and capability so that we can have individuals who are constantly looking at, how do we make work easier? What are some of the technical investments that we could make to minimize or eliminate dependencies within the organization.

We also have a self-organized standards working team. Sometimes, standards can be seen as bureaucracy. Our team's elevated that, they think we should have some amount of standards so that teams can actually move faster. We have a team that is focused on, what is the minimal amount of guardrails and standards that will enable speed? We're working through that as an organization. We are also introducing the DORA metrics, so each team is starting to elevate those four metrics that I mentioned earlier.

Outcome Focused Teams

This is where I genuinely think this is a version of a North Star, trying to get to outcome focused teams. One thing that I believe is value stream mapping is such a great technique to get shared understanding and really understand the baseline for lead time. Then focusing on outcomes versus outputs. This example is from Nordstrom, where we focused on our feature count, like how many features are we delivering? Versus an outcome, which was, how do we become a 5-star app? It really shifted our mindset and thought process around what work we took on in order to achieve that outcome. Then to get to on-demand releases, technology cannot be the constraint for delivering value. We really needed to focus on, how do we become an enabler?

I also believe passionately that leaders need to evolve. I talked about creating a dynamic learning organization, generative culture. This table is the Westrum model. I believe passionately in striving for creating an environment that is demonstrating the behaviors that are listed under the generative column. How do you embrace when a team member or a team brings you a problem? How do you ask questions instead of blaming? My first question is never who. If something went wrong, I talk about how. Like, how did the system break down? What does the team need? What support can I provide as a leader to help?

Leadership Evolution

I also believe senior leaders should be accountable for strategic enterprise prioritization. That might sound like it is taking away or not empowering teams. I truly believe that if strategic prioritization is done, then teams are empowered with context and accountability. Then they're not needing to reconcile conflict that should be reconciled at the senior leadership level before it gets to the teams. This takes discipline. It takes a balanced point of view. Not everything that gets prioritized can be a big revenue driver. There's compliance activities. There's regulatory activities. There's test and learn that if driving revenue is the hurdle that needs to be addressed in order to invest in something, a lot of test and learn wouldn't happen. Having the ability to prioritize test and learn is super important.

Then I also believe that there will always be more demand than there is capacity in the organization. You need to understand the capacity and where it's going in order to make an eyes wide open, intentional prioritization decisions. First and foremost, required to operate. What does it take to operate our services? Second is, what is mandatory, compliance, regulatory, contract driven? Third, enterprise wide priorities, and how are you lining up capacity against those? Then last, product specific priorities. In that order, and it should be visible so that you know if you're making tradeoffs, and what the implications are for those tradeoffs.

This is a tool that I've used, it's called an A3-X. It might look really complicated. It takes a little bit to get used to, but once you're used to it, it is a really good way to continuously prioritize and understand the capacity required to achieve the outcomes. This allowed us at Nordstrom to be able to see, where is our capacity going? How might we free up capacity if needed to unblock something that might be higher on the priority list? We use that for a couple different situations in order to make sure that we had our capacity aligned to the most strategic outcomes.

I talked about focusing on outcomes. I'm also a big believer in OKRs. I think the focus should be on creating the right structure and system to manage them, versus trying to acquire a tool to manage them. Shared OKRs are powerful, you can use those to get alignment. OKRs are not the same as KPIs, you need both. I think sometimes that there's this myth that you have to have one or the other, when really you need both. OKRs should be what you're improving. KPIs should be ongoing measurement and metrics that you're using to understand the health of whether it's your product or capabilities. I also believe data without context is meaningless. You need to be able to look at team level data, rather than aggregating or averaging across teams. An example is lead time. Lead time is a team level metric. If I rolled it up and looked at it across teams, it would not add value. It's super important for leaders to not take a data point and jump to a conclusion. It really should be a opportunity to seek out and get curious, and ask questions.

OKRs and Leader Standard Work

Here are some examples. The OKR Confluence page I have used in my past to help explain OKRs and also to manage just being able to see them. Then having the right structure in place to understand the health and then make adjustments if needed to either the work or the OKR. The Jira board. This is something that I believe in as well. Most teams are using Jira to manage their work. I think leaders should use Jira to manage their work, because often we are the bottleneck when teams need help. It can take time for us to make a decision, or we get distracted too because we have a lot of work in flight. This is something I've used with my leadership team so that we can see work and workload balance, and unblock if something is critical and needs to be decided. This allows us to see and also track lead time for decisions.

Self-Serve Dashboards

Here are some self-service dashboards I've also used. The one in the very back is a way to understand capacity across teams and be able to see where you over-allocated or under-allocated, and where might you be able to balance if needed. The middle one is around team composition. I believe that it's important and not a one-size-fits-all. Not all teams will have the exact same team composition, but knowing where you might have gaps. If you have a team that's down to two engineers, it's going to be really hard for them to have an on-call rotation. How might you help with rebalancing or investing in closing any gaps around team composition? Then, Employee Net Promoter Score, I believe in this as well. This is also from the book, Accelerate. Essentially, this is two questions, would you refer a friend or colleague to your team? Would you refer a friend or colleague to the technology organization? Then this gives me a way to learn if I have bright spots, or where I have teams that need help. Then try to understand what's contributing to high or low ENPS.

Sustaining Momentum

This is a visual from John Smart's book, "Sooner Safer Happier." Any of his talks and materials online are worth reading and listening to. At one point in my career, I thought you had to choose agile or lean. This is a visual that I like to use to remind myself that it really should be about the work. The work should be the indicator for which methodology you apply, and making sure leaders are leading by example, not just in the words, but in the actions. I believe leaders should create focus, not chaos. I talked about that prioritization and focus. I think, if leaders are creating that, then there's less chaos in the organization. I also love this final bullet, people, process, tooling in that order. I think it's super important to always be focused on people first.

Resources

These are the resources and inspiration I've used throughout my career and continuously use. I truly believe that the community is here to share and learn from. I try to always be looking for how can I learn and continuously be inspired, and not be insular.

Questions and Answers

Shoup: How do you measure lead time? Let's pop it up a level of like, why is lead time important? Because I don't know that we've super motivated that.

Kissler: When I first started on this journey, I was not prescriptive. For me, it was just more important for teams to start understanding, what is it taking to deliver value to your customer? I've seen it in two different ways. At Starbucks, it was easy for us to understand, request came in from our customer, to we've released it into our customers' hands. The underlying mechanism we use to measure it happened to be Jira. We had a way to understand the state of the stories as they were going through the backlog. We used that data to understand what it was taking. We did that at Nordstrom too, where we could look at variation and a bunch of different things because we had that structure. It also allowed for understanding the data quality of lead time, because if teams weren't moving the features along, you would see that variation and it created an opportunity to just get better discipline in the system. That was the how. I've seen and I think the State of DevOps and Accelerate now say, from on dev backlog to in production as the measure.

Shoup: Because we're talking about lead time, when you say a value stream map, just walk us through, what would that look like? Then I think a bunch of the other techniques that we'll talk about.

Kissler: A value stream map is a technique and a practice where first you bring together anyone who is accountable for delivering that value. Say it's putting a feature into your iPhone app. It's like anyone who contributes to that, and it needs to be people who are close to the work, not leaders, usually. Not as easy to do remotely, but when we were not in that situation you would get everybody in a room, and literally Lo-Fi, up on the wall, Post-it's that say, these are the steps that we take, and it should be reality. Not these are the steps we should be taking, it is what is really happening. Then you document how much process time, so how much actual time does it take. How much wait time, so someone's waiting. Then delay time, and you start to see the total time. It is very fact based. Usually there's not a lot of emotion. Definitely, eyes get opened really wide, because people start to see and some don't even know that they're handing off, and someone then is waiting or vice versa.

The other thing that's powerful with value stream mapping is this concept, it's a lean concept, percent complete and accurate. Which helps you understand, am I sending something to someone, and they have to send it back, because it didn't have the data that was needed to actually complete the next step? I've always used outside help, sometimes that that translates into train the trainer. At Nike, we trained our continuous improvement team, so then they could do value stream mapping for us. That's the concept, you essentially document it. Then you can problem-solve against it, because you see where all the bottlenecks are.

Shoup: Several people asked about the capacity question. There was one about people feeling awkward about redeploying their capacity and how do you deal with that? Then you mentioned and also the question mentioned the understaffing problem.

Kissler: One thing I've learned, and it is not easy, it takes heavy lifting, but once you do it, it becomes very natural and just part of the system. Reality is the work that the teams are doing every single day. Often, that's not well understood, especially at a senior leadership level. When decisions get made, and I've been in this scenario, this is now our new priority, move teams and have them work on this. Often, that is not informed by the implications of that decision. You get teams, they move, they start working on that, and then there's discoveries after the fact. What I leverage is, we have to know the capacity in the organization, and what the teams are currently working on. Not in a micromanage-y way, in a way to help elevate reality for the executives and the management team.

I believe that the number one thing is required to operate, some people call it keep the lights on, you have to have capacity against sustaining critical services. Then, most of us are accountable for compliance, regulatory work that has to be done, but often isn't well understood. Then it should be these cross-company enterprise initiatives and priorities. Then that allows leaders to understand, if we're going to take capacity from this and move it here, we are going to have implications that are these. Are we all good with that? At least it's an informed decision. It's not easy, and it takes discipline. I think once you get there, then teams see that leaders are engaging in the right way. You also see the understaffing problem, because sometimes there's this assumption, and one of my least favorite words is fungible, that like, we'll just move people around and magic will happen. Often, that is not an easy answer. You have to understand the complexity. You have to understand the skill set required. There's a bunch of factors that go into moving capacity around. My approach is just to make that as visible as possible, and as clear to the decision makers, so they understand the tradeoffs.

Shoup: Turns out we're not all like interchangeable cogs.

To lead with speed, how much decision making should be decentralized versus from a top-down?

Kissler: I believe that empowerment without context is chaos. I think senior leaders are accountable for creating context, intent, like this is the strategic outcome that we are going after as a company. Then empower the teams to organize against that outcome and achieve it. Create a mechanism or a system so that leaders don't just say it's a priority, go figure out how to get it done, but they engage on going to support the teams if they hit a roadblock, or they need help. I think the tops-down component is really clarity of strategic direction and outcomes, and true outcomes, not just, you need to finish this project. There should be something meaningful attached to it. Then, creating that structure so that teams can really be empowered. Then, my goal is to strive for decisions should be made as close to the work as possible, but teams should also have an escalation path for decisions that might need senior leadership help. When I've seen it done well, and when I've experienced it, a priority conflict no longer has to happen at the team level. The senior leaders are like, no, this is clarity of priority. Now the negotiation is happening less at the team level and more at the higher level.

See more presentations with transcripts