Host Intro (Gene Kim)

So some of my favorite talks over the last several years have been the ones from John Deere — an engineering and smart industrial organization that is nearly 200 years old and has over 10,000 technologists. A constant in those presentations has been Amy Willard, Director of Global IT Strategy and Transformation, who is another leader I've learned so much from. In fact, that checkbox project I presented on in my opening remarks — that was inspired by a working group that she was part of. And I'm so delighted that she too is now part of the ETLS programming committee.

So this year she'll be co-presenting with two people in her group, Justin Thomsen's group — product manager for developer experience — and Adam Brunner, principal software engineer and group product manager for developer advocacy.

So, among other things, they'll be sharing their journey to help elevate developer productivity by reducing cognitive load and liberating from arcane things that they don't or shouldn't have to care about. Here's Amy, Justin, and Adam.

Amy Willard

All right. Thank you so much, Gene, for having us back again. We are very excited for our third year here. It is a great new venue, lots of new people to meet. We're excited to tell you a little bit more about our journey, and we're also excited to learn from all of you as well.

Before we get into the details of our story here, I'll tell you just a little bit about John Deere. We are a manufacturing organization at our core that delivers agricultural, construction, forestry, road-building solutions across the world. We have over a hundred locations globally. We have over 82,000 employees. And we're 187 years old. So we're a pretty old company, but we actually have technology in our DNA. So since day one with a plow, we've had innovation and new tech coming to the market with us — not only in our solutions that we deliver to our customers, but also in how we run our business.

And in that "how we run our business" portion of the journey, I want to talk to you a little bit about our technology demographics. So we have about 500 digital product teams inside our Global IT hierarchy. That's where Justin and Adam and I work today. But if you zoom out across our broader definition of technologists, we actually have over 11,000 people in our enterprise GitHub environment. And so that's other types of technologists that aren't necessarily just leaning into digital products. We have about 3,500 digital software engineers inside of our organization.

To go back in time for just a minute, I want to orient you to our strategy up to this point. So starting in 2019, we kicked off an agile operating model journey. We've talked about that here before. That was really a three-year journey to completely transform the way we work. So we took all 500 teams, we restructured, we changed everything that we worked on, and it took us really three years to get through that entire journey as an organization. And that really laid the foundation for us in how we wanted to work differently.

We told the story last year. We got to the end of that three-year journey. And because continuous improvement is in our DNA, we said, okay: we got twice as fast, we delivered twice as much, we're more technical, our employees seem happier — but we're only comparing ourselves to the past. So we're twice as good as we used to be. When we looked at "are we as good as we want to be?" — the answer was no. "Are we as good as we need to be?" The answer was no. And so we started this new part of our journey that we really refer to as Digital Leaps.

And at its core, if I oversimplify that, what it really means is that we as a technology function wake up and worry about: how do we maximize the value for our company through a transformative tech stack and through digital mastery — which is our version of the skills that we need today, but also into the future? And so this is our current strategy. We're still building on that in 2024, making sure that we not only remove waste from the environment, but also focus on: are we measuring and delivering the most value that we can for John Deere as quickly as we can?

I have the privilege to really lead a centralized organization that really focuses on how do we drive that strategy forward. So how do we provide the advocacy, the platforms, the learning experiences for the organization to be able to operate at its best? And you can see the structure of the organization there. It's a global footprint for us, because our teams are global. There's a new addition since I was last here that focuses on AI and citizen development adoption. That's something that we are now expanding beyond just the impact in the technology organization, to also understand how can we raise the water across the entire knowledge worker base that we have at John Deere. How can they get the same technology value out of some of these stacks as well?

The most important part — probably on the slide, or maybe my favorite part of this slide — is actually the asterisk at the bottom. So it's a subtle note here. We're lucky as a company — privileged, actually — to have a centralized organization that gets to focus on this and drive this forward. But we actually have a significant number of folks embedded across the organization, closer to their product areas, closer to their customers, closer to the problems they're trying to solve — whether they be delivery leads, scrum masters, coaches, engineering leaders, folks that sit across the organization actually driving change locally. We have this really strong partnership with architecture, security, risk. You'll hear more about that too.

