What Makes DevOps so Hard to Comprehend? | DevOps Onramp 2023

Hello, I'm Mike Ard, and welcome to our panel on what makes DevOps so hard to comprehend. Today I am joined by Sharon Zisman, who's founder of R T F M, please. They are a, uh, specialist in all things cloud native.

We also have Mike Gibbs, who's c e o for Go Cloud Careers, and he helps people figure out how to build their architectures and all kinds of good stuff in terms of their careers and their skills and what's required. And finally, we have Mitch Ashley, who's principal for Techstar and Research, and a long time veteran of the DevOps world. And I guess our first question is, and I'm gonna kick this out to Mitch, it seems like to me at least that we have a hard time getting people indoctrinated into the DevOps philosophy and kind of getting them onboarded onto a team.

So you've been looking at this for, you know, well over a decade. Is there, are there trends or things that you've seen that, um, make it easier to onboard new folks? Or what do you think is the challenge?

Well, it depends on where you're starting from, right? If you're starting from like ground zero and not doing any, doing any quote unquote DevOps yet, um, I think if you've got some practices already happening, um, there, there are many different roles, right? That, that are somewhat DevOps roles, not DevOps roles, very centric to DevOps.

And, and for the developer community, for the people managing tools and doing integration that usually it starts around the repository that you're using. If you're, you know, doing, you're, you're doing GitHub or using something like Visual Studio or another set of, of, uh, ides and tools. But today, the repositories also integrate with or provide their own workflows.

So I, I, the thing that I do is kind of start where it all begins, which is around the C I C D process and orient people to how that works. Now, if you're not someone who is gonna be writing code and checking in code, but maybe you're a tester, right? So you'll, you'll want them to know what the process and the flow looks like so that as they're writing test software, they know what happens.

You know, how does it get kicked off? Uh, what are the environments that are spun up to be able to do the testing? Um, if you're a developer, you know, I just need to know what repositories we're working on.

What tools do I need to integrate into my I D E? There are in, in the pository there are requirements files, if you will, MD files that help define what your environment needs to be set up. So there's a lot of tools to help you, but that's the technology set.

I think the more important side is how are we writing, creating, building, and releasing our software, and what does that process look like and help everyone ex uh, understand what that is. If you're more at the beginning stage, I think kind of bringing everybody together through the process is very helpful because we can start to adjust and change our roles. But that's another conversation.

Sherron, you wanna add anything to that? It seems to me that there's no shortage of titles in the DevOps landscape these days, so it's kind of hard to determine who's doing what. Yeah, so, um, I, I lead DevOps days, telaviv, that's one of the things that I do as part of my, uh, kind of community work, um, and DevOps days.

The very first one in Gant was launched in like 2009. So DevOps as a concept is already about nearly 14 years old. And the reason I say that is because a lot of the concepts and culture, um, of, of DevOps are already seeing like kind of a new wave of, kind of, of an evolution.

Uh, and when DevOps first came about, it was more about kind of building that, um, that culture and the processes from dev through operations. And today we're seeing a lot of subsets in, in the world of, uh, of DevOps as well, like subsets of roles and, and domain expertise under the guise of DevOps. So everything from like DevOps to s r e, to platform engineering, to production engineering people that have specific expertise in monitoring and observability.

All of these are, um, specific and different domain expert domains of expertise. Um, and with the growing complexity, sheer size and volume of the cloud fleets and the microservices that we're running on, and the different, you know, stacks that we're using, many, uh, larger engineering organizations today have poly glad environments, multi-cloud environments. It's becoming, uh, it's, you know, you need to have specific expertise to different stacks that you're running.

And so this is where all of that comes into play. Um, and the onboarding process then also looks a lot different than it did, you know, 20 years ago where it's like, you know, developer came in and they just knew like kind of the, uh, code that they needed to write or the operations engineer knew the, the few racks that they needed to run today. There is a very large amount of tools and stacks and, and projects and things that are running in every single engineering organization.

Um, and getting onboarded into that is no easy feat. Mike, what's your take on this, especially as we kind of live in this cloud era now and um, it seems to me at least that there was a, a shift in mindset, but I think Mitch pointed this out earlier, uh, DevOps was originally part of the IT counterculture and then maybe it's gone mainstream when we were having a chat this morning. So what's your sense of where are we with the evolution of DevOps and how deep is it ingrained in these organizations at this point?

Well, I'm gonna add a little of this and a little about what you previously said. DevOps is ingrained very deep in most organizations and it's getting deeper by the day. We've gotta be able to automate, we've gotta be able to reduce the complexity.

