“We try to create empowered teams that can solve problems and create great outcomes together that work towards our strategy.”

Those were the kind of the seeds that ultimately became this product organization, this desire to meet the demands of our customers, to meet the demands or the trends that were being pushed by retail and be able to reinvent ourselves again. And that’s hard. There’s a great book called The Innovators Dilemma. When you think about trying to disrupt yourself, that is challenging, especially when you’re on top. We are a market leader in used cars, but we only have about 4 to 5% market share. This is a hugely fragmented industry, but we have been the leader for years and continued to be. It’s hard to take what’s a winning model, be able to look at yourself in the future and say that model might not work again. So that was really the impetus for our product organization that I’m a part of now.

This was before my time, but our leaders brought in Marty Kagan of the Silicon Valley product group, and he served as a consultant to help us figure out what this digital product model was for us. Marty Kagan really compliments us well because he is deep on these values and philosophy around product, and really believes in having these empowered teams, having inspired associates. These are mission-based, we’re bringing problems, not solutions. And they operate in dual track agile, meaning that they are in each sprint, both discovering and delivering in the same, in the same sprint. Marty’s philosophy and model created the seeds for our early teams focused on lead generation.

Each of these teams are made up of a product manager, a delivery manager, a product designer, a lead developer, usually about three to five developers and then a quality engineer. These are big teams. You’ve got 10 associates across multiple different disciplines and functions and different ways of thinking about problems. And that can be tricky, and we try to create these empowered teams that can solve problems together and create great outcomes that work towards our strategy.

It sounds like you’ve gone from 50 teams now to 70 teams, that’s quite a large digital product organization. Is that because digital is an increasingly large part of the business itself?

Absolutely. As I mentioned, our early teams were largely upper-funnel teams, meaning they were focused on lead generations. Their focus was on how we drive traffic to CarMax stores and bring people into them. As we got further into our journey, it was clear that it was successful, we were driving traffic, but two areas of our business needed to be digitized. In doing that quickly and modernizing our underlying technology stacks we needed to scale dramatically, and that’s what led us to these 70 plus teams — that’s more than 500 associates, in total. Our technology org is well over a thousand. But those aligned within the product space are closer to that size. Our ambition really has grown to transformational efforts.

When I talk about the bridge between our corporate strategy and our product teams, really our product teams were the manifestation of our corporate strategy. So much was about transformation and bringing digital and digital-first thinking to each of our core areas of our business. And that was challenging. We divided into three core product groups as we grew. We have one group focused on our retail business. We have one focused on our supply, meaning both our wholesale auction, so we sell to other dealers, and the way we acquire cars from our customers. So, we divided into those core experience product groups, and then we have a Capabilities and Modernization Group that’s feeding a lot of the underlying platforms that enable those experiences of the other two groups.

“Our product teams were the manifestation of our corporate strategy. So much was about transformation and bringing digital and digital-first thinking to each of our core business areas.”

We also created these strategic programs. You’ll hear me talk about how we started to cascade and how we figured out what OKRs look like across each different level. We created these 15 strategic programs that support our overall corporate strategy but localize the strategies enough to manage the daily and support the teams building against those strategies. Each of those strategic programs have roughly three to five teams — but we are highly matrix and highly cross-functional. Each of those teams represents about five or six different areas or functions. We’ve got technology, design, delivery, and product management, but we’ve realized more recently how important our analyst partner is. Especially when we think about OKRs and our business partner, operational partner who is generally our gateway of change to our field associates.

And with so much of our work having both implications on our customers and associates, it’s been just increasingly important that we’re lockstep with our business partners and that we can advocate for change, or cascade change as effectively as we can to the field. That’s how our overall product organization is organized. As you can imagine, trying to keep that many teams and our product orgs fairly small compared to a lot of your other clients, but for us that was huge. Trying to figure out how to make sure that the teams are driving against our OKRs was an important thing when I joined this organization.

