Eliminating DevOps Drudgery – Andrew Davis, AutoRABIT

This is Textron tv. Hey guys, thanks for the throw. We're here with Andrew Davis, who's Chief Product Officer for Auto Rabbit, and we're talking about, well, how do they maintain focus these days?

Because it's hard when you're confronted with all these tasks, and I think a lot of us get sidetracked and forget to think about what matters here and maybe prioritize things better. But we'll see where we go. Andrew, welcome to the show.

Thank you so much, Mike. Great to be here. We have this issue in DevOps, but it probably affects everybody everywhere, but it's the same kind of thing.

It's like there's so much toil and so much scut work that maybe we forget to focus on the things that matter, but how do we kind of keep our eye on the ball? Uh, that is an excellent question. It's a, it's a perennial issue, and I think it's, you know, uh, it's one of these mathematically unprovable challenges when you have unpredictable number of incoming requests and so forth, how to prioritize.

So, um, I would say it's a balance of, uh, there, there's two parts of our, of our mind that are always, uh, available to operate. The very focused part of the mind, the sort of very left brained part of the mind that just, uh, zooms in on the task to be done. And then the, the broad awareness, the situational awareness that helps us to align with overall priorities, and we need to be constantly moving between those.

Um, and in the sense of moving between focused tasks and then also stepping back and looking at the big picture. One of the best ways to do that, of course, is syncing with broader teams, teams out, you know, periodically syncing with broader teams within the organization, um, to hear what their concerns are and what they are seeing. And then also just to, uh, as development teams to get out and meet the customers and meet the people that you're actually serving, because that, that's always an important reality check.

And we wind up sometimes measuring the wrong things because we don't engage with the rest of the business enough. So we're highly focused on, uh, in the land of DevOps, shall we say, uh, you know, the speed in which a release is made, but the rest of the business is trying to focus on developer productivity. So do we need to kinda, um, gut check and realign with the rest of the business?

'cause sometimes we're not quite focused on what everybody else is focused on. Yeah. Um, I mean, developer productivity, these, there are these famous metrics in, um, in the DevOps space about speed and quality.

And, and obviously they, they are and will always remain, you know, important characteristics. And they're, they're also, you know, integral to developer productivity, however we think about that. Um, but I think there's, uh, as, uh, I think it was Peter Drucker said, there's nothing more unproductive than working hard on the wrong thing.

And so of course, you need to be constantly checking, you know, are we focused on the wrong metrics? Probably, um, you know, and me metric metrics are always just a proxy to help get us a little bit closer, relatively closer to delivering valuable impact. But finally, that's a qualitative assessment.

Uh, it depends on measures that are not within the control of the development team, uh, directly. So it necessarily requires interfacing with a broader business, seeing what the business priorities are, how the team's being perceived, uh, but even also how the team is, um, uh, feeling, you know, is the, are, are the, is the work feeling sustainable? Are they engaged?

Are they interested? Are they feeling like they're building their skills and so forth? So, um, it's hard to put out specific metrics that we should be focusing on because it's so situational.

And typically whatever metric you focus on, it's always easy to over rotate on that metric. And so you want to balance scorecard, so to speak, of metrics, you know, focusing on both speed and quality or focusing on, you know, the internal engineering metrics versus the revenue focused metrics, or typically there's different metrics will help orient the team in different directions. And do you wanna be looking at a balanced scorecard or metrics that, that apply some pressure on each other in opposite directions, uh, and then reassessing on a regular basis to see, are you getting closer to the qualitative goals?

We've been talking about the divide between business and IT now for, I don't know, four decades or more. Um, are we getting better at this? Because it seems like it does come down and the fact that most it, people don't really understand what it is that they are supposed to be working on and why it matters to the business.

So it's hard to stay motivated And by, you know, by extension, most business people don't quite understand what the IT folks are doing. And, and so I think there's no question, I mean, in detail the details of what they're doing. And so I think there's no question that there is a risk of getting that tunnel vision.

I, I was gonna quip that we've been talking about the business IT divide since it appeared, uh, since the business presumably predated, uh, it, but, um, is it getting better? You know, it, it's a, these things are never ending challenges, right? Because you got all these and you have junior people coming into the field all the time, and it's a lot just to try to get your head wrapped around your job.

And development is by nature, a very concentration intensive task, kind of takes most of your available mental resources to zone zoom in to understand what it is that you're doing. And, um, you know, and so that necessarily, uh, tends to create a kind of tunnel vision. And that's that focused left brain thinking that I was referring to previously.

That we do also need to be balancing that with right brain thinking, looking more broadly at why are we doing this? What's the company, um, what's the company exists to do? And I would say that it's not that developers are intrinsically uninterested.