We've gotta increase the velocity of application deployment cuz that's agility and that's fosters digital transformation. But the onboarding piece, you know, we're training architects and whether you're training architects, network engineers or DevOps engineers, as Mike pointed out, there's a reason for this. We're trying to break down silos between organizations and in the training that's out there, they're not training people on communication and collaboration.

They're training people on, here's a name of something and here's how to configure it. But they're not getting into the depth of why, you know, we see certifications and they're basically so superficial and that that they almost give someone enough to do a basic technician job, but not to be an engineer, not to be a DevOps engineer, not to be an architect, not to be anything really. So it's making onboarding there.

So the key is DevOps is there and it's gonna grow and I think it's gonna take over more of those cloud engineering roles because I can have one DevOps engineer now I can augment that DevOps engineer with AI and make them do the role of 10 or 13 or 15 p other people's jobs. But they have to understand the what, the why, the how, why are they doing these things as opposed to, hey, there's this cool tool, let me use it. And that's what we're seeing is everybody's in a rush to use a tool.

Oh, it's exciting, but they don't know why. And half of the tools are the same old tools. It's kind of like the song from the who meet the new boss, same as the old boss.

It's the same thing wrapped up with a pretty little name, but it's not, it's different. Sharon, what do you think about that in terms of, um, do we not concentrate enough on the soft skills that Mike was describing and that we have a lot of folks who can pass a online certification exams, but they're not really all that useful when they go to work? So my take is that, um, DevOps really is a culture.

It's a cultural change that an organization has to undergo. It's not about the tools that those are implementation details. Um, and in that sense, um, a lot of the DevOps kind of, um, being able to achieve DevOps and do DevOps, right?

And, and when we talk about DORA metrics and uh, velocity with safety, you know, all of these things, it's a byproduct of how your teams work together. And one of the things we are actually seeing today is that, okay, we said that DevOps is actually, it's manifested itself, it's propagated, most engineerings are doing some kind of, at least some level of DevOps no matter where they're running, whether they're still OnPrem or in the cloud or doing other, uh, more advanced uh, um stuff. But everybody is doing DevOps in in some form.

And the new evolution is actually that DevOps is now these teams that are considered DevOps and supposed to be kind of this bridge between dev and operations have also become a sort of bottleneck. And we're seeing this as well, um, where like they're building like platform teams or SREs and DevOps and expecting them to roll out repeatable infrastructure and things for teams so that they offload that from engineers, from the engineers who just wanna write code. But even that is, um, is adding complexity.

So I think a lot of the work that needs to be done to achieve DevOps and get to that place of speed and safety, uh, is on the cultural side. And I agree with Mike a hundred percent on that in making sure that you have the, the processes, the communication, the tools, uh, and all of those things in place to support the what you, the architecture and whatever it is that you want to, um, implement in your organization. Because if you don't have that, you won't be able to succeed at DevOps no matter what nifty, exciting new tooling you implement.

Right, Mitch, do we still have a cultural divide among the IT community? I mean, you know, insult intended to our folks who are all adherence to idle, but you know, that's a very structured methodology and I know the latest version has some more, uh, at least the tip of the hat to more agile thinking. But is part of the issue is that we just have these two competing philosophies inside of it these days?

And is that something we need to kind of come together on? Well, as you mentioned, idle four has got, took, took a lot of, uh, kind of the fundamentals of DevOps and tried to influence that into the idle specification. So it's, it's moving that way.

But I think the, the rub, if you will, is the DevOps world is very flexible and dynamic, right? It's if you sort of step back to kind of first principles, even though they aren't formally defined, but it's about creating much smaller elements of work, both whether it's the code that you're delivering and the code you're, you're, you're developing or the, the, uh, infrastructure platform that you're creating, you know, setting this up with automation, making it dynamic things that can change quite frequently and that can rub against sometimes security operations of, well, don't change things cuz when you change things, quality or reliability or those kind of things fall, you know, can suffer when if you, if you really kind of start to get it about DevOps or, or implementing it, that actually that resiliency comes from being able to respond quickly to when there are problems or errors being able to deploy code or make changes or updates or fix vulnerabilities or whatever that is. So that, that is a, I think a cultural or a mindset challenge.

But I think once you start working together, kind of to Mike's point, right? It's why are we doing this, right? We're trying to increase velocity.

Well why do we wanna increase velocity? We're trying to respond to what the business is trying to accomplish, the competitive nature markets that we're in capabilities we wanted to deliver, but we also need flexibility so that we can pivot and change and adjust and not take six or 12 months to do it, but take, you know, days, maybe weeks to do it at times, maybe shorter. So I, I think it's a matter of not, not painting a picture of well i's wrong and DevOps is right.

