The Next Chapter of Dev Productivity: Aligning Experience with Excellence

Hi, everyone. Thanks for joining this talk on the next chapter of Dev Productivity, aligning experience with excellence. My name is Jeff Schnitter. I'm a Solution Architect at Cortex, and frankly, I'm not sure if I'm qualified to give the talk about Dev Productivity and aligning experience with excellence across the entire industry. I work with an amazing marketing team that studies this, and they take a look at the landscape and the competition.

So, intent of my talk isn't really to talk about all that. It's really to give you my personal experience that I've seen both as a customer of Dev Productivity, Dev Engineering Excellence, and then to show you the flip side, which is my opportunity to work with other customers working in this space.

So, I'd like to start off with a small story about the parable of the 25% bike wheel. I wish there was a parable, actually. I had a dream last night before I was going to give this talk, and I was going to ride my bike in the city. I took the bike into the city. I was in the car, and I pulled the bike out of the trunk, and I noticed that 75% of the front wheel was gone, and it had been eaten by rodents, and I figured this must be some kind of a sign for this talk.

Now, you can see in the picture that I had ChatGPT create for me that I have no idea what was going on here, and I was trying to think, is there a parable here? I would like to point out that in my dream, I kind of looked at that wheel, and the first thought I had was, would it be possible for me to ride this bike even though I've only got 25% of the wheel? And ChatGPT is really nice. After I asked it to show a 25% wheel, it puts 23% up on this target. It made me wonder, is there a story here? And I'm probably grasping at straws, but I think that to tie this into dev productivity and engineering excellence, there's a part of me that thinks we're only like 25% of the way there. Software is a journey, and this space, the ability to have the need for an internal developer portal for this kind of a product, exists because of the evolution of software, and there's a part of me that thinks that this is a sign, number one, of me grasping at straws for a metaphor, but number two, thinking that maybe there is a story here, and I think part of the story is that eng excellence is difficult, and I think that I've had days where at the end of the day, I feel like I've been riding a bike that's only got a quarter of a wheel, and it's a little bit painful on the backside, but the thing is that we got through it. So I'd love to hear your comments after you hear this talk. Do you think that we're 25% of the way through this journey from dev productivity, engineering excellence, and where would we potentially fill out the rest of the slices here? I can kind of imagine that these wedges might relate to artificial intelligence, how we're going to do automated ownership, how we're going to figure out your ecosystem based on the integrations that you're feeding in, but would love to hear your thoughts. Thanks for listening to that crazy story about the parable of the bike wheel.

So, what you're going to see in this talk is you're going to see some great slides put together by the marketing team, and then it'll be very clear the slides that I have put together, but this slide really resonates with me because it's the same journey that I've been on. I think that when I started my career in the last 15 years, I found that I was spending a lot of time on developer experience, even though we didn't call it that at the time. I was a build and release engineer. I was working on tools that developers used, and I found that I was trying to figure out the best way that we could use those tools to make developers more productive, make them happier, get the work done that they wanted to.

I think that it's been a natural evolution to move toward engineering excellence because developer experience is part of the story, but it doesn't encompass everything. I think DevEx is really about the tooling that you're using and reducing the friction for developers to make their lives easier. Engineering excellence takes a look at the full story, and I think what I have found is that there's a great amount of overlap between the two.

The story I'm going to tell is about what I found working at Workday. I was there for 16 years, and I'm going to walk you through that journey about how I kind of went from developer experience to engineering excellence, and then I'm going to extend the story since I've joined Cortex, which builds an internal developer portal, and I had the opportunity to talk to numerous customers about their journey. So, good developer experience make developers happy.

So, good developer experience make developers happy. Great NGX makes the business thrive, and this ties it back to developers being happy. I kind of see these as being one and the same in a way because even though NGX takes a look at the business as a whole, if you have really good NGX, it means you've paved the way for developers to do what they want to do, which is write code, and we'll get into that a little bit more.

So, I'm an engineer at heart. I am not a slide creator, so I really needed help putting this presentation together, and what I wanted to convey is that NGX excellence is really a constant journey. You're never really going to achieve that end goal because this is constant change that's going on, and my experience was that you're always moving to the next great thing. That's the thing about software is that you implement something, and then you find that there's a better, smarter way to do it.

