Host Intro (Gene Kim)

Gene Kim: Some of my favorite experience reports over the years are from John Deere. They are, of course, the engineering and smart industrial organization that is nearly 200 years old. The two people coming up are Amy Willard, Director of Global IT Strategy and Transformation, and Matt Ring, Senior Product and Engineering Coach.

I loved their presentations over the last two years because they are so different than the paths taken by most organizations. Last year reflected this idea of lifting the tide so that all one thousand engineers were lifted at one time through a series of waves. This one was about identifying key skills that are needed not just in every functional discipline, but across everyone, across all engineers.

Hello, Amy. Matt, I'm so glad you're here. Could you both introduce yourselves and talk about what you shared two months ago?

Amy Willard

Amy Willard: Yeah, absolutely. I'll get started. Gene, thanks for having us. I am Amy Willard. I'm responsible for our IT strategy and transformation organization, which includes things like agility, product management, practices, quality, and our DX and cloud platform spaces, as well as our HR and corporate functions at John Deere. I have the privilege of leading the organization that gets to drive change, and Matt is part of that group. Matt, I'll have you introduce yourself and share a little bit about what we've been up to.

Matt Ring

Matt Ring: Thanks, Amy. I'm Matt Ring. I'm a senior product and engineering coach within Amy's organization. A lot of my focus more recently, post-transformation waves, has been on the product side, making sure that we are building the right thing early.

Fun fact before we get into this: Amy, your Wi-Fi is going really good. For those that aren't aware, Amy is on the other side of the world right now, at least for me. She's in India, so it's evening time for her. I'm glad she's able to join us.

Amy Willard: I'm glad to be here.

Q&A

Gene Kim: We're so glad to have you. You talked a lot about transformation and helping the teams create value, and you said the three frontiers you wanted to tackle were value maximization, technology stack transformation, and digital mastery. Let's go to the first one. Can you give your favorite examples of how teams have come up with answers about how one maximizes, or at least increases, value, where the answer was surprising or not what you might have expected?

Matt Ring: I can start with this one. We've got a couple examples here. I can share one, and Amy has another one.

In our talk, we talked about value maximization as one of our new strategic areas that we wanted to focus on after the big transformation that we did. When I was up on stage in Vegas, I said we were doing some really great stuff that I couldn't talk about, so I'm glad this was the first question you asked.

In our talk, one of our guiding beliefs was that we wanted to create more transparency into the work being done across our product teams, across our value streams, and across our lines of business. We also wanted to start talking about effort in terms of the anticipated measurable benefits to our business and to our customers, not just that we released the software or released system X.

A bit of what we have been doing over the past year in terms of measuring and communicating value is explored somewhat in our measuring value guidance paper, which we're also talking about tomorrow in our talk. If you're interested in that one, come back for it.

The example I would share is that we had a situation in one of our lines of business where multiple initiatives were going on, and one product team was basically the bottleneck. They needed to deliver a bunch of different functionality across these multiple initiatives. That sounds like a novel thing. I don't think anyone has ever heard of that situation coming up before.

Think of this team as like a platform team. They were building APIs, but there were a number of different initiatives that needed those APIs built out. At its heart, it was really a prioritization problem.

In a project world, we would just say, work harder, work nights, work weekends, cut corners. Don't say cut corners. Or we would compete for these resources, protect our domains or fiefdoms, or try to pull all these different business owners into the room together, each vying for their own project, and try to get them to agree on what should be worked on first and what was most important, which is typically whatever their particular project is.

In our situation, some of the things we had laid out with our agile operating model were tailwinds for us. First, we had a product structure that we had introduced. Now we have a dedicated product organization with product managers and product leaders. They own the full lifecycle of the product. It's not just getting the thing delivered, but owning the whole piece.

We still had business stakeholders and business leaders vying for our time, but now there was this level of hierarchy within our product model. If two product managers had a conflict about what should be worked on first, we had product leadership that could ultimately make that tiebreaker decision: this is first priority, this is next, et cetera. Then they own that decision and the opportunity costs associated with delaying the other work.

The second thing is that we were talking about these competing priorities not just in terms of burn-down or how much work was left, but in terms of the expected customer or business outcomes that we were supposed to get from these things. Is it new revenue? Are we reducing costs? Are we improving productivity or satisfaction or retention? What is the outcome by doing these things?

Because we had those two things in place, it allowed that bottleneck team to have that conversation with their product leadership, come back down into their teams, and say, we're going to delay work on this initiative so that we can deliver on this other thing. They could articulate that both to their teams and across their stakeholders or customers as a decision based on business needs and customer needs, not just because my boss said so or because it was the lowest thing on the burn-down.

Gene Kim: I love that. I love the joint decision making across potentially P&L owners, so that they jointly make and own decisions. Amy, do you have one? There's a certain example you shared with me that I just have as one of those great things I've heard.