Well, let's, let's step away from that and talk about how do we apply idle into a, in a flexible dynamic world and adjust, make adjustments to both that fit our company. You know, we call it culture, I think of it as d n a companies have a D n A about how they work and how do you adapt things like, uh, DevOps and idle and others to how you work. Mike, do you wanna jump in here because I'd be curious, I mean, do I just take a bunch of DevOps folks and idle adherence and throw 'em in a room and lock the door and hope that something good pops up?

Or is there, you know, have you seen organizations do something a little more, uh, structured that kind of works? To me it's about bringing everybody together. So I've been designing big architectures, billion dollar architectures for about 25 years now.

And, and, and to me, if you don't know, it's all about the why. And that's the difference between a professional and just the tech. It's the why, you know, you have to start with the business.

What are the business needs? And, and typically that's the siloed world of the architect to translate the business needs to the tech professionals that are gonna go build it. But then you get this conflict of we need to do this cuz architecture is just a series of trade offs to get to a desired business outcome.

And if you don't bring the engineers in there somewhere along the line, or don't add that to their educational platform, to them it's just tech. And if it's just tech, you know, it's just tech and no business buys tech cause they like it. They buy it for a competitive business advantage.

So if your engineers aren't thinking the competitive business advantage and they're just thinking the tech and your architects are only focused on business and your customers don't care about anything other than how does it improve their profitability or their customer experience or something, you got this mismatch. So that's really where I see it. I've been training our engineers and our architects to give them almost MBA level business acumen and we also focus on soft skills, leadership skills, executive presence, CX o relevancy, because it's a world of difficult conversations.

It's a world of building teams, let's face it. We're not gonna go that far on our own and it's gonna be multicultural in everything we do. There's nothing that I do in today's point where I'm sitting here in south Florida where I don't have somebody in India, I don't have somebody in Israel, I don't have somebody in Africa.

We need people everywhere and each place has different things that they specialize in. So that's today's world. And if you don't teach that and you don't teach cross-cultural boundaries, you can easily offend somebody pretty quickly.

You can easily destroy the team dynamics. So for me, you know, in these last couple of decades, it's all about human side of it. And the human side I believe is more important than the tech because together we're much stronger.

But once we let all these boundaries and walls come up, that's where we're there. And that's why to me, it's all about the team. If there's an African proverb, if you wanna go fast, go alone.

If you want to go far, go together. And that's really the struggle that I see is all these little siloed teams and everybody's getting 1,000,001 certifications in everybody else's career, but they're missing the elements. The how do these things work, the why do these things work?

The why do we need the team? You know, the DevOps engineers here know far more about DevOps than I do great. Cuz they're DevOps engineers.

My world is architecture, but what good is that if I design something that the DevOps engineer can't build? And that's really the key for me is how do we tie these and marry these pieces together to build the best outcome for the customer. Sure.

I'd like, I wanna add on to that. I have, um, so I think we touched on a few really interesting elements. And I think one of the, the game changers in, in the, in the world of like kind of connecting engineers to the business, um, has been the whole world of on-call, you build it, you own it.

Um, you, and I think this changed the mindset of how, um, your code as an engineer impacts the business. Um, because once upon a time an engineer would just throw it over the fence and somebody in operations or DevOps would have to own it. And they were completely decoupled from this process.

And I think this brought the whole entire industry, like matured the entire industry in terms of the way they think about technology and how it impacts the business. Um, but uh, but I think also the other half of that, um, the, the interesting part of that, um, um, is that, uh, now we're, we're seeing this like kind of even um, being taken further. Um, and when an, an engineer can understand how their code impacts the business directly, they also mature as engineers.

And this is true also for DevOps, right? Um, today after, you know, all the postmortems and all of the learnings that we've, uh, achieved from, um, many outages and failures and other things, um, all of this, uh, intelligence is taken back into the organization. We know how to mature as an entire industry.

Um, and, uh, yeah, so I, I agree with, um, Mike, a hundred percent on that. I think that everybody needs to understand what they're doing and how it impacts the, the business direct directly, um, because they're not working in a, in a little silo in a basement that has, uh, no, no impact. Mm-hmm.

Let me follow up on that with you on another topic that Mike touched on. But we have this world where we thought, hey, you know, post covid, it's gonna be great. We can hire our developers and DevOps engineers anywhere in the world and we'll have this kind of highly, uh, distributed environment.

But did we really think that through Sharon in terms of how we work together and make that all happen? Cuz it seems like we're inviting people to join teams and, you know, they're in 4,000 miles away and nobody and they don't have any context. So I I, and when I said tooling, when I talk about tooling, I'm, most of the time I'm talking about kind of even just the communication and the support tooling and the way that people can collaborate on, on knowledge.