The problem is if you're working at a company that's becoming more and more successful, you're going to start to adopt these things at different times through your organization. You're going to have your early adopters. You're going to have your late adopters, and so how do you manage all of that? How do you figure out all of those things that are going on within your organization and try to figure out the path forward because you're going to have your late adopters who don't have that new technology. Again, you have your early adopters, and then the next thing's going to come, and this is why I think NGX excellence is really difficult because you're trying to provide those tools for developer experience. You're trying to provide the way that make things more efficient, work better, less cost, and so how do you drive all that?

So, ChatGPT to the rescue. And when ChatGPT created this graph for me, I realized that my job really isn't threatened, at least in the near term, from what ChatGPT is able to do. I think this is such a horribly gaudy graph that I wanted to include it. I kind of think that, in a way, I'm like this woman with the dress and the one eye, like, what's going on? It's kind of like my quarter bike wheel. It's just absolutely mayhem out there, and I wanted to keep this slide here because even though it's a nonsense slide, the graph doesn't really make sense. There's a lot of confusion out there with all of the great tools that are coming. The adoption of those tools makes sense. We know that it will get you toward this path of engineering excellence. It's still really difficult to make sense through all of that, just like this horrible graph is.

I wanted to walk through my journey at Workday. As I mentioned, I was there for 16 years, super successful company, really technically advanced. I don't want to walk through all of the items on this slide, but I did want to point out that there was an evolution here. The evolution shows that you're always moving from one thing to the next. At times, you can kind of lose that forest for the trees example and realize that you're working on a single migration or you're working on a single feature. I think it's often helpful to step back and take a look at the sum of the things that you've been working on over the course of several years to truly understand that this is a journey. You're constantly moving from the previous thing to the next thing, and it really is very difficult to keep these things all going together because often there will be multiple streams.

Now, I've picked out a handful of them that I wanted to show here, but the point is that these things are often going in parallel. So, developers are working on multiple things at once. They often don't know all of these technologies.

So, think about a developer whose job is really to understand, let's say, they're going to be writing Java code. They might have to understand the networking, how that all works together, but on top of that, you're going to change the way, number one, how you're going to package it, how you're going to deploy it, the different types of environments where that code is going to be written. This is a lot of cognitive load on top of the developer. So, although you're doing everything for those developers, trying to give them the best tools, the tools that make the most sense, you introduce a lot of complexity.

And one of the things that I learned on this journey as I take a look at the CI CD tools bullet is I felt that the way to the engineering excellence was to have standardization. So, I essentially fought a holy war early on in my career where I wanted to make sure that teams were using the same CI CD tools. I learned the hard way. That's not a fight that you want to get involved in. That what I thought was engineering excellence, which was the same way to do things to have standards, did not resonate with developers. So, although it was painful to try to fight that battle for a while, what I ended up learning is that developers want to use the tools that make them most efficient.

So, developer productivity is about giving developers the tools they want to use and the ability for them to achieve the end result, which is writing good code, writing performing code, writing secure code, code that is not going to break the bank based on the way that it is architected, on the way that it is deployed. And so, that was a key thing for me to learn. It's been a long journey for me, but I think I started to learn the frame set of the developer, which is to reduce the friction for them to be able to do what they want to do, which is to write more feature code. Everything else kind of gets in the way of that.

So, even though in this journey that I found at Workday where you change CI CD tools, you broke out a monolith into hundreds of microservices, you changed the way you package. Anybody who's had a long career might be familiar with seeing the way that code is packaged from a simple tar file to Red Hat package manager, doc ranges, Helm charts, Kubernetes deploys. All of these things are meant to make it easier for you to create good applications, but they do put cognitive load on the developer. So, the challenge really is how do we take developer productivity and make sure that it feeds into engineering excellence. So, I wanted to show what my journey was like, and I asked ChatGPT one more time, show how I've been learning this path I mentioned. Trying to push and core standards on developers wasn't the right thing to do. So, this was my prompt to try to show you what my journey has been like. Again, I'm not worried about AI taking over the world anytime soon. I am glad that I didn't have to create this graph. I'm a big 49ers fan. I kind of lost faith and I just didn't come back to my learning journey after the 49ers lost the Super Bowl years ago. We all took a dip during the pandemic. But in all seriousness, what I'm trying to show with this graph is that it truly is a journey. I'm trying to understand that path to engineering excellence. You have to try things. You're going to try things that work.