Um, you know, naturally and understandably developers are people who chose to be interested in software development. They, you know, IT professionals chose to be interested in that. So, you know, they find the problem solving aspect of their work fund.

But, uh, I think there's a role for internally marketing what the company does to employees. And that's something maybe for marketing departments and businesses more broadly to, to get better at telling the story internal to the company about what do we do? Who's our customer?

What do we serve? You know, who are we serving? Who are we trying to help?

Um, and, um, if possible go out and actually meet the customer. I've got a friend who works at, uh, DoorDash, um, as a Salesforce, um, development lead, but all DoorDash employees have to go deliver orders, you know, a couple times a year, including the CEO on a regular basis out delivering DoorDash. So you never know when the DoorDash person shows up.

It could be the CEO of the company, uh, depending on where you live. And so that's the kind of thing where you're, you're getting out of, um, you know, getting out from behind your computer, getting out from, from behind your desk, and, um, and actually going and, and either seeing the customers directly or doing other things there. Uh, we've done a couple of things recently since I joined as the Chief Product Officer here at Auto Rabbit.

Um, uh, on my first week on the job, I was in India with our team there. And, um, I was quite impressed with the staff of the hotel that, uh, we were saying that I was staying at. So I began to engage 'em in conversation about how they think about creating a great, um, customer experience there at the hotel.

And then ended up bringing the whole product team to the hotel for sort of a day offsite in getting briefed by the staff, going touring behind the scenes, how they run the hotel, the operation center, and so forth, so that we could see how businesses in real life function. 'cause I think there's a lot of confusion that, uh, is because everything we do in software is invisible. And so even the messes in our code base are invisible.

Uh, only very trained specialists can tell that there's a steaming big heap of manure in the middle of the code base, so to speak. You know, it's not something that's obvious, um, to most people. So getting to know other industries, um, you know, we're gonna go and tour a car, uh, factory next week here in our office in Prague.

And so getting to see how people do operations in other industries in real life is a good way of helping developers to understand, um, and how, how you, how we can mature our process, which really is what DevOps is about, continuous learning and what is a fully operationalized mature process, uh, look like. The empathy needs to go beyond just the DevOps team. The empathy has to reach out to the customer, right?

Y yes. Yeah, yeah, yeah, yeah. The customer and also, you know, the sales department, the marketing department, the support department, all of your, all of your colleagues throughout the business, there's a real danger.

I think the bigger a bus, the bigger a business go becomes, the more we lose context, the more we lose clarity, um, on what's actually happening in the organization. Uh, if you're in a team, you know, a small startup, five, 10 people, you know, everybody, you know what's going on, you've got the context. The bigger the organization gets, the harder it is to maintain that clarity.

And that's why that storytelling is important and empathy with departments and other colleagues, uh, colleagues in other departments. Yeah. Do we get a little too attached to the scut work and the task at hand and that thing that we keep doing every day, whether it's writing scripts or, um, you know, just shifting a workload from point A to point B, and that becomes, at least in our mind, the job, when the job is really something else entirely different.

Uh, I would say, yeah, that's just another, no, kind of another way of framing the same problem that, that we, we, I think as humans, we naturally lose context. It's, it's like you get sucked into a game, or like, if you're watching a TV program, the world disappears. And that's amazing that our minds can do that, that our minds can sort of zoom in on something and just enter a new world.

And, and that's very important because as I said earlier, it, and especially software development there, there's such concentration intensive tasks. It's really important to get the world to disappear so that you have complete space in your mind to tackle these very, very cognitively demanding, um, tasks. And, you know, if you're a, you know, the reason people become professionals, IT professionals is 'cause they like it.

They like the concentration, they like the sort of piece, they like the problem solving. They like the focus. And so, uh, anytime you get that, it can be a little addictive.

You can get a little attached to it, as you say. Um, and you can lose context. You can stop, um, uh, you know, seeing the big picture of what's, what's really needed in the organization.

And that's why I said, uh, I'll, I'll keep repeating the same thing, that there's this sort of left brain, right brain balance where we need to shift between the very focused left brain kind of approach and the, uh, the situational awareness, the broad contextual part of the mind that is, um, that we get with the right brain. And there's a lot of ways to do that, uh, storytelling, but getting out and engaging with the customers, hearing from other people in the business. But you're right, I think there is a tunnel vision that is detrimental, um, yeah, detrimental, uh, in, in all kinds of ways, including we can just be building the wrong solution.

We, you know, and we need developers to be engaging their creative minds. The better a developer really understands what they're doing, the more creatively, the more creative they can be in solving that problem. Um, Are we on the cusp of some major disruptions of our brains with the rise of artificial intelligence?