And I think that one of the things that you need to be, um, really cognizant of and, and really, uh, intentional about is public facing information and documenting things and using text a lot more. Um, more than than we, we used to. Like if you have a zoom and you know, there are different time zones and synchronizing those things are nearly impossible.

Synchronous time is very, very difficult to achieve when you have a follow the sun sort of a team. Um, and this is where like I've seen, I've heard about like companies, I, I also, um, produce the Dev Interrupted podcast in Hubbert, but I I, I like the podcast in English as well, and it's targeted at engineering leaders and, and they often have really interesting, uh, nuggets there. And, and they had an engineering leader from GitLab who spoke about the fact that they're very, very intentional about, uh, the way that they document.

And they, and they dog food GitLab in a sense to create really detailed kind of, um, transcriptions of meetings. They, they put them in public channels, they make sure that all of the, uh, information in the organization is very, very transparent and easily and easily consumable and in a place that isn't, um, you know, in a place that, that that won't disappear on you. Not like a slack, not like something that's, um, it's volatile and it's gone, but somewhere where it's like well documented like in some kind of a wiki or a notion or whatever it is, so that somebody who is not in the loop in a synchronous call can be sure to be debriefed well enough.

And these are the tools that support the engineering, the communication tools and making sure that you're very, very transparent when you have these asynchronous teams about transferring knowledge and intentional about it. I think that's a really good point because it, it is a very collaborative effort and, and Mike spoke to this as well, right? It's not let's all do our pieces and it comes together at the end when we integrate it and build it like things used to be when, especially when you're, you have, uh, distributed development teams.

Let's, let's be honest, I mean we, we've been doing distributed development for a long time, especially when, when get kind of came onto the scene, really enabled that in a, in a much more better, much better way. I mean, developers read coat on planes sitting in coffee shops, you know, covid happens, okay? The rest of the organization starts to do more distributed work, kind of like we've been doing and in many organizations.

So the, there's a, there's a, uh, kind of culture around how we communicate across teams. And sometimes that's broken down by teams using different tools. Sometimes it's, it's, uh, we use a common set of tools for communications like we do in our company.

You know, it's, it's pretty much email and slack and that's where things go if you're doing development, there's also adding to, you know, what the repository is and communications and how we track, um, you know, requests and enhancements and things like that. You can do that and get, or you can do it in another tool, but having that place where it happens so you can go, because when it's asynchronous work, it's asynchronous communications too. So I may have done something three hours ago, I'm in bed next person's picking that up, building it, fixing something that I might have messed up or, or taking it and enhancing it.

And, you know, you need to be able to also catch up and see what happens since you last touched things or you were engaged, We had a really good talk at DevOps days, Tel Aviv a couple years ago, Florian Haas, who's, uh, a friend from the community, he did a good talk on like why you shouldn't dump everything in Slack and why you need things that are a lot less ephemeral and, uh, so, and, and the place and communicate that really well where people can consume knowledge after the fact. Mm-hmm. Um, so a hundred percent like synchronous time is, is a commodity.

And, you know, it's, it's important to like kind of be respectful and mindful of people's time. And another thing, another phrase that he uses is naked pings. Never do the naked pings.

You know, like when someone does, hey, and I just like waiting for you to reply, hey, and you're like, no, just spit it out, just tell me what you need. You know, be clear. Like we're working in an asynchronous format and people sometimes are in the zone and in flow and developing and coding and doing their work and they don't wanna be, uh, interrupted.

It's like a shoulder tap, hey, so make sure that you, uh, you know, if you have a specific question, you actually write it out, Hey, I'm looking for this kind of answer. It's not urgent, it is urgent. You know, just kind of give context to what you need and how urgently so that people know how to respond and, uh, work in a na form.

Right? You don't, don't use reply all On everything, right? Yeah, I, I think that's clear, but I think we also have to get to the common lexicon.

So I came from medicine before I went into tech about 25 years ago. And if I was gonna prescribe, you know, acetaminophen, it was acetaminophen in every part of the world except for maybe England where it was paramo. And granted there were 18,000 different marketing names, but we communicated in the same thing When I went into tech 25 years ago, somebody called me at two o'clock in the morning and said, there's a lot of PVCs that are down and we need to, uh, for example, I'm like, I need your help.

And I said, start a lidocaine boas. And they looked at me like I had four heads and I was thinking it was a cardiovascular thing. The reason I bring this out is in tech, people send us messages and we don't even understand them.