One other thing to note is that part of Marty’s philosophy was really that the OKRs are team OKRs. It’s not that we have a design OKR, and a tech OKR, and a business OKR, it’s the team’s OKR as a group. And that’s been powerful for us to make sure our teams are working together and against the same goals. What that means though, is it’s tricky and challenging to gain alignment cross-functionally at every level and make sure the cascade and the communication is as strong as it can be. That the teams ultimately understand what they’re working on, why they’re working on it, what the problem really is, and then give them the leash and the rope to go figure out what the best solution is against it. So, it’s been quite a journey to figure out how we scale Marty Kagan’s model and how we create and continue to enable empowered teams, but still in a way that supports our transformational journey overall.

“I was initially looking for a way to hit our OKRs and it ballooned into this bigger effort around how do we manage our teams, operationalize our strategies, set ourselves up for success.”

How did things work and function before you started working with Marty and how hard was it to bridge from the before to the after?

It’s been a journey. When I started two years ago, OKRs were just a thing that product managers set. Leaders would set these OKRs and would come back to the team and unveil them. We found that there wasn’t a lot of buy-in to what those OKRs were, and we were setting them and then totally forgetting them. It was just a thing that happened at the end of each quarter in advance of the next quarter, and it was pushed to the wayside.

We also introduced these programs which added a new layer and a new set of leaders. We had a lot of folks that knew how to set their own OKRs or had their own philosophies of what good looked like, but it differed by leader. We had a whole smattering of different skill levels on what great OKRs look like. In that case you might have one leader who was looking at it from an output standpoint, meaning we’re going to deliver on X by the end of this quarter, and then you’d have some more aligned to what our ultimate philosophy ended up being, which was we’re going to have a stretch goal of hitting X traffic target or X customer engagement score or NPS score. That was probably more like what we wanted.

In addition to that, we just had mass communication and collaboration challenges. There’s still a challenge today that we continue to work through, but the alignment piece was something that I wanted to tackle as part of that collaboration and communication challenge. I figured if we’re not all aligned from the start, then the communication and collaboration challenges just expand and get worse as you move forward with the work. It was also just hard to know what was going on. I remember having a conversation with our product leader early on and he’d say, I just want to hit our OKRs — and it was like, well what are the OKRs that we’re hitting?

I also found that we pull up the OKRs that were written and immediately the conversation would go to what the work was, what the deliverables were, how we were doing on that. And again, the OKRs just fell by the wayside. There was a real tension around what was important, what was our management system of these teams. The questions that our leaders were asking were different than the kind of philosophy we had instilled from Marty Kagan. It kind of came to a head when I joined product because we had set an output goal as a corporate goal. That kind of rubbed people the wrong way because they felt like that was so counter to the culture that they had experienced throughout growth, which was, it’s not outputs, it’s outcomes.

At the end of the day, we had a handful of engineers responsible for this corporate goal that was a bonus metric for us. From all those experiences that first year, it was very clear that we needed to take a step back, really understand what good could look like, what questions leaders really were asking and probing on, and then what teams need to be successful. And the communication gaps, collaboration challenges, dependencies we had on other teams as a result, and the lack of clear escalation points and alignment points were frustrating for teams and individuals on these teams. That’s what led us to explore WorkBoard. I was initially looking for a way to hit our OKRs and it ballooned into this bigger effort around how do we manage our teams, operationalize our strategies, set ourselves up for success?

“We need to think about establishing our plans for the quarter ahead to be successful. You can’t do that without the OKR conversation first.”

Take us back to that time. What were your assumptions going into the beginning of your WorkBoard journey?

When I first came across WorkBoard, I thought — we’re good at OKRs, we know how to write good OKRs. We know who manages them. We have this calendar and schedule. We don’t need any services agreement. We don’t need to sign up for any support. We will just pay for our licenses, and all manage from there. Well, that could not have been further from the truth. Within three or four months, it was clear we needed to unwind the way we had deployed things, understand and meet people where they were, and really hear what the pain points were.