It seems like you can't walk down the street these days without somebody leaping out, out to tell you about their great new AI thing, but that does seem like, you know, we're automating large swats of the DevOps processes, or at least they're about to. Yeah. Which I guess is you're prompting me to tell you about my great new AI thing.

Know. Uh, no, you're right. I mean, and the, um, the buzz and the hype, I mean, it's, it's for good reason.

This is quite a disruptive, um, innovation, uh, to use that, that cliche. Um, and I think that there is something really, this is very interesting, a little, little bit unsettling, I think for software developers that we've been, uh, we've been, um, in this very comfortable position where while the world of manufacturing was getting automated away by robots and, um, uh, you know, that was also shifted, shifted outside of the us for example. Um, and we have had it, and tech jobs shifted outside the us but we've not had previously the, the sense that there could be an imminent disruption where robots are taking our jobs in the IT field.

And so I think it does necessarily put pressure for us to, to think about upskilling, uh, learning, you know, how to work with these new and disruptive incoming technologies. Um, but also it puts, it shifts the pressure, it shifts the pressure away from, you know, I know Stack Overflow is experiencing a lot of, uh, you know, risk. They've laid off a significant part of their sales team because a lot of the stuff that people used to go to Stack Overflow for, to copy and paste solutions, now they're getting from copilot or chat GPT or something like that.

So, but that doesn't take away the need for thinking, it just reduces some of the upfront thinking to like, what's the right template for this? You know, now you can get chat GPT to get, you, get, you give you a template that may be a good starting place, but it shifts the pressure, uh, it shifts the pressure towards editing, towards sanity checking towards making sure it actually works. Um, and towards understanding, um, how, what your building will fit into the broader landscape of your broader land IT landscape in your organization.

So the need for high quality thinking hasn't gone away. I would say actually the, the pressure on high quality thinking, the pressure, pressure for high quality thinking has increased. So we need to be, while everybody's talking about artificial intelligence, the most important thing we can do is cultivate and protect our natural intelligence.

So natural intelligence is, um, incredibly varied, right? It's not just analytical intelligence, right? It's aesthetic intelligence, social intelligence, emotional intelligence, kinesthetic intelligence.

There's so much, such a rich variety of intelligence as we have, and we really are under pressure to use them. And I think you're, you're kind of hinting in that direction that software developers should probably, you know, talk to people more and, uh, you know, get outside their cubicle a bit more. Uh, if anybody's still sitting in cubicles, um, uh, we need to use that natural intelligence because it's, it's, it's also easier to get fooled, right?

It's easier to get, um, get results back that maybe have security flaw, security risks, um, in them. You need some way to do like static analysis, uh, code scanning to make sure you've not introduced security risks into your code. You need to be, um, looking more at the big picture.

'cause, because one thing that I would say will be happening is that things will be continuing to accelerate just when you thought things couldn't move any faster, you're probably just gonna be accelerating more. So ultimately, what's your best advice to folks about how to kinda get that focus and not allow the overwhelming, uh, work of the day get in the way of actually thinking about what needs to be done at a higher level? I'm gonna, um, I'm gonna tag team some authorities on the subject that since we're on a DevOps podcast, uh, gene Kim's just, uh, reduced, released a new book wiring the winning organization.

One of the, one of the main themes in that, uh, book is basically three things that organ, that people and organizations need to do to be more effective at scale. Uh, slow ification, simplification and amplification, but slow ification. They had to make up a word to describe this, but it's, it's the idea that it's like thinking fast and slow.

There's certain parts of our mind that are, that are geared towards very fast thinking, very reflexive, and it's very important that we have those, but they can't help us to solve novel problems. So for novel problems and strange situations, we need slow thinking. And that takes literally slowing down the pace of conversation, stepping back.

It's things like, uh, retrospectives in, um, in scrums. It's things like, um, postmortems, if there's an issue, it's conversations, um, and just contemplation, right? Just taking a step back.

And that there is a very, very important place for, for that slowing down the thinking process that also extends to things like being able to run tests in reliable testing environments, these kinds of practice, uh, environments where you're, um, you're, you're honing your skills in a non-production environment. Um, you know, simulating, um, simulating failures, simulating, uh, disaster recovery scenarios and so forth. These are all examples of slow ification where you can slow down, get out of the heat of, of battle, so to speak, in a production environment and begin to, um, yeah, do high quality thinking.

So that, those are some thoughts on this. All right, folks, well, you heard it here. I think what we're calling for is the equivalent of a DevOps retreat where we can go contemplate some of these issues and take a minute and maybe reorientate ourselves because so much of what we do becomes firefighting, that we forget how to focus on the fire prevention in the first place.

Hey, Andrew, thanks for being on the show. Well said, Michael. Thank you very much.

All right, and back to you guys in the studio.