One of my students had said to me, Mike, I work in vm, what do you think I should ask for on the salary? And I said, do you work in voicemail systems? Do you work in vulnerability management?

Are you working with virtual machines? And I love the wikis or whatever kind of collaboration tools. Cause you know, some tech companies, believe it or not, are huge and there's still being run on Excel spreadsheets.

Others try to search email and slack message, which doesn't work. So for me it's two things. One, we still try to get these video conference calls together because I find a lot of people don't read anymore.

And if it's longer than a couple of sentences, they don't read it. So we still need that face-to-face because some people are visual and auditory learners. And then I definitely agree completely though, Sharon, it has to be documented somewhere intelligently.

But I think the clarity of the documentation, the simplicity of the language, the using a common terminology for everything is the real key. Especially in a tech world where we've got companies where there's basic simple stuff and the marketing teams obviate everything. A virtual machine, how many crazy names can we have for a virtual machine?

You know, it's a virtual machine in the, in the data center. Azure calls it a virtual machine. Thank you.

Google comes up with this ridiculous name compute engine instance. AWS calls it elastic compute cloud By the time we're done, and I do speak Greek as a primary language, but if I'm speaking to Greek and somebody else is speaking Hebrew and somebody else is speaking Hindi, we're not talking to each other. We've gotta use some common language somewhere along the line.

So to that end, we have a question from the audience about, you know, they're asking about sprints and I'm wondering, you know, are the, is the concept of a sprint, Sharon, as we once known, it kinda needs to be reevaluated in this asynchronous world and how do we kinda, you know, apply that concept that we've leaned on for many years in this new kind of model? So I do believe that there needs to be some way to quantify the amount of time that you work on a certain project, but I do think that the, uh, two week kind of sprint format is really random and it isn't appropriate for every single kind of pro, you know, project. So the only way that you can actually, if you do wanna have some kind of way to define a certain amount of time where you have some kind of a sanity check is either you have to break down a certain project into smaller chunks and be cognizant of the fact that a large project is not gonna be achievable in like a two week sprint obviously, or something like that.

Um, and to understand the milestones that go into different sprints. Um, but some, some companies are actually not, not working in that format anymore. They, uh, you have like kind of, obviously with the CI I C D and rolling deployments, some companies are like, um, you know, deploy as quickly as you can and, and if you have an issue and if you're not managing to deploy, if you have some kind of bottlenecks because of somebody who's not picking up, uh, their, your coder view or, or whatever it is, um, raise the flag.

Um, but you know, depending on what you're looking to achieve, sometimes a, you know, random two week kind of time period that you define as like your end all be all for delivering software is actually not beneficial. And you'll find that you'll have, uh, it's more error prone, quality goes down and, and many other issues that you need to pay attention to that will directly impact your DevOps engineers. And when they have to maintain that code and uh, and run it in production.

So it's, somebody needs to be re you know, you need to rethink, uh, certain paradigms that don't necessarily, um, align with new modern delivering software. Mike, what do you think of that? Cuz we have another question that's, you know, basically tugging at, we live in this world where we're supposed to be driving digital business transformation and it's all dependent on software and yet, you know, there are these laws of physics about how much time people are available and how much time they can write code.

So do we have a disconnect between our business agendas and what's actually practical? I mean the reality is we do, and I think a lot of it is the unrealistic expectations of this can be done instantly. And again, there's too much separation.

The people that actually build it know what they're doing in terms of building it. But they're typically so far away from the C-level executives that determine what needs to be done. We've gotta breach that.

I've spent the last 25 years as an architect basically translating business requirements from sea level executives to detect people that actually build it. I don't think it's good enough. I think the executives need to understand a little more about what goes on in the world.

Because let's face it, tech is no longer a basic competitive advantage to have it. If you don't have it, you're out of business. And then it's how fast can you develop the technology that supports the business and what can you do to have a competitive advantage?

But all that's gone, if it's not created and it's not created on time, it has to be sped up as fast as it can in ways that make sense and still slow down to the point that it's quality. One outage can destroy a brand. Yeah, bad software can destroy a brand sloppy code, which is, which is security prone will destroy a brand.

So yeah, I completely agree with it that it needs to be done. But you know, my world has been basically educating engineers, architects and getting them outta that pigeonholed world where they sit behind the desk all day long and only look at code. It's putting 'em in the bigger stage.

And you know, there's a direct correlation between business acumen and salary. Dramatic, same thing with soft skills. But you know, I come from medicine, lack of communication means disastrous consequences.

And it's the same problem we have here. I'll give you a perfect example of using tech the wrong way. The US government mandated electronic health records about 10 years ago prior to electronic health records.