We swirled for probably about nine months. Your team was just phenomenal in helping in any way you could, despite us not having a services agreement. We had a great session with WorkBoard and took a step back and were able to do a big reset. What we realized in a kind of meeting of the minds was we do need an aligned OKR philosophy for CarMax and for our product org, and be able to look at Marty Kagan’s philosophy, look at WorkBoard’s philosophies, and just make sure it all makes sense together. And it did. But it was important to put pen to paper on those things. We also realized we needed to make milestones a thing, which sounds like a funny thing, but roadmaps were a four-letter word for CarMax product.

I think there were a few different examples in the past that had led to that sentiment around milestones and roadmaps. We had a hard time having a conversation around our OKRs without talking about the work we wanted to do and how we were going to achieve those OKRs. What I wanted to do was just formalize that thinking and the discipline around planning out the quarter.

I remember a great presentation with Jeff Gothelf — he talked about milestones and setting roadmaps. The next quarter and sprint should be clear, but the quarter after that becomes a little murkier. It was that thinking that helped me bring it to life.

We need to think about establishing our plans for the quarter ahead to be successful. You can’t do that without the OKR conversation first. And I think that’s where the roadmap situation gets tricky — is when you aren’t talking about the why first and then talking about how you plan to go after it.

“I talked through a mission statement, a vision statement, OKRs, milestones, then where do we house it, and then who’s responsible for it?”

I love the maturity of your thinking. You have a clear view of the management model and philosophy. Paint the picture for us of what that management model and philosophy are and how you think about the management system overall.

Absolutely. In my role I have a lot of people coming to me, and I was realizing that just when I thought I had a handle on how something was going, there was another question or a different piece of information that someone was looking for. So, I thought — what is all this information we use to manage these teams and manage the work? I started writing an Excel file for myself, trying to build on it. Essentially what gives us confidence as we get deeper into the granularity of the work and ultimately the team. So, at the highest level, why does your team exist?

Well, we call out a mission statement and what is the future state of your scope? We call out a vision statement and then what strategies are guiding you? What problems are you solving? Well, that’s your opportunity backlog and what’s your design target? And that’s your design, that’s your design target. I just kept going down, what outcomes are you driving? Well, those would be your Objectives. What values do you expect to drive? Those would be your Key Results. How do you think you can deliver on that value? Those would be your milestones.

I’ve just kept going down that path and the most granular I’ve gotten at this point, and I think this is largely inclusive of how we manage at this point. Is the work known? Is it broken out? Is the work carted out? And then is the team healthy? Is it high performing? You can think about continuous improvement, velocity, etcetera. And then the technology itself, is it performant? Is it discoverable? Is it documented? There’s a whole slew of other metrics we can manage from a tech perspective, but this was cool because then I started to think about — what’s the term we use to manage that? I talked through a mission statement, a vision statement, OKRs, milestones, then where do we house it, and then who’s responsible for it? And you can start to see holistically, well one, we were managing these things in a whole slew of different spots, and as we’ve started to mature, we’ve been able to put more and more into WorkBoard so that it is one place.

You also start to see the cross-functional nature of our work. Some of the friction points we’ve had, are product managers responsible or delivery managers responsible, or are the tech managers responsible? And you start to get clear on the health of these teams are a cross-functional responsibility, you can break it down to a point that at least functionally where you’re responsible, and how that fits in the broader picture of the health of that area.

WorkBoard’s been great to go through and say, “Today we don’t use WorkBoard for this, today we use Excel for this. But could we use WorkBoard in the future? Or it doesn’t make sense to use WorkBoard for this. We always use Azure DevOps to manage X, Y, Z, but are there integration points?” I’ve started to share it more broadly just to gut check ourselves on when we say our team’s healthier, are we saying we’re being successful? Are we looking at the full picture? It’s been a helpful tool from that angle.

It sounds so simple to go from vision, mission, down to the OKRs all the way to team. But actually, thinking through those logical layers and the order of things, which questions they answer for whom, who’s responsible for them. It’s super obvious when you say it’s not well articulated very often, but cathartic and clarifying when you do spell it out.