So if there's one takeaway, central organizations are great, but we would not be anywhere near as successful without this embedded, federated support that we have across our entire organization. So making sure we continue to have that, and try to continue to make sure that everybody sees themselves in this strategy versus just a central organization, is really core to how we believe we should operate from a transformation perspective.

So with that, I'm going to get out of the way. I'm going to let Adam and Justin talk about their space, where they really focus on the developer experience lens of the strategy and how we bring value even into that equation.

Justin Thomsen

So I'm Justin Thomsen. I'm the group product manager for the developer experience at John Deere.

Where we started — we had gone through a number of the waves that you've heard about in the last few times that Amy's presented here. We realized that we needed to do something to really accelerate how quickly software engineers can get up to speed and deliver software.

So we took a number of developer tools teams — teams that were focused around CI, APIs, version control — and a couple of cloud platform teams. The cloud platform teams were already sort of well on their way. They'd been around for seven or eight years at that point, and had already had great success with an enforcement approach that still allowed flexibility. So with a few key things that they did — requiring infrastructure as code for all of your cloud resources, automating governance for policies and roles to help with securing your cloud resources, and no human-to-machine deployment (so you can't just log into your server and upload things). So this enforcement-with-flexibility approach that we took — we wanted to expand it beyond just the cloud platforms that were already successful. We wanted to take and look at a holistic developer platform.

So coming to this conference for the last 10 years, you can see all of the things — it's a continuous, large, growing list that we expect all software engineers to be experts at. We realize that's impossible.

So the goal of developer platforms — Mike mentioned this, he didn't see my slides before, so we get to reinforce each other — but we want to reduce cognitive load. We want to help reduce that complexity of delivering software. We want to make sure that we're focused on value. What of those hundreds of things are the biggest problems that we want to go after? And how do we do that in a way that our engineers naturally want to use it, as opposed to being told "this is the way"?

So thinking about how we're going to maximize that value, how do we pick those things, and how do we measure those things? So a quick shout-out to Christina and Robbie in their "Art of Abstraction" talk a few years ago — helped me understand: how do I measure developer productivity, developer platform value?

So we use value maximization across all of Amy's organization, across all of John Deere and Global IT, to help us understand how do we measure these things. So we knew we had all these problems to solve. We knew what value meant to us in our value maximization strategy: productivity gains, risk reduction, cost reduction. And we decided how we're going to measure it. So cognitive load reduction: how long does it take an engineer to do a thing? And if I do that thing on behalf of the engineer, they save time. Let's multiply that out by how often that happens throughout a year, and that's the value that we're providing — reducing all of those engineering hours.

So how did we choose what example we would start with? So containerization — getting into a loosely coupled architecture — we knew that this is something that we wanted to help encourage. So tons of cognitive load required. How do we go about it? So we felt like this is a thing we're going to go after.

I don't know how many people know this phrase, have seen this movie. This is also a relative fallacy in the software world, but we're going to pretend for a moment that we believed in it: "If you build it, they will come."

So at the edge we have factories, we have factory engineers, they needed servers. In the past, you would give them a VM. In the future, we said, "Hey, we're not going to do that anymore. We're going to give you containers." So we built an enforced approach where we said, "this is how you get a container." It was a Kubernetes solution. It got 43% market share, saved a ton of cognitive load for all those engineers at the edge. And we said, "Oh my gosh, there is so much value we could unlock if we spread this across the rest of the public cloud — container as a service for all." And the angels from above cried out in unison, and we said, "victory!"

…Except when you ask people to do something versus force them, you get a little bit of a different market share.

So what was missing? Why didn't they run in droves to save all of this time for themselves? Did we really create as much value as we could?