Those of us that used to prescribe would write these sloppy prescriptions as the pharmacist would call us and say, Hey, what do you think? What'd you write here? Mike and the techies and the government drove the mandate for electronic health records at the time.

Medical errors were the fifth leading cause of death in the us Poof, you must use one of these electronic health records. Guess what happened? Medical errors went up 250% prior to covid medical errors became the third leading cause of death in the United States.

Medical errors after the tech. So first it's, you know, what is the end business goal? Then you map out that end end business goal.

People process these technologies, then you determine what the architecture needs to look like. And you can't design the architecture without collaborating with the engineers. And that's the biggest place where I've seen it.

I don't do an architecture where I don't speak to 10, 15, 20 engineers along the way. They're part of the team. But I've seen people that do the architect's job is design, present and sell it.

And if they don't collaborate with those engineers, they're gonna make very unrealistic expectations. And then it's gonna reach that post-sales team that's gotta go build this thing and they can't do it. And the time allotted and then the customer's upset and there's brand damage for the provider or the customer.

No one wins. So gotta get 'em all together. And I think if you do that, you'll be in good shape.

Mitch, there's a question here that's a follow up on this, but it points out that not all software engineers have the same level of expertise or even experience and it can take one, four minutes to fix something and another one four hours. But how do you plan around that when you've got people with varying skill sets in the team? Yeah, it's a, it's a really good question of, you know, when we, is it gonna take four hours for uh, maybe some SREs to resolve an issue or an ops person when a developer might be able to pinpoint it?

There, there's sort of multiple parts of this. One is communication, right? If you know this is an issue, you know, you can post on whatever communication channel you're talking on.

I'm working on this, does anybody know something about this? The other is, and this is where it gets more complex, is what I'm looking at this, who owns it, right? Who's the person that I go to just even knowing that.

And you get into microservices and service mesh and that gets complex, right? Like who owns this one thing, want this one microservice? Then you can go back and look in, in the repository and kind of see who checks in what.

But that's not always obvious to an ops person or to someone who is not living in that tool. So, uh, the, the other side of it though is uh, uh, I hope we're living or we're, we're, we're building a world where it isn't as much throw it over the wall like in the throw it over the WA wall world and then you say, go solve that problem. Figure out what's going on.

That's hard. That's extremely difficult. If on the other hand, for example, you have SRE as part of your team, um, or platform engineers or others or who are using a observability tools that start to understand more of what's happening inside the software.

I mean, they're not the architect. They're not the developer, they're not that level of expertise, but they're familiar enough with what's happening and there are tools, you know, doing distributed tracing and things like that that can help you start to narrow this down. So I think some of that is, you know, and Mike might have some thoughts about training in that, in that world where you can expand of, it's not just, I'm not the here per the person to answer the phone and then go dig around in the logs and I gotta figure it out myself.

There are better ways to do those things now and we have tools and people that can help. What what are your thoughts Mike? I totally agree.

There are tools that can help, but it, it also comes down to hiring. And it comes down to the philosophy of the training person. For example, I don't hire hobbyist to me a hobby.

Somebody that's got 15 certifications and 15 people's careers is a hobbyist cuz it might take 20 years to be really great at one career. And when I get somebody and they're certified in DevOps, they're certified in cis ops, which is maintenance, they're certified in architecture, then they're a certified developer, then they're a super certified in this, this and this. What do they have?

They have nothing. You don't see an Olympic athlete train in 50 different squares. They'd be horrible at everything.

They train in one. And when I've interviewed and I've done over 5,000 interviews, actually 6,000 at this point of technology professionals, I can easily find somebody with 30 to 50 certifications. That's nothing.

But finding one person out of a thousand that really knows how to do their job and do it well is impossible. Sometimes I'll hire people and train them myself if they were have the right attitude, energy, and enthusiasm. But the hobbyist philosophy of let me learn everybody else's job so I can tell everybody else how to do their job, which is the worst thing to do anyway, and not know how to do my own job.

That's the biggest challenge I've seen in the last 25 years in tech. And with the, I need every AWS cert or every Azure cert or every Google cert or all three of them. And in the end, the people don't even understand what the underlying technology is that makes cloud possible in the first place.

I'd rather somebody learn how to drive a ho a car than learn how to drive a Honda. And it's the same thing I'm saying in tech, learn your job, you know, the airplane pilot does not need to be a flight attendant. They do not need to be an airplane mechanics.

They don't need to be an air traffic controller. And if they did, they're not gonna be good at anything cause they split their focus. Sharon, let me follow up on that.