You're going to try others that don't. But you will learn about the mindset of the developer and the mindset of really the organization and try to make the two things come together. So, I want to talk a little bit about what I have learned about engineering excellence, now that I have joined Cortex, where I get the opportunity not just to see the way that one company is tackling the problem, but the way that numerous companies take a look at it.

And what I've learned is that customers are on different paths. So, they're going to comment at different entry points of that DevEx to engineering excellence journey. And some of them are going to be like me where they might be trying to force standards that may or may not work within their organization. You have to understand different cultures will adopt to the Dev productivity to excellence journey differently. And so, that's been really helpful for me to understand culture plays a part in this. And the willingness to be risk averse or willing to take risk as you move forward is a key differentiator on how you might want to approach the problem.

And then I think that I'm definitely seeing where AI can fit in, despite the questionable graphs and pictures of bicycles that AI has built for me in this presentation. I think that there's going to be a huge opportunity for AI to fit in. You have a vast array of an engineering ecosystem where you've got different tools. You're pulling in data from multiple sources, multiple teams, maybe you've had multiple acquisitions in different ways of pulling data in. AI is going to be able to help. I've seen this at my company where we're working on automated onboarding and trying to keep teams up to date automatically. You can take a look at the signals that exist in the various tools and integrations that you have and pull that in. And I think that there's a big opportunity there. It's part of the journey. Maybe it's part of that 25% bicycle wheel where we're part of the way there, but not all the way there yet.

And I've definitely seen that with internal developer portals, it's more than just the catalog and the owners. You have to have that as your foundation. But where do you go from there? Where do you go from making sure that you know what your on-call tools are, what your CICD tools are, what your code coverage tools are? You have to go beyond that and you want to see a much bigger picture. Do you have the metrics? Everybody loves DORA. Do you have the metrics to show how well the good developer experience tools you have that have set that good foundation, paved the way for engineering excellence, the thing that the organization wants to make sure that you've got all of those things, security, performance, cost, built in the way that you do your business. So this is part of that bigger journey that I've seen the way that different companies are taking a look at that problem and how they're moving forward with that path from DevEx to engineering excellence.

And I think what I ended up honing in on to finish this journey story and the journey metaphor is I think DevEx and engineering excellence are essentially the same thing. That as I've worked not only with supporting a group of developers when I was working in DevEx at Workday, when I was working on that path to engineering excellence with those users who were building a very robust application, and since I've come to Cortex and being able to see the same thing with customers, DevEx and engineering excellence to me mean the same thing. How do you free up developers to make sure that they have time to do what they want to do, to do what they do best? And that's right, feature code. Feature code gets your product to the market, it can become the differentiator for your competition. And I think that it's perceived that everything else that you might do, whether it's re-architecting due to cost overruns, or if you have to take a look at a security vulnerability in a library and then you have to potentially move to a new library, these are all things that halt the developer and halt the organization from doing what they need to do, which is to get their ideas out to production.

And so that's why I think it's the same thing. Now we might label them differently, DevEx is the tools and the reducing the friction for the developer, engineering excellence is really looking at it in its entirety, how the organization thinks about success, how they think about all of those factors, but ultimately it's really one and the same. It is reducing the friction in the most economical way, the most performant way, and the most secure way that you can to get your ideas and your product out to production.

Finally, I'd like to end to let you know that we'd love to continue this conversation with you about engineering excellence. Cortex is hosting a series of engineering excellence activities in the following cities. We'd love to see you join us to add to the conversation. I'd love to hear your thoughts on completing that 25% bike wheel. What does that wedge mean? What are the next steps that you see in the journey from DevEx to engineering excellence to complete the story? And by complete the story, I say just getting us to the next step because the journey really never ends. There will be the next best thing, there will be the next innovation. So we have to make sure that we have processes, we have to make sure that we have the right tooling in place that can help us adopt to that change, be prepared for that change, and be ready to be on that journey, ideally with the bike that's completely built.

So I look forward to continuing the conversation with you. Thank you very much for your time today.