Amy Willard: I do have that one ready. One more example I'll share has some value, some speed-to-delivery, and some tech elements to it. This is one Gene and I have talked about a lot.

We have a large SAP footprint at John Deere, and therefore a large amount of security roles in SAP, and a number of products and initiatives. Many of those need to route through those security roles in that SAP security team to get their work done. This was raised as an impediment to our IT director team, the team that I'm part of, as something that was a bottleneck to value. It was a speed-to-value challenge.

We all know that having the appropriate security in SAP is very, very important. We need to make sure we're doing that in a healthy, safe way. But doing it well doesn't actually really add value in and of itself. The value is what happens beyond the security being enabled. Doing that security allocation, assigning those roles, or creating those roles slowly in fact minimizes the value. It slows teams down, and we don't want to minimize the value our teams can provide. It can be a constraint, and it was a constraint for us.

Last year, an impediment was raised that included a net promoter score from the customers of this product team, the security product team. It was not a strong net promoter score; it was a low score. It also contained the lead time to deliver a role change or to add somebody to a role. Spoiler alert: it was a very long lead time. This was raised as an impediment on behalf of all of the product teams that were using that capability, so it was a common challenge.

This SAP security team was doing a really great job processing requests and working in the framework that they had built over decades, but we knew that we had to get better and faster. In the end, that impediment was investigated. We did root cause analysis, and we ended up with a reorganization that shifted that SAP security organization closer to the teams that are doing the product work in a single hop. Over the long term, we are working to simplify the process and the roles, and ultimately to shift those security delivery responsibilities into the full product ownership that actually owns the business functionality that it is meant to enable.

That's still a work in progress for us, but it's a reaction to the fact that minimizing value works against our ability to maximize value, and slowing down value does as well. We have work to do, but the improved delivery of those fundamental roles across a platform like SAP has been a great effort as an organization and a testament to our ability to really go after some of these root causes.

Gene Kim: You talked a little bit about the attention-getting negative net promoter scores. Can you talk a little bit about early results in terms of improvements of lead time and new net promoter scores?

Amy Willard: Absolutely. We have a subset of the organization that really has this natively embedded as part of the product teams working on security: understanding the roles, understanding the simplification, understanding what roles and security elements accomplish the business processes that those products own. Where we have that embedded nature, it's very quick. There are no handoffs, or very few handoffs, and the teams are able to deliver.

Not only are the security folks who are involved in it happier because they're no longer the end of the frustration from the other product teams, but the teams that are working with them see the value and are able to run very quickly. Those trials of doing that embedded nature and really simplifying the roles in those spaces is a lot of lift, but where it's been done, it has led to happier employees, faster delivery, and really a better partnership versus a handoff over organizational boundaries along the way. All signs are pointing to good outcomes there.

Gene Kim: That's awesome. Everyone has heard Amy say, "We're a big fan of shared services, but maybe not here." It was something about the way that led to all these outcomes. It was absolutely fantastic.

Let's go to the second one, which is about tech stack transformation. We're all technical people here. Can you each share one of your favorite examples of improvements that were made somewhere in the John Deere organizations that you particularly appreciated?

Amy Willard: I'll start. Building on what you just said, we like to inspect our shared services and determine if they're speeding us up or slowing us down. We do have a number of platform teams, and we're advocates and fans of platform teams when they speed us up. But over time, sometimes platform teams go a bit too far and slow us down, as in that last example.

The example I'll talk about is a place where we are leveraging the platform teams to go more quickly. What we talked about in our talk was that software engineers, we believe, do their best work when they're focused on solving real business problems, hard problems, not doing repetitive tasks or what they might consider waste or toil in their day. Our tech stack should be a value accelerant, not a value anchor, and it should be something that our software engineers aspire to and love to work in.

From our developer experience product family, one of the things we've worked on over the last year is something we call secure CI. Our platform teams led an effort that went from team-managed CI servers and clients, team-managed agents and runners, to a centralized CI that met security audit needs and FinOps optimization, compliant audit by design. They were ephemeral, so that reduced the cognitive load of the engineers, reduced costs, reduced security and audit issues, and we went from thousands of individual agents that software engineers had to maintain and may or may not do well, down to hundreds and continuing to decrease that.

What enabled that was the focus from the DX platform on solving problems through a customer lens, but looking at it as the inverse of the other example. How do we speed up the engineers? If the platform can't make them faster, we should challenge whether we are really doing platform engineering in the right places. That's one of the types of outcomes we've been working on. Matt, I don't know if you want to add to that or have another one.

Matt Ring: I think maybe I'll expand on that example, tying it back to value maximization. With the DX product family, their focus really was cognitive load reduction. Team Topologies says reducing cognitive load helps improve flow and get more value out the door faster. Our DX platform team is really focused on cognitive load reduction.

One way they measured how they were producing value for the organization was asking how much time teams were taking to manage their own team CI infrastructure. Hypothetically, these aren't real numbers, but if it's one hour per week for every team, that's one hour per week times 52 weeks times 400 product teams. That's almost 21,000 hours a year that teams are spending on that.

Then this DX team could say the average software engineer's hourly salary is X dollars, and quantify that in financial terms at 21,000 hours times X dollars. If we move toward this centralized system, this is X dollars of budget that can be reinvested in other features, products, capabilities, and things like that.

That's how they were able to tie tech stack transformation to value maximization: by investing in this, and by people adopting these solutions, we're able to reinvest and tie back to value maximization.

Amy Willard: Maybe I'll share one more nugget on that topic. One thing we learned on that journey is that it really helped us think about driving adoption, not just deploying features in our platforms. If I can save one hour per team and only 10 teams adopt it, that's not a lot of value. If I can save one hour and 400 teams adopt it, and that happens weekly, that is a lot of value. It changes the way we think about the value that a platform offers, and focuses us on advocacy, marketing, and adoption of these features across our engineering teams versus just throwing new platform features out the door.

Gene Kim: Fabulous. I have to marvel that in your SAP role example versus the central CI example, one you push closer to the edge and one you push closer to the center. Absolutely fascinating, which ones are more amenable to each.

Let's go to the third one, which is one of the things that excited me the most. I was dying for more concrete details. You talked about a digital mastery initiative of no-regret skills. Can you talk about particular skills that you're putting into this category, or are there job paths that have skills you're particularly fond of where you're finding time, either now or in the future, to level this stuff up in certain domains?

Matt Ring: I can start with that one. The intent of the no-regret skills was that we wanted them to be broadly applicable across most of our digital products or most of all of our employees. They were meant to be guidelines or guardrails for employees to understand what skills they should be upskilling on that we felt were necessary for our future organization state, our desired technology stacks, and things like that.

We have this triangle of roles that we have shared in our talks. It's not just software engineering roles. It's product roles, UX, agility roles, and software engineering roles. We wanted to have these no-regret skills across those different roles.

Gene Kim: Is there one that struck you as something you actually want to level yourself up in, for your own aspirations and goals?

Matt Ring: They're aligned to roles. It doesn't mean you necessarily have to stay in that box. For me, of course, I lean into some of the product roles in terms of customer centricity. How are we not just delivering things, but discovering what's the right thing to build? What techniques do we learn to understand what is the right thing to build?

As it relates to software engineering, if we want something more concrete, we didn't want to get too prescriptive, and we didn't want the skills to be too comprehensive. It was a minimal foundational step. We weren't trying to be prescriptive on languages, like you all must know Java or C# or things like that. But we did know that most all of our teams need to understand version control, and we use Git. They need to have some basic understanding in Git as a foundational skill. We wanted them to understand and use Git somewhat consistently, to promote transferable skills. If I'm going from team A to team B, I'm not having to learn something completely new. We wanted common ways to use Git and common branching strategies, but we didn't go to the point of an edict like, thou shalt all do trunk-based development.

Gene Kim: Awesome. Thank you. Someday I'd like to learn how to use rebase. Amy, is there a particular skill that really caught your attention that you jumped on or are committing time for in the future?

Amy Willard: There are a couple. Two hats I wear: one is a product officer hat, and one is an IT director hat with the engineering skills. I'm working my way through the engineering skills that my teams use most as well. Git is one of them that I've been working through, cloud, a number of others. AI to the forefront obviously makes it to the list.

I've also been working on things like prioritization and making sure that I'm measuring the value that my groups do. You saw some examples and we talked about that earlier. I'm working on both sides of that.

In addition, I want to make sure I don't forget how important leadership skills are. We don't necessarily call leadership a no-regret skill because leadership has always been important. But we focus on a few skills across the organization, and some of my favorites are that being a servant leader is important. That means both serving and actively leading, not being passive in the leadership side. That means allowing teams to do things like determine their own how, learning from experimentation, listening more than telling, and supporting teams.

But it also really means leading, and leading with credibility, which gets me back to our no-regret skills. You have to understand your tech, you have to understand your product, you have to understand the value and how we work as an organization, so that when you create that north star, that destination that you want your peers and other leaders and teams to follow you to, it is credible.

We believe that good leaders get things done, but great leaders have a vision and can take people to a destination. All of these skills come together to help us make sure that we really are delivering on our higher purpose, and that our leaders can see a path that people will follow them on, and that they're credible in their own skills to get there. That's what I would tack on there.

Gene Kim: So good. Amy, Matt, thank you so much. Matt, it would be such a great favor to me if you could maybe in Slack, just as Amy did for Jason, describe the things that you think Amy does, that she models, that really make her so effective as a leader, because I know she won't volunteer those.

Amy, Matt, thank you so much. This is our second session, and I'm just loving this additional room to be able to have these discussions. Amy, Matt, thank you.

Amy Willard: Thank you so much.

Matt Ring: Thank you so much for having us back.