Yeah, I'd like to follow up on that. Oh, is there, you wanna add to the question? Cause I, uh, I have some thoughts on the, I wanna add to the question, are we too harsh with each other when we have those newbies that come on and then they get intimidated and then they don't ask the questions because you know, they're in this, you know, intense meritocracy space and maybe we need to chill out.

Okay, so I have, that's exactly the area that I wanted to touch on. I wanted to touch on the area of skilling up. Uh, because we're getting to an age where there is, um, more technology.

The, the systems are larger and there are more moving parts and there are people to run them. Uh, and skilling up is gonna be a crucial thing for businesses to survive. Um, and one of the, and the question was like, oh, why don't I just give it to the, uh, resident senior engineer, the resident gu guru instead of skilling up my engineers?

Um, and so one of the ways that you can do that is, is buddy systems where like if there is, uh, an outage or some a learning experience that you do take the time, enable those senior engineers to transfer the knowledge and transferring the knowledge, um, really is the most effective in a real world scenario and in a real situation where they can actually get the hands-on experience of troubleshooting a real production system. Um, so all of these things are really, really important. And I actually think one of the things that, uh, Mike said, and also Mitch said, um, are, are, are a hundred percent true.

And I think these are the things that we also need to think about. Um, is that because of all the abstraction layers that have been created in the world of cloud, a lot of the, uh, new, uh, developers and it's not even their fault, don't really know the, the primitives and the fundamentals and the things that are happening under the hood. And this, it's really, really critical because at the end of the day, if we're building software upon really complex systems and that, and you won't have the people on hand to troubleshoot when things go down, you're gonna be in big trouble.

And this is also kind of what's gonna be coming when it comes to AI and AI generating our code. Who's gonna, who's gonna troubleshoot that code that nobody wrote, right? Um, and so I think that the skilling up of your junior engineers is equally important, uh, to your uptime and to your business because you will not be able to create your next, uh, generation of leadership without it.

And if we just take a look at numbers, uh, I mean, to be an expert in something, you need to have invested 20,000 hours. Proficient is 10,000 hours. Um, so the, the junior engineers need the opportunity and the, and and the chance to actually do these things in order to gain that expertise.

So don't don't forget that when, uh, when you have a certain learning opportunity. All right, we got to 35 minutes without anybody mentioning ai, but here we are, um, Mike, are we training people for the wrong thing? Because there are a lot of tasks that we're trying to change make happen today that may be automated in six months from now or a year from now.

And maybe do we need to think about what it is we want people to do, not just today but tomorrow? It really is. And and truth be told, we had a really good at cloud engineering program and we pulled it about a year ago and we pulled it for the following reason.

We knew, and we, we still are training architects. We knew AI was coming and we knew AI would severely change the landscape of our engineers that are out there. We do need to bring up our junior engineers.

But a lot of the stuff that junior, that really junior engineers do can actually be done by ai. AI doesn't ask for a raise, it doesn't complain about work-life balance. It doesn't go on strike.

And, and sadly in certain cases it can do what people do better. But the problem becomes is you know, the stuff that's gonna come outta AI isn't gonna be great for a while. We're still in a beta phase.

0, which is pretty good. What's it gonna be like after those 10 billion that Microsoft put in it? What's it gonna be like in a few years?

I think it's gonna be scary. Good. We look at Google's bar, it, it's kind of like in its infancy, but it won't be Google will throw some money behind it.

We look at AWS with their code whisperer. I think it changes the landscape. I think if we don't give our engineers the people skills where they're done, AI is not human.

AI can't build a relationship. AI can't work across boundaries. AI can't work across cultures.

AI can't really tie all the pieces and parts together. So as long as, and, and we'll as long as the engineers have that soft skills, that executive presence, the communication skills, the business acumen, the CX o relevancy, I think they're gonna be fine for the future. But if they're only learning the tech and it's just surface level knowledge of the tech, it terrifies me for the future of these technology careers.

That's why we pulled our engineering program. No, I'm not gonna say we're not gonna bring it back and we're not gonna have the AI enabled engineer and it's not gonna be super focused on business acumen and leadership and executive things, which we're thinking about. But the standard engineer of the, that we have today, I think unfortunately mostly will be replaced in the future.

And that terrifies me cuz there's a lot of really wonderful people that are super smart. Same thing for bloggers, for example, technical documentation people. But the human element cannot be replicated.

And I think as long as we focus on that and we keep the culture strong and we keep the working relationships on, then it's a partnership between people and ai. Mitchy telling your high school friends and kids to go into DevOps at this point or you know, what's your sense of where are we for the future career of a DevOps engineer? I'm excited cuz I work with interns and you know, folks that are still in school a lot.