We realized that just tracking that potential value wasn't enough. We needed to figure out how do we get realizable value. We had to shift our thinking from "we're a developer platform" — and we had to consider the entire developer experience, which includes the human aspect.

So enter Adam and developer advocacy, and he's going to talk about how we took this approach to improve that.

Adam Brunner

Awesome. Thanks, Justin.

So like any good idea, we realized this problem — we had to come up with a name. So we pitched it to Amy: "UX for DX." That's what we're going to go with. And it was real catchy.

We originally started with customer journey mapping and trying to understand the problem space through user research. But we realized after some time that our real differentiating value was adopting a marketing mindset — really thinking about the change management process that we heard earlier today. We're going to cover that a little bit more.

So let's double-click into that containerization problem Justin was talking about. So we first asked ourselves: do our engineers even understand why we're introducing the Kubernetes platform? What is its purpose? Why are we adding it into the tech stack? How is it different from what we have today?

So we started with the town hall. Let's take our early adopters that have seen increased deployment frequency and improved DORA metrics from migrating from their legacy solutions over to this platform — and let's give them a forum to tell their story. And we can also at the same time highlight the value to the enterprise, to the business, of moving off those legacy platforms. That starts to get that desire wheel turning and really get engineers engaged in, "hmm, maybe there's something to listen in to here."

We don't stop there, right? We continue with a communication plan saying: how do we continue to echo and reverberate that message through the organization? How do we post into Teams channels, go to communities of practice, engage with group engineering leaders' staff meetings, to continue to echo, echo, echo? And you get that energy and that desire in the organization.

We shift to the next question: do our engineers actually have the skills to leverage this platform in Deere? That wasn't always true. We have a lot of engineers that predate container technology popularity. And so we had to curate learning paths that help them get from zero to competent in that space. I'm proud to say that we have about 1,100 software engineers today that are competent in this container platform, and we engaged over 500 new learners in this space.

But we all know that just learning in a frictionless world doesn't necessarily translate to confidence to take a workload to production. So we worked on some workshops where engineers would come in and work with a sample application to practice moving that legacy application into the Kubernetes space. And that gave them that confidence to bring it back to their workload.

From there, we moved to prioritization. And the conversation with the engineering managers was a lot easier this time around. And it went something like this: "Here's the success stories, here's the path to get there." Most of them said, "yep, I'll sign up." And we moved 90 production applications off our legacy platform into our Kubernetes hosting environment.

So our next challenge came on the heels of Log4Shell. You all probably have heard of this, maybe. Like many of you, it inspired us to really look at our security posture and say, how can we continue to improve where we're currently at?

And at the same time, as Amy was mentioning earlier, [we were] trying to step from establishing our agile operating model to moving to inspiring our ongoing digital transformation. How do we get that culture of continuous improvement within our organization?

We're also noticing that we were getting the same audit comments across many product teams, showcasing that divergent developer experience that we had in our community. Sound familiar? It should.

In 2022, Amy and Justin went to the DevOps Enterprise Summit with Matt Ring. And they learned a lot about Investments Unlimited and minimum continuous delivery and governance as a service. And we brought those ideas back to Deere and said, how can this inspire how we approach these problems?

We took minimum continuous delivery and we used it as our umbrella conversation to really encapsulate all things engineering practices, and really this definition of "deployable" — which I'll talk more about in a moment — that not only had us push our security posture, but also really help drive that continuous improvement.

So let's double-click. We started again with the town hall where we painted that vision. We illuminated this road to value where there's no obstacles, there's no potholes, and you have the help that you need to make it through.

Next, and this is probably the most important piece, is we formed a coalition within Deere with our audit, our risk, our security, and our developer experience teams. And together we came up with a unified minimum definition of deployable. So what are the minimum things you need to take a change to production, and how do we ensure the lowest-friction way to get that feedback in your pipeline?

