Charles Humble talks to Zulily CTO and SVP of Technology Courtney Kissler about experience in driving technological transformations at Nike, Nordstrom, Starbucks and Zulily. They discuss Courtney’s journey within DevOps and how her experience leading transformations at large enterprises including Nordstrom, Starbucks and Nike led her to Zulily. Topics include the importance of fixed capacity; creating a generative culture where team members feel they can be honest and supported; the 90 day framework; Value stream mapping and how this can help teams increase the flow of value to customers; technical debt and more.
Subscribe: Amazon Music | Apple Podcasts | Google Podcasts | Spotify
About the interviewee
Courtney Kissler joined Zulily in January 2021 as CTO and SVP of Technology. Previously she was Vice President Global Technology at Nike accountable for building a reusable seamless platform to power Nike Direct to Consumer experiences, core commerce services, user services, consumer data engineering and global retail solutions. She also led the Global Supply Chain, Fulfilment and Logistics teams worldwide and was driving transformation across the supply chain ecosystem. Prior to that, Courtney was the VP of Retail Technology at Starbucks where she led global POS and retail store technology experiences. Courtney spent 14 years at Nordstrom, starting in infrastructure and security, moving into delivery leadership roles with her last role being the Vice President of E-Commerce and Store technologies where she drove a technological transformation essential for outpacing the demands of today’s Omnichannel consumers. In all 3 organisations, Courtney drove transformation in ways of working, moving to more outcome-based delivery of technology using modern practices, including DevOps. Courtney brings diverse technology experience from startups, CyberSafe and WorldStream Communications, to beloved global brands.
Resources mentioned
The Phoenix Project
First 90 Days: Critical Success Strategies for New Leaders at All Levels
Westrum’s Organisational Model
Accelerate
The Andon Cord
Nordstrom - Transforming to a Culture of Continuous Improvement
Starbucks Technology Transformation (Requires registration)
Full transcript
Introduction
Charles Humble:
Hello, and welcome to the fourth episode of Hacking the Org, the podcast from the WTF is Cloud Native team here at Container Solutions. I'm Charles Humble, Container Solutions editor in chief. And for this episode, I'm joined by Courtney Kissler.
Charles Humble:
Courtney joined the American E-commerce company, Zulily in January of 2021 as CTO and SVP of technology. But she's also held senior IT roles in Nike, at Nordstrom and at Starbucks. And in all three organisations, she has driven transformations in ways of working, moving to a more outcome based delivery of technology and using modern practices, including DevOps. I'm really excited to have her on the show.
Charles Humble:
Courtney, welcome. Thank you so much for doing this.
Courtney Kissler:
Thank you for having me. I'm very excited to be here.
What drove Nordstrom’s decision to go all in on digital in 2012?
Charles Humble:
It's obviously a bit of a way back now, but I thought it would be interesting to start with your experience at Nordstrom and in particular, the decision that you and they made to go all in on digital, which was around 2012, I believe, which is relatively early. There's a wonderful talk you gave on this at the DevOps Enterprise Summit from 2014, so I'll make sure to link to that in the show notes. But can you tell us a bit about that and particularly how did you arrive at that decision? What drove the decision?
Courtney Kissler:
In 2012, I had been at Nordstrom for almost a decade. And so for the bulk of that time, really technology was all about cost savings, how do we drive the most efficiency out of our technology ecosystem? And then our board actually was recognizing external companies that had ignored digital as a primary channel for growth, and basically came to us and said, "We need to shift, and we need to 30 X our investment in digital."
Courtney Kissler:
And at the time we had a website. We did twice a year releases and basically spent, I'd say 1 to $2 million on our website. So as you can imagine, when you get this support to go big, it created this exciting momentum in the organisation. It also put us in a position to really elevate and amplify the areas where we needed to change.
Courtney Kissler:
So 2012, I was in a role where I was accountable for helping the organisation build out what now we call a product model. Back then it was really how do we be more agile? How do we shift away from waterfall approaches and this project based approach to delivering tech?
Courtney Kissler:
And for me, I spent a lot of time immersing myself into the agile community and we got some things wrong specifically around the agile methodology. A bunch of senior leaders went into a room and said, "We're going to come out with a process, including roles and responsibilities." And then we pushed it into the organisation, which had some amount of results just because everybody said, "Well, the senior leaders are telling us to do this, so we'll do it." But most people didn't really get the why behind it.
Courtney Kissler:
So in 2013, that is when I started to get immersed in the DevOps community. So I read The Phoenix Project, I started spending time with others in the community and really started to understand that we needed to focus more on the flow of value through the organisation and how do we understand that.
Courtney Kissler:
And the trailblazers in the organisation was the infrastructure teams. And that's where I started, by the way, that's my roots, security and infrastructure. And what our infrastructure leaders had recognized was the old way of provisioning hardware, software, databases, storage was not going to meet our digital strategic outcomes. And so they started saying, "How do we make things self-service?"
Courtney Kissler:
And we hadn't started our cloud journey yet, so this was more still about how do we take an existing provisioning process and turn it into something that met the speed and requirements of the development teams? So that kick started our journey, infrastructure is code, all the things that now where companies all talk about this. And then we started taking those same mindset and practices into our development teams.
Courtney Kissler:
And one thing that I believe passionately in is understanding that flow of value. So we introduced value stream maps. We started with a subset of our teams because digital mattered and we hadn't owned our apps, we had outsourced it. Yeah, so we brought it back in. We said, what are we going to do to get to a spot where we're not delivering every six months?
Courtney Kissler:
We needed to get to a place where we could deliver on demand and create a capability where it became a business decision when we would deploy features and functionality. So that's where we started and what led to the ... We called it digital transformation. Everyone calls it that, but it was how do we become more relevant in this channel that is really going to turn into a growth opportunity for us as a company?
With the mobile team you bought it in house and then used value stream mapping as a way of understanding where your bottlenecks were and what your lead time was.
Charles Humble:
So with the mobile team specifically, you were releasing a couple of times a year. You then bought that team which had been outsourced, you bought it in house, and then used value stream mapping I think, as a way of understanding where your bottlenecks were and what your lead time was. Is that right?
Courtney Kissler:
You got it. And this is where the culture component comes in. So we had a leader in the organisation who had already been trying to introduce lean design thinking, changing how we were delivering technology. And so he was put in the role of leading our customer mobile teams and he worked for me, but having the mindset of, we need to challenge status quo and we can't keep doing what we've always been doing.
Courtney Kissler:
And it was really fascinating because initially he didn't even call it value stream mapping. He just engaged with anyone who was contributing to delivering a feature or functionality in the mobile app and said, "What's it like to do your work? How long does it take for you to test these capabilities? When you go to deploy, how long does it take?"
Courtney Kissler:
And then he played it back. He basically drew this picture and showed us all of the wait time and the handoffs and just how painful it was to get anything delivered, which then created this shared understanding and ownership of making it better.
Courtney Kissler:
So teams got excited about that and saw that we can invest in automating our testing capabilities, creating APIs so that we don't have these monolithic dependencies in our code base. How might we do this in a way that really also makes it easier for the teams to get their work done? So we get a great outcome, because we're going to deliver faster. And I know that this has already been said in our industry, but delivering faster doesn't mean you compromise quality. So it was like, how do we get better at what we're delivering and make our teams feel great about the work they're doing?
What were some of the changes you were making in terms of team structure at this point?
Charles Humble:
So thinking specifically here about the Nordstrom mobile team, what were some of the changes you were making maybe in terms of team structure at this point?
Courtney Kissler:
So from a team structure perspective, this probably will not be surprising. We had a lot of silos in the organisation. We had the development teams, we had a testing team, and we had a production support team and they all were different teams within the organisation. So we went on this journey of saying, well, quality should be the developer's accountability. We shouldn't hand this off to a separate organisation to test. Plus we would get delayed feedback loops.
Courtney Kissler:
So we at first brought some of those team members into the team so that we could teach, how do we create a better testing framework and platform. And then over time it became the expectation of the developers and the engineers that they were building quality in. We also said you don't just work on features. So we had backlog separation. So we had the development teams, all they deployed were features, and then we had support teams that took on anything that was considered a production issue.
Charles Humble:
If I'm understanding you, those were managed as separate backlogs?
Courtney Kissler:
Separate backlogs. Yep.
Charles Humble:
So you've effectively got a structural silo there between dev and support
Courtney Kissler:
And almost never was there a feedback loop between the support and the development team.
Charles Humble:
Right. Yes. Yep.
Courtney Kissler:
So we said everything needs to be in a shared backlog. Teams need to be accountable for the production issues as well. Resilience is a feature. I mean, we started just breaking down these old constructs of how we thought about support and operational work and said, if your app isn't performing, if it isn't reliable, if it isn't secure, that is a feature that should be part of the product. And it just changed the dialogue.
Courtney Kissler:
Now, in order to really make that something that we could get all of our stakeholders aligned to, we started leveraging data. So prior to that, all of the, you might call them just traditional monitoring and alerting metrics were an IT problem. So business didn't even want to talk about it.
Courtney Kissler:
Well, what we realised is that we had a lot of stability issues with our apps. So we started elevating crash rate and showing our stakeholder community that it was unacceptable. And then they got more engaged in prioritising work that would reduce our crash rate. So we started being more outcome focused and saying these are things that we don't want to have as part of the product. How might we do work that would improve these metrics?
Courtney Kissler:
And having again, the team that's developing the code also accountable for what happens in production, which is the standard kind of DevOps philosophy. It wasn't like we were doing anything revolutionary, but it was a big change for the organisation. And to really embrace, we're not going to hand this over to another team to take the on call and to take all of the burden from the production incidents.
Did you get rid of the hardening sprint?
Charles Humble:
I believe I'm right in saying you also had what you called a hardening sprint. In the place I used to work, we used to call this a stabilisation sprint or a stabilisation period. They're a very odd thing where notionally you have a code freeze, but actually it isn't really a code freeze because people are still fixing bugs that have been found and all of this sort of thing. I've never really been quite sure what the purpose of this is. Right?
Courtney Kissler:
Yeah.
Charles Humble:
It's a very, very odd thing. But anyway, I believe you had one of those. I'm presuming like all organisations, at some point you went, why do we have this and got rid of it?
Courtney Kissler:
We did. So that was in our website team. And so the delivery process was to allocate a certain amount of time for development, allocate a certain amount of time for testing, allocate this hardening sprint. And then we do these and it was a multi-day release process.
Courtney Kissler:
So once we did our value stream map and we put that all up on a wall and said, wow, not only do we have a lot of, I'll just say waste and opportunity in the process, we're really not even using this hardening sprint for what it really was ever intended to be used for. We were using it to finish development activities and to clean up the test results.
Courtney Kissler:
And so we took a step back and said any opportunity to fix the upstream defects, and I say that meaning don't overcommit. So what we found was we were overcommitting, which then created this pressure on the dev teams to not descope certain capabilities. And so they would say, "Well, we have that hardening sprint, so we'll just let dev and QA take over some of that time allocation." And then our poor deployment teams were feeling the pain because they would get things very last minute, and then the release process would take longer. And sometimes we would have to not deploy the feature anyway, because we were scrambling to deploy it.
Courtney Kissler:
And so the learning was, make sure we're not overcommitting, right size the commitment. And at one point we just said, we're taking that hardening sprint out, so it's not available anymore. And I'm a believer in some amount of forcing function. If you just continue to say, let's try to get better at this and let's see if we can not continue to leverage the hardening sprint for the wrong activities, there might be some incremental process improvement, but if you start to say, it's gone, we're no longer going to have this as part of our value stream, it creates the opportunity to really move the problem to the right spot in the value stream.
What were the similarities and differences between Nordstrom and Starbucks?
Charles Humble:
And then you moved from Nordstrom to Starbucks and you actually gave another brilliant talk at the 2016 DevOps Enterprise Summit, so I will link to that in the show notes as well. But I was interested to get your reflections on the similarities and differences between the two organisations, because from the outside, I would say that Starbucks and Nordstrom are really poles apart in terms of what they're like as companies.
Courtney Kissler:
So it was so interesting to leave an organisation where I had been there for 14 years. I really had learned and had grown through the organisation to the role that I was in, which is a senior leadership role. Then to move to a really large global scale organisation as a senior leader.
Courtney Kissler:
And I hadn't leveraged this in my past, and I was so fortunate because someone talked to me about this when I was leaving Nordstrom, they mentioned the First 90 Days framework. So I read the book, I thought, oh my gosh, where has this been my entire career? And I used it because, what I didn't want to do, because I had seen other senior leaders do this, come into the organisation, they want to add value quickly, and sometimes there's disruption just for disruption's sake. It's not really grounded in the problems the organisation is facing.
Courtney Kissler:
I'm also a believer in, you build up a playbook over time and not all plays apply to every organisation. So you really have to understand the context and take the time to listen. So I went into the organisation and I just started asking tons of questions and I had my questions. And one of my questions was, do we have a value stream map?
Courtney Kissler:
So my role was leading the teams that delivered any features, functionalities to the point of service in the Starbucks stores. We also had a really tight integration to the mobile order experience that has been a big, big ... I don't know, it was such a great capability to be a part of.
Courtney Kissler:
So when I asked the question, my team said, "We do have a value stream map." And I thought, oh my gosh, amazing. And so I immersed myself in it, and then I started asking follow up questions. And one of my follow up questions was what is our total lead time at Starbucks?
Courtney Kissler:
The employees are called partners. So when a partner submits a request to our team, how long before we have it in front of them, they can leverage it? And the team said, "Well, we release monthly." And I said, "That's different. That is not how long it takes."
Courtney Kissler:
And so we did all this problem solving and we realised that it took 84 days from request to in production. What a great discovery, because then we took a step back and said, okay, how might we reduce that? And what can we do in small experiments? I'm also a believer in don't boil the ocean, don't try to do everything.
Courtney Kissler:
So we took one of the teams and said, how might you run something fast through and understand what could be the target state for us? And eventually over time, we got to 11 days. So we had a fast track capability where we could go from requests to it's in production in 11 days.
Courtney Kissler:
And that took breaking down the features, which is probably not surprising, break things down. And it's okay to be deploying something that might not be the full feature set yet, but you can be deploying it, and then at some point you take it live to your customer, because there was all this like, well, that's not value, if we're delivering a feature, but the customer's not consuming it, which is true. But it created the right mindset around breaking things down, leveraging feature flags, doing things that really got us to a spot where we could move at the speed we needed to move at, including, this is my favourite example, a lot of times the focus is on how fast can you get features to your customer?
Courtney Kissler:
There's also something to be said for how fast can you respond to an incident? So if something happens in production and it takes days, weeks for you to get the fix out, that can be almost more disruptive than being able to deploy a feature. So security response, production incident response, all of those things could follow this fast track and we could actually get things out faster. So that was amazing.
Courtney Kissler:
Some of the same tactics applied though, even just within my own team. So within my own team, I had silos. I had my dev team, my QA team, and my production support team. They all reported to me, but they all had different sets of ownership and accountability. And we said, well, wait a minute, what might it look like if we brought a team together with all those capabilities and have them work as a team to deliver?
Courtney Kissler:
And one of the biggest ahas that we had was we created that. We basically took developers, testers, and production support team members put them together. And one of our production support team member said, "Oh, that feature has been one of the biggest challenges for us. We have hundreds of incidents that are related to a defect in that feature." The developers had never heard it before.
Courtney Kissler:
So they mined all that data and they were able to resolve that defect within days, just from being in the same team together. And so there's so many unlocks that can come from just even simple things like that. And then the teams felt supported and energised by it because they saw, oh, I don't have to just keep taking this incident. And often they would just work around the problem versus getting the support from the dev team to fix the actual problem.
Charles Humble:
It's interesting to me that you mentioned this business of conflating release cadence and lead time because it's one of those things I've seen happen actually really quite regularly. And I think it's one of those things where if you're not actually measuring lead time, it's really, really easy to fall into the trap.
Can you talk more about the 90 Day Framework book?
Charles Humble:
You also mentioned the 90 Day framework book there, which is a book that I have to confess I've heard of, but I haven't actually read. Can you maybe give me and our listeners a bit of a summary of that book and why you find it so useful?
Courtney Kissler:
Yeah. So essentially first thing you do is you try to assess the situation that you're in. And there are these categories that the book gives you guidance around. And one is, are you in a turnaround? So are you in a situation where you're turning around, whether it's a team, a business, whatever the context might be.
Courtney Kissler:
Are you sustaining success? Are you coming into an organisation where there's an established, I'll say success pattern and you're going to build upon it and continue that momentum?
Courtney Kissler:
And then there's two other categories, which frankly, in my career I have not used yet. One is the greenfield, you're starting a business from scratch, how might you think about entering into that situation? And then there's another one about creating new business models. So for me, every situation I've been in has either been sustaining success or turnaround.
Courtney Kissler:
And then there are sets of questions that you can ask. So you build your list of roles and people that you want to interview. And so usually what mine looks like is my boss, the top 5 to 10 people that I'm going to be dependent on for my success. So that's usually peers in the organisation, including business partners. Team, so my direct reports and I try to go as deep into my team as I can.
Courtney Kissler:
Sometimes I have to do that in a more scaled way, rather than one on one, listening to learn, I'll hold like round tables and I'll bring together 10 to 20 people, and I'll ask questions to try to surface the reality that they're facing. So it's very open ended. You ask questions like, what's in your way? What makes you feel like you can't be successful? What's good? Because it's good to understand also what contributes to the success that we've seen as an organisation. So then I collect all of that and then I play it back.
Courtney Kissler:
Now, I have other activities that I'll introduce into that First 90 Days framework depending on the situation I'm in. So I mentioned a standard thing that I look for is a value stream map. I also like to do a deep dive because I'm in a technical role, like architecture, design diagrams. How might I learn about the technology ecosystem that I'm accountable for? But all in the spirit of learning because nothing is worse than coming into an organisation and having people feel like their leader is judging the situation.
Courtney Kissler:
I know this is part of the DevOps industry community as well, but I am a big believer in the Westrum model and striving for generative culture. So if, as a leader I show up and I'm not creating an environment where people feel safe telling me things, I will suboptimize in my decision making.
Courtney Kissler:
And so it's super important for me to listen and then play back and often I'll play it back in small groups before I play it back to my entire organisation. And then how are we going to solve some of these things together? So at Starbucks there was a lot of, well, I mentioned the lead time opportunity, so how might we improve our lead time?
Courtney Kissler:
There also was the same situation that we had at Nordstrom where we didn't have a shared backlog. To me, that's something it's like, all right, we can work on this. We also had too much work in progress, which is a common thing, and lots of dependencies amongst teams. So it's like, all right, how might we limit our WIP?
Courtney Kissler:
How do we dedicate capacity against the things that matter? Because we also had teams that were getting contact switched all the time. And so, one tactic I like to use is first of all, work needs to be visible and then taking the capacity in the organisation, which is fixed and allocating it against the things that are the highest priority. And you always have to protect some amount of capacity for maintaining the existing capabilities and services that you have in production. And then you can start to add priorities in from there.
Courtney Kissler:
What I find sometimes is teams are only getting support to do feature delivery, which then turns into a lot of opportunity in improving the tech stack. So I don't like the term tech debt, but some amount of understanding of what investments need to be made in order to make our lives easier for our teams.
Courtney Kissler:
And this is where State of DevOps report DORA metrics, the book Accelerate influenced me as well, because right around that timeframe, when I joined Starbucks was when all of the DORA work and State of DevOps was becoming very, very relevant in our industry.
Courtney Kissler:
And I found that if you can understand, how long does it take teams to detect and restore service, what is their lead time for change, how do you know your change failure rate and deployment frequency, if you can bring those together in a meaningful way, it will highlight where you need to invest. And then it becomes a choice.
How can you get organisations to pay attention to tech debt?
Charles Humble:
Again, this is something I've seen frequently during the course of my career. You say you're not a fan of the term tech debt, and I have to say that I'm not either, but there is a sort of organisational reluctance to invest in things which are not features. And I think a side effect of that is that over time you get this accumulated cruft of out of date frameworks and code that's suffered from bit rot that just naturally happens over time.
Charles Humble:
And it's really difficult to justify investing time and effort to fix that over time. So you tend to end up with these large scale modernization efforts, which I think generally don't work that well. Do you have any suggestions for ways that you might be able to manage that better?
Courtney Kissler:
I believe data is critical, when you're making the data visible in addition to the work visible. So what I've found is most I'll say leaders that are outside of technology, they don't really understand if you show up and talk about the DORA metrics. They don't understand, but if you can connect it to what they care about and frame it in business outcomes.
Courtney Kissler:
So for example, one thing that I find organisations don't always appreciate is when a service and capability is unavailable. That has a direct impact on revenue and your trust of your customer. But it typically just gets framed up as some companies will quantify it, they'll say, oh, the website was down for three days, we probably lost this amount of revenue. But there's never the feedback loop back in to the backlog to say, wow, we should probably understand and learn from this and invest in what's needed.
Courtney Kissler:
And I'm not a believer in to make it never happen again, that's not how complex systems work, but if you do the right learning and you understand the contributing factors and then you leverage that quantified impact, you should be prioritising that work above the next feature. And so trying to create that data driven decision making and also make visible.
Courtney Kissler:
So one thing that I've done at Starbucks and Nike and now at Zulily, is show my peers across the company where the capacity's going. So I've had teams that get zero allocation to do things that really improve the technical capabilities. And if you're categorising that work in a meaningful way, you can bring that data forward and say, you're frustrated because we continue to have stability issues in our mobile app. Well, here's why. Every time we commit to work, we deprioritize the things that are going to make it better for us to avoid incidents in the future.
Courtney Kissler:
And then everybody goes, "Oh, I didn't know that. I didn't realise that our decisions were contributing to the lack of progress in this space." Sometimes my teams will say, "Well, we just need the business to prioritise it. We just need them to care." That's like, you have to bring some data to the table and if you don't bring the data to the table, it makes it really hard to influence the conversation.
Estimating itself also uses capacity
Charles Humble:
There's a related pattern there that I've seen just thinking about capacity, which must be a standard in probably every organisation I've ever worked in where a business person has an idea, they come to IT, they say, I've got this idea. I'm building a business case for it. I need to know from you about how long it's going to take you to build, which is a perfectly reasonable question, except as we all know, estimating is hard and estimating in software is incredibly hard.
Charles Humble:
But also, the business of estimating is itself using capacity, which I think people so often miss. I think it's really easy just to assume that that business of doing the estimate, just magically happens and doesn't require any resources, right?
Courtney Kissler:
Yep. So if I could do this, I would make the decision to never estimate. I think estimates are a waste. Now I realise that most organisations and the reality is people aren't ready to jump to that as the way you operate. So here's some things that I've tried.
Courtney Kissler:
So I truly believe the fastest way to know how long something's going to take is to start working on it. So what I've done is I've broken apart, and I've called it discovery, I think you can call it whatever you want, but it's like, we need to do some amount of discovery and it may even include a prototype to understand what the effort's really going to look like.
Courtney Kissler:
And here's the key, to respond to what you said, that also takes capacity and needs to be prioritised. So there wasn't this assumption that, well, just absorb that into what you're already doing. And so, one thing I did at Starbucks and it was hard, we would have multiple requests to do estimation like, well, I really want you to do this feature, but I need to know how long it's going to take. And we would spin and spin and spin. And we would have anywhere from 1 to 10 of those in flight at any given point in time.
Courtney Kissler:
And then I found that my teams were getting pulled away from other work in order to do these estimation exercises. So I said, we're going to have a WIP limit of one discovery activity at any point in time. We're going to do one. And everybody was like, "Well, you can't just do one." And I said, "But here's my commitment to you. We will turn them around within two days, so you will have an answer faster to inform the decision."
Courtney Kissler:
And so we broke this pattern of having multiple estimation efforts in flight. And we did, we were able to get back to our stakeholders and say, based on our understanding, it's going to take this long. I would say it's a bridge between what I would love to see happening and traditional estimation. It was, do enough due diligence to feel confident, and in some cases there was just prototyping done to say, if we take this into our backlog, we expect it would take this long.
Courtney Kissler:
And so that created a really good trust building mechanism too, because I didn't have all this frustration in the organisation. It's like, oh, we keep asking your team and they never answer us. Or the teams would just say, it's an extra large, because they'd just want to get it out of their backlog. It's like, well, let's make it more meaningful. Let's actually do something that then informs whether or not we're going to work on it.
How do you shift IT from being a cost centre in an organisation?
Charles Humble:
I think there's a related thing in there, which, again, it's a shift in mindset that I've seen over the course of my technology career. When I started, which would've been, let's say the early 1990s, so really quite a long time ago, IT was a cost centre. It was kind of like a service provider to the organisation, but it was very much a cost.
Charles Humble:
And there has been a significant shift, I think in terms of making IT be more part of the value of an organisation. But as always with these things, it's not universal. I know that some of the Container Solutions customers, for example, still struggle with that. How do you have those kind of conversations? How do you affect that change?
Courtney Kissler:
So I'll start with, I had this aha moment where the optimising for cost and efficiency needed to shift dramatically to optimising for speed. And what I've learned, and I can say it with almost a hundred percent confidence, if you shift your mindset to optimising for speed, you can also have cost and efficiency benefits, but if you optimise for cost and efficiency, you're almost never going to meet your speed outcome.
Courtney Kissler:
And so getting organisations to make that shift is hard because you can't shift to speed and ignore your fiscal responsibility to the organisation. They go hand in hand, but it needs to lead. And I've talked about this, lead with speed, if you're leading with that as an outcome. Also with the framing of that doesn't mean you compromise quality, because I always have people say you're going fast, but you're not focusing on quality. And it's like, no, you can't go fast without focusing on quality.
Courtney Kissler:
And then again, it goes back to facts and data. So if I can present a balanced scorecard that shows the speed components of the work that we're doing, which again, I often use the DORA metrics for that, and also the financial components of the work that we're doing.
Courtney Kissler:
So everybody, I think most people have been in a scenario where they've gone on a cloud journey and sometimes there's this, oh my gosh, the cloud's costing us so much. We should probably back off on our usage of the cloud. And it's like, as a technology leader, what I need to demonstrate is we are leveraging it in the right way, we have the fundamentals incorporated into everything we do and then connect it to the speed outcome.
Courtney Kissler:
We can deploy faster because we're on cloud. We can have more stability because we're leveraging cloud. And try to connect the two so that you're not seen as a technology leader who doesn't care about the cost and the business and the P and L impact of the cost, but that's not what you lead with.
How did Nike compare to Nordstrom and Starbucks?
Charles Humble:
So in terms of your career, you've gone from Nordstrom to Starbucks and then from Starbucks you went to Nike. So maybe you could tell us a little bit about your experiences at Nike and how they compared with Nordstrom and Starbucks.
Courtney Kissler:
I joined Nike in the digital part of the technology organisation, and again, took my First 90 Days framework and started immersing myself into the organisation and asking a ton of questions.
Courtney Kissler:
At the time value stream mapping and really knowing the flow of value was not part of the system there. There was a lot of embracing of agile mindset and product model and tons of that momentum, but no one had really done a true value stream map for any of the teams.
Courtney Kissler:
So after my first 90 days, I proposed that we take a handful of teams, so we ended up with three teams, and brought in a coach to help value stream map the work that they were doing. And it was again, this huge eye opener where everybody went, "Oh my gosh, I had no idea that we had that long of a testing cycle. Oh my gosh, I had no idea that when the product management team doesn't help us break the stories down, we have all of this waste because we're doing rework late in the life cycle." So it was like a big education and unlock for the organisation.
Courtney Kissler:
And then similar concepts that I had leveraged in my past, but I wanted to make sure that it was going to be connected to problems that were happening in the organisation. So there was the need for the investment in the underlying deployment pipelines, the embedding quality and test frameworks into the deployment pipeline, breaking the, I built it, but I don't own it, I don't run it, I hand it off to another team and they do that.
Courtney Kissler:
So we started with my teams taking ownership of the production incidents. And it took some change management because when you've been used to not being accountable for those things, it takes a little bit of time for that shift in mindset to happen. But then teams start to see, oh, why get pulled in, anyway? Even if I'm not the primary responder, my capacity is still getting pulled over to resolve these things. So if I'm aware that the work I'm doing is having this downstream impact, I can just build it in to what I'm doing.
Courtney Kissler:
Observability. We did a big initiative around observability and how do we instrument? We also had an initiative and this is one of my favourites because we had that anti pattern happening where we would freeze, we would have freeze windows. So during this part of the year we cannot deploy code. And I was like, well, we should be able to deploy code, but it should be a decision. And so we created this initiative, we called it Ship 365, which was our, how might we ship code 365 days a year and make it a business decision?
Courtney Kissler:
So we'd have the capability as a tech team, but we still might choose not to deploy on Black Friday. But if we have an incident on Black Friday, we'll have the capabilities to respond and deploy quickly. And so that created this really great culture movement in the teams in the organisation because we had this rally cry and north star.
Courtney Kissler:
And then again, back to making it visible, how much of our capacity is going against things that improve that capability versus not, and partnering with product management to show them this is the amount of capacity we have in the team. They're working on these things. How do we feel about that as an organisation?
Courtney Kissler:
So introducing, I call it a system of accountability, but it's a mechanism for coming together, inspecting reality. So we may not like reality, but let's make it visible, so then we can talk about it and we can problem solve against it. A lot of it was hidden. People were frustrated, but there wasn't a real great way to problem solve against it.
What drew you to Zulily?
Charles Humble:
And then in terms of your career, you left Nike to join Zulily, which is an American E-commerce retailer. Can you talk about what drew you to them?
Courtney Kissler:
So I had had a conversation with Zulily when I was leaving Nordstrom and when I made the decision to go to Starbucks, a lot of the reason was to work at a company with global scale. So what I liked when I talked to Zulily then was the culture. Very builder culture, very innovative, growth oriented, focus on speed, lots of things that I value.
Courtney Kissler:
So when I talked to them and made the decision to join, a lot of that was still in the DNA of the organisation. It was, we are about growth and innovation. Yes, we have been a startup for a decade, we're ready to scale. We need a platform focus. We need someone to come in and help us grow to the next level. So that was very compelling to me.
Courtney Kissler:
Now, again, I joined, I followed the same First 90 Days. I listened a lot and what I learned, and this is a new thing I learned. I knew about this in former roles, but I never framed it in this way. So lots of burden in the organisation, lots of wanting to work on things that would make team members' lives easier, but that was never getting prioritised.
Courtney Kissler:
The other thing was, so I'm a big believer in speed, a big contributor to not achieving speed is high degree of dependencies. Now in big organisations that just comes with the territory. You're like, yep, we got a lot of dependencies. But in a small company, I thought, oh, it's probably not going to be what I've seen in my former roles. There was tons of dependencies.
Courtney Kissler:
And so this year as a goal, we've created what we're calling a viscosity score. So we're starting to measure how much dependency exists in the organisation and taking that information and elevating it and saying, okay, in order for this team to get work done, they are dependent on 10 other teams and 10 other services. Let's improve that viscosity score, whether it's through building an API instead of a point to point integration or some amount of investment that reduces the viscosity across the organisation.
Courtney Kissler:
And one discipline that I believe passionately in, and we had this at Nordstrom towards the end of my time there, and we had this at Nike, is the discipline around technical program management. And the T matters, because what I've found is if you get really great, strong technical program managers, they are just hyper focused on elevating dependencies and identifying areas where you can minimize or eliminate dependencies.
Courtney Kissler:
And so that was a discipline that wasn't part of Zulily when I joined, but we've introduced it since I've joined. And those teams are such high value to the other teams because they're there to make their lives easier. And so we've started to incorporate that into our set of metrics because it's helping us elevate where we have this complexity and it shows up as dependencies.
What would you say is your role as a technology leader?
Charles Humble:
If you were going to try and sum it up, what would you say is your role as a technology leader?
Courtney Kissler:
So this is something I'm extremely passionate about. I believe senior leaders need to evolve and frankly I think all leaders need to evolve, but I think it starts with the top. And so I believe my role is to be extremely clear with the intent and the why behind anything that we're doing, create that intent and then empower with context and accountability. So how do I get local decisioning, because teams understand how their work lines up to the intent?
Courtney Kissler:
I need to be close to the work in a way where I can be helpful. So I've talked about Gemba, go to the work, not to micromanage it, but to be informed, thoughtful, and helpful. I want teams to feel like they can elevate reality. And when they elevate it, they're going to get help, not judgement. I spoke about generative culture. I believe passionately in that, and I talk about creating a dynamic learning organisation where we're just continuously learning and taking information in.
Courtney Kissler:
And as a leader, I believe every action I take and every decision that I make is an opportunity to build trust, break trust, or be trust neutral. And so I'm constantly reflecting on everything I do and trying to lead by example and create an environment where people feel like they can contribute to the strategic outcomes, so they can also surface reality, like this is painful, I need help. It's a version of the Andon Cord. And how do team members feel like they can stop the line and say, this should not be deployed. Or if we don't focus on this technical capability, we are not going to be able to scale.
Courtney Kissler:
So I'm constantly trying to create that type of environment and hire leaders who will push on me so that I'm learning all the time. I want constant learning, but I think it starts with senior leaders need to be clearer and provide strategic focus and clarity to the organisation, which takes discipline, because if you're not willing to focus on the things that matter and clear the way for the teams, I don't think you can grow at the pace you need to grow at and deliver what you need to deliver, because there will always be more demand than there is capacity. I've yet to be in a position yet where I've had more capacity than demand.
Courtney Kissler:
And so practising some amount of discipline creates the speed and agility that you need to be successful. And again, I think it starts with leaders. I think they have to be embracing that and they have to demonstrate it through actions.
Charles Humble:
Courtney, thank you so much for taking the time to talk to me today on the Hacking the Org podcast from the WTF is Cloud Native team here at Container Solutions.
Courtney Kissler:
Thanks for having me.
Previous article