We're in software engineering. It, it's, it's it interesting time to be in that world because you know, you do have, you know, assisted code development tools, um, you know, whether it's through GitHub or Microsoft or other environments and, and I think I'm not a person who think that's gonna replace a lot of people. I think it's gonna be more assisted kind of things.

And also, you know, my, my complaint is when I write pick a language python code, I still do a crap ton of housekeeping kind of junk. I just don't really know what I have to do anymore. That's the kind of thing I think that, uh, Mike might be be referring to, but start to do more of that kind of activity for me.

Setting up the environment, setting up how I'm gonna communicate to this API stack or whatever it might be in these libraries that I need, yada yada. I think those are the things that AI can step in in the near term and really help us be more productive. You know, are you gonna say AI build me a online e-commerce system that, you know, does, here's the 55 requirements I needed to build?

No, I mean that's not in the near term. Certainly I don't know that ever, ever will happen, but I think it's a great time to be in software. I wouldn't be, I wouldn't be turning away from it cuz of ai.

I'd be moving towards it. Uh, Sharon, what do you think? Cuz you're a cloud native specialist in a lot of ways.

And I look at that thing and I go over to the C n cm landscape and I see like a bazillion projects and I just like my eyes cross and I'm like, this doesn't look like any kinda easy buttons arriving anytime soon. So what's your take of where we go from here? So I, I mean, I think that, uh, AI is an excellent tool and I think it, where it's at right now is even mind boggling if you look at co-pilot, if you look at, uh, chat G P T and other tools.

But I think in the same way that, um, I I am more in, uh, Mitch's camp here in that I think that, uh, I think it's gonna be a tool to help skill up engineers more quickly. Um, juniors, um, will be able to leverage these tools as kind of another tool in their, uh, in their box to, to help them kind of, um, not have to deal with the small details, the nitty gritty and be able to think about the higher order concepts, the higher order things that they can be learning and, and designing and the architecture, as Mike said, and things that are a little bit more that require the human versus, uh, you know, necessarily a machine. I think that it's okay and DevOps actually introduced, uh, machines and automation and machines, machine interaction APIs and things like that.

And I think this will be another way to take advantage of machines, um, to do things that humans shouldn't have to do, um, so that humans can, uh, you know, be freed up to do the, um, the more important tasks. Um, I do think in the same way that, um, AI is bringing a lot of innovation, things like no code and low code are also helping in the terms in terms of junior engineers and skilling them up. Uh, and I think that almost every engineer is going to be well-versed in what's called prompt engineering and know how to kind of, um, you know, get really great prompts to, uh, extract things that will help them in their day to day.

But I don't think it's gonna replace engineers per se because I think engineers have a lot more to contribute in terms of, uh, the stuff that they're working on. All right. I think it'd be good scaffolding, but I'm not sure it's, uh, the core.

All right, Mike, I think we have time for one more question. I guess I'm dying to know the answer to the following. You see all these guys, they wanna hire these great engineers.

They're looking for people with 15 years of experience with Kubernetes on a platform that's only been around for six years. And, you know, the question I have is, you know, are we, you know, realistic in the fact that we seem to all wanna be George Steinbrenner type owners and hire the best talent at the highest price when maybe we need to build a farm system and win the World Series that way? Well, you know, there's a couple things.

If you look at the trends and you look at a cloud provider like aws, they're trying to commoditize these roles. Here's your cloud quest. It's a video game and it's gonna teach you almost enough to be able to do something, but not enough to be a professional.

So I see the commoditization of these roles. At the same time, we look at job descriptions, which ask for 10 Olympic gold medals, a thousand years of experience in 50 different careers. I'm gonna tell you this, I've never had more than 10% of anything on a job description for any job I've ever accepted while I've never been on an interview where I didn't get hired.

Now, of the people that I coach, they get jobs where people want 15 years of experience and they have none because it's not the experience that hiring managers care about. They don't care. I've, and I've interviewed thousands when they care about the following, can you do the job experienced or not?

Can they trust you? Are you energetic, enthusiastic, and passionate about the work? Or are you s lazy and sleepy and on TikTok quiet, quitting?

Are you gonna bring out the best in others? Are you a good team player? And will you go above and beyond if you can demonstrate that these pe everybody's getting hired.

So that's really there. I, I do think we need more specialists because most of my life has been cleaning up the mistakes that were made by generalists that try to do things that they didn't know. All right.

Hey folks, we got 30 seconds left. I want to thank our panelists for sharing their knowledge and expertise today. As they say, it's all about attitude and culture, and you can always learn the rest, right?

Absolutely. Thanks guys, and thank you all for participating in the panel, and thank you all for watching.