But just writing it down doesn't necessarily translate to getting it applied. So we also said, okay, what are the known paved paths that we have within our organization to meet these controls? These controls aren't new — we're just bringing the story together. So we enumerated all of them, and we also took an attempt at: explain it to the engineers. What's the value you can get as an engineer, and what's the value your product can get, by applying the definition of deployable?

That made it really easy to turn around after we got 47% of our repositories to opt into the definition of deployable through their own agency, to go back to engineering leaders and say, "We're seeing success. Here's the results of that success. Can we enforce this broadly across all of our digital product organizations?" And that alignment was pretty easy to get.

Then we shifted over and went back to Justin's organization who's building these amazing platforms and said, "how do we take these ideas and just make them day-zero things?" How do we — when the first time you build an application, it's all just built in? And Justin seems to have done a great job baking that into the platform, along with our security groups who are doing the same. And we've seen — where we've taken the time to automate these controls in the platform — a 92% coverage rate across the repositories in our digital organization. Pretty remarkable.

Let's take a look at a couple of the words from some of our key stakeholders. So at the top you'll see a quote from Renee de la Garza, and Renee talks about the enhanced code quality and the safety he feels moving changes through his rapid iterations and getting them to production, knowing that he's meeting all the requirements that he needs to meet.

At the bottom, Lynn Vestal, one of our key partners — Director of IT Internal Audit — she talks about the unique partnership that we have between developer experience and IT audit, and the fact that it allowed engineers to take control of their controls — is the way that she phrases it. But it doesn't just benefit engineers. It also benefits our audit team, and it helps them have a broader influence, and put more controls and more checks into our ecosystem, because they can move more quickly through engineering teams with that unified experience.

So you're probably reflecting at this time: what can I take away to my own developer experience platform? And we want to leave you with three things.

So the first is — Justin and Amy talked about — quantify the value of your engineering platform. What is it that you're providing to your organization? Implement data-gathering tools to measure key metrics that articulate the impact and the performance of your platform. But it's not just about going and getting those things out of version control or your CI/CD system or your hosting environment. It's about painting a picture and telling a story and communicating with humans, and helping them see the value and the impact that people are seeing from moving on to your platform and the outcomes that they're eventually seeing at the end of the day.

Number two is treating your employees like customers, right? This is the most important piece that Justin, Amy, and I stress about every day: how do we engage our customers, our internal employees? Developing targeted communication plans to make sure that we can involve the employees early and often, so they feel like they have the agency to choose our platform versus being forced onto our platform.

And the last is: continuously listen for toil in the system and find ways to automate it out of there. That's going to give you these efficiency gains that you can capture and reuse, that leave you happier employees that are motivated to innovate and focus on the differentiating value that excites your customers.

And I'm going to hand it back to Amy. She'll tell you a little bit about where we're headed next, and I'll ask for you.

Amy Willard

All right, thank you Justin, Adam. Awesome job explaining a little bit of how you wake up every day and worry about the DevEx experience.

Just to maybe bring us home in the last minute we have here. So our continued priorities — value maximization is the takeaway you should have, right? So being relentless on making sure that value is in every conversation we have. Why are we transforming or upgrading that tech stack? Why are we learning these skills? What is the outcome we want? It is crucial to the way we approach our strategy moving forward. And it drives all the other decisions we make about where we invest, how we invest, where we advocate, where we update our platforms.

We've added a significant focus on industry-leading speed to value. So our previous transformation journey was: how much better are we than we used to be? This is about: how do we compare ourselves to the best in the industry and try to get there? And so we're actively working through that.

And like many of you — how do we become AI-native in how we work? So that's a new addition this year, for most of us. That's in our products, but also in the way we work as software engineering, as a product organization.

And last but not least, we would love your help. So we're here for the rest of the week, we would love to connect. What we're most interested in is: how are you maximizing value and adoption of your own developer platforms? How are you intersecting this dynamic between skills and engineering practices to deliver outcomes? And then how are you embedding gen AI into your experiences and your platforms today and your ways of working?

So with that, thank you for having us. We look forward to talking to you for the rest of the conference.