It’s the same level of clarity in general that we’re asking our teams — how confident do you feel that you’re working on the right stuff? It ultimately comes back to Marty Kagan’s philosophy, having empowered and inspired teams. It does start with the strategies, with the vision, and those OKRs — and the rest just enables teams to feel empowered, and like they have a reason that they exist. We are on this journey that has not ended, but continues to evolve, and we’re figuring out what works best for us, using all the tools on this platform and many members of your team.

“We are on this journey that has not ended, but continues to evolve, and we’re figuring out what works best for us, using all the tools on this platform and many members of your team.”

Many organizations, particularly ones that have experience doing OKRs, overlook the process of agreeing on the intended outcome and the changes in customer behavior they expect to see. Milestones are the leading indicators, and the impact on the customer is the lagging indicator. Great teams keep an eye on both.

Exactly. And I think we had this cover of this dual track agile methodology in teams thinking, well, I’ll just discover my way into it. And what happened would be — sprints, sprints, and quarters and quarters. We’d get to the end of the year and look back and think — what happened? How did this take longer than we thought it would? Someone had thrown out a date along the way and now that date was missed and missed — we probably knew more than we thought we did at the beginning. We just didn’t have the discipline to write it down, get some reactions. Don’t create these in a vacuum, we also don’t need hold ourselves to them perfectly. Things will change. We discover, we evolve, we figure stuff out. But what is that path ahead and how do we get confidence from the people around us that we’re moving in the right direction and that we can hit our OKRs at 70%? That was a big piece.

Another implication of that was dependency management. We’ve made this huge shift to add transformational change in addition to our lead gen products. Transformational change requires breaking down old tech systems to rebuild them and building customer experiences. By nature, you’re going to have tons of dependencies between teams. What we found was we had some discipline around dependency conversations before the quarter started, but that we only linked those to the OKRs.

We only knew — I’m trying to drive these OKRs, and I have this dependency, but that team didn’t understand or know why that was a big dependency or when in the quarter that might need to be done. Or, what’s the interplay between that person’s or team’s dependency and another team’s? We’re getting ready for the quarter by not just talking about OKRs, not just talking about dependencies in a vacuum, but also talking about the milestones and the work that we’re trying to achieve. Having artifacts in WorkBoard has helped us reduce dependencies and create greater visibility into where we have some hotspots and address those in advance of the quarter.

We know that before we go into the quarter so our product leaders can say, nope — not this, not that. This is our focus for this quarter. We will lift our heads back up in the next planning cycle and reevaluate what else is a priority for this team. It allows us to be protective of our teams because sometimes they don’t know what’s going to be the highest priority. This has allowed us to anticipate some of those conversations.

“I think we’ve had a lot of wins from establishing a role that is fully dedicated to managing this process.”

On day one of the quarter, you know the outcomes you’re driving, — so the OKRs are done, the milestones are defined. Those are in a Workstream in WorkBoard associated with the OKRs and you have the dependencies identified with owners and resolution dates.

That’s right. And we make those action items too, so that there’s something followed up on as needed or hotbox items for conversations that we have in our business reviews. It’s been powerful to have that trail via WorkBoard on what’s happening with that milestone. Right now, those are all in one place, so everything sticks together as opposed to depending on where you look, you’re going to see something different.

How was that organized before?

It ran the gamut. We had a lot in Miro. It’s a tool that we’ve used as an organization and it’s an amazing digital space for our creative folks to work or for us to map things out. But it wasn’t a great tool for us to manage day to day, week to week, sprint to sprint. We’ve ended up still using that as a spot where we create, but then we translate. We had typical Excel files, and we had nothing in some instances. We had our teams do use Azure DevOps and lean kit depending on what technology stack they’re on.

Some of that was being managed there, but that was often way more granular and something that was hard to manage as a leader because it was a format that was intended for developers to help them prioritize their work day-to-day. We had the luxury of figuring that out as we’ve gotten further along in our transformation. And as you know, this economic environment has tightened. We’ve just had to be a little tighter in our planning, in our day one readiness.

What did you have to do to create that day-one readiness? What are some of the ways you created that preparation and you set the ground for that construct?

This has been quite a journey with WorkBoard’s support. We began our most recent effort about 10 months ago. Our reset started in earnest around July of last year and it’s been super iterative. We’ve used each quarter as an opportunity to reflect on what worked well, just like our teams would. We’ve reflected on how we operated, what we can change or evolve, and how we can be planful about introducing change in later quarters. The first quarter we introduced it, we ripped the band aid off. With WorkBoard support, we defined an OKR philosophy with our leaders and socialized it to make sure our trained OKR coaches understood what that was.

We re-energized our Workboard Pro community so that they were well equipped to be able to support this, too. We went through a massive change effort to communicate and cascade our plan for the quarter. We published a calendar that was explicit around what group was doing at what time, so everyone could have visibility.

We got tight on what the ceremony is, who’s in it, who’s leading it, and the outcome we expect, and we’ve evolved that each quarter. First, we started with group leadership, we did a tie off there, we cascaded and had leaders join each program individually to set context. What we learned from that was these program leaders would really appreciate understanding what their peers are working on and other programs we’re working on. We combined that context setting into one session which gave the opportunity to hear more broadly what’s happening. When there are dependency conversations, there’s context there.

“Because we can be nimble and pivot quarter to quarter, we can start making those strategies take shape and infuse them into our OKRs.”

Basically, we are trying to work towards unzipping and then zipping it back up. The unzipping was cascading context and OKRs down, and then the zip back up was rolling up those milestones and dependencies, tying them off at each level, and ending the quarter with what you’re going after, why you’re going after it, and how you plan to get there. There’s a lot of welcome of change, but change is hard.

I think where we’ve had a lot of wins. We did establish a role that is fully dedicated to managing this process. This has allowed us to have a single point of contact that people can go to with feedback. That can orchestrate change quarter by quarter as we receive that feedback, and we change the way we’re working. Now there’s an accountability partner for our leaders to help them and kind of manage them through this process. It’s a lot of work at the end of the day, and I totally miscalculated at the beginning of this journey that this was something that someone could do side of desk, or a few people could do side of desk. It really needed to have someone dedicated to it. We also expanded that core team.

We added three product directors that are three of our leaders across the organization. That helped because still at the end of the day, our product managers need to be the ones that feel a level of responsibility for those OKRs. We needed to be sure that their management, so the product directors and product VPs, were bought in and could advocate for them. We brought those directors into the fold, and they’ve helped shape some of our processes and philosophies. We designated one person across each group to tactically look across the product group and make sure that we’re being consistent in how we’re adopting some of these planning processes.

In some instances, the individual groups or teams have adapted the overarching plan for the quarter. We’ve tried to create some checkpoints along the way in the quarter and say, you can facilitate the conversation in a way that works better for you, but coming out of it, we need to have OKRs. We want to have a tie off by this point. That’s given some freedom too, for groups and teams to figure out what works best for them.

“There’s so much brain power spent on the strategy, and yet so much of the measure of success is so dependent on executing.”

You initially thought, “I can do this on the side.” But you ended up getting a dedicated manager. I’m guessing that’s when things started to go a little bit smoother. Many orgs take months to work on the strategy and then hire a consulting firm to help them think more about the strategy. It’s a real irony, right?

It’s a total irony. And to some extent, I think this is what led me to this path in the delivery organization. The corporate strategy team kind of operated as delivery for the senior team or for our bigger organization. We had that luxury of six months where we weren’t really building the strategy to go operationalize it, but we weren’t close enough to the work to be able to inform some of the more tactical decisions and deeper conversations that needed to happen. You can’t when you’re operating at that level. At the end of the day, you’re drawing on the same set of resources who are building strategies, deploying, and executing.

What it’s allowed us to do is front run a corporate strategy. For example, right now we’re thinking about an area of our business that we’ve started to work in, but we see some big opportunity. Historically, we probably would’ve waited until we had presented it to the board, and everything’s been blessed. Because we can be nimble and pivot quarter to quarter, we can start making those strategies take shape and infuse them into our OKRs. Some of our teams don’t yet have the context of what the overarching vision would be, but they have enough to get them going as that bigger vision is taking shape so that we don’t lose ground. It allows us to pivot. Now I wish I could take credit for that. I will say the product org has always been great about being able to run on a quarterly cycle. As we’ve gotten bigger, it got harder. You get bogged down localizing those strategies and enabling teams to know that they’re working on the “right” things that can support that broader strategy.

Scale is the enemy of speed, right? And if you can totally scale and keep your speed, you have a competitive advantage.

You’re right. I’ll be the first to admit as someone who loves strategy, who loves seeing a framework on a slide, and seeing how the pieces might fit together, it was a little hard for me to go from that into day-to-day execution of the work. And I think it’s because of my former life that I kept thinking there’s got to be a bigger organizing principle around this. Work is happening, but I don’t necessarily know that it’s in service of the things that we think they’re in service of. Or maybe they are, but I’m having a hard time seeing it. And I thought, if I’m having a hard time, someone in a completely different part of our business would have a hard time.

Candidly there were some reputations of work ideas getting funneled into a black box and you have no idea whether it gets worked on or not. There’s a big part of this around building confidence in our org and creating clarity and transparency into what we’re working on and what we’re not working on. You’re so right though. There’s so much brain power spent on the strategy, and yet so much of the measure of success is so dependent on executing.

“Scorecards have enabled us to create a more robust narrative around OKRs and then embed that into Biz Reviews.”

Let’s talk about how you’re using WorkBoard and what impact or results are you seeing?

We have tapped into a lot of different functionalities within WorkBoard, and your team has been phenomenal in helping us think through different situations that we’re working through and how we can adapt the tools that are available for our needs. Obviously, we have our OKRs available there. The Comments functionality has been great. Now, we are diligently working on increasing adoption of that functionality, as we can see that trail has become easier to understand where we are on that body of work and avoiding random team messages — that’s been really a great function. The biggest thing for us that’s been leveraged are Biz Reviews. I think it’s because we can shape and mold them for what we need, and we can pull in the information in the kind of widgets within WorkBoard for what the audience is.

We also introduced this idea of a Monthly Program Review and a Monthly Group Review. We wanted to have the conversation holistically around where we are on our OKRs and our milestones. These Biz Reviews have been great because you bring those from two different functions within WorkBoard together and be able to have those conversations in one place. During our Monthly Program Reviews, we look at our OKRs and our milestones with highlight spotlights and lowlights, which are essentially the hotbox. And, then showcase other metrics as part of that conversation that we’ve pulled in.

One thing I’ve been excited about recently is the Scorecard. And that has won fans across our org as being super helpful. We wanted to have the conversation around OKRs, but it wasn’t quite enough to just see the OKRs in the red, amber, green, and the most recent comment. We wanted to understand what’s your confidence and what’s your next step? The Scorecards have enabled us to just create a more robust narrative around those OKRs and then embed that into these Biz Reviews. We’ve used Action Items for a lot, particularly for tie offs. When we have tie offs, we try to focus the conversation more on the spots that are misaligned or need further conversations.

We’ve documented those as action items and then those we’ve followed up on a few times before the quarter starts. And then our Workstreams, I’ve talked a lot about milestones and just getting the work broken down for the quarter ahead and we’re finally getting to a point where I feel like we can manage those through Workstreams. One of the cool things for us is each different program can manage their own milestones within their own Workstreams, but we can mirror those then into the group level. Me and my peers can keep a pulse on what’s happening across the programs, those that are most important and might be a click above what the program itself might manage.

  Download the PDF of this conversation.