Google Outage, DevFinOps & Platform Engineer Pay | Techstrong Gang Ep. 860

Hey everyone. It was a tough time for Google Cloud. Hopefully it's better now you're watching Textron Gang.

Hi everyone. Happy Monday. It's Alan Shimel here for Techstrong Gang.

Um, we've got a lot to talk about today. Of course, the end of last week was a, was a bit of a bumpy ride for our friends at Google Cloud. We've got some platform engineering news to talk about it more, but we've got a great gang of people to talk about it.

Let me introduce you to them. First of all, for the first time, I think on the show with me is a, a friend of mine for many, many years. She is a multi-talented, faceted individual, Dr.

Tracy Thayer. Stacy, it's so good to have you on here. Um, it does my heart.

Good to see you. How's everything? I'm excited to be here.

Thank you, Alan. Excellent. Also new to our Textron gang, uh, gang is Jack Gold.

Jack, welcome. And you know, I don't know if you've had, tell people a little bit about yourself. Yeah, thanks Alan.

It's good to be here. Uh, I'm a, uh, industry analyst. Been an industry analyst for about 30 years or so, and covering a pretty wide range of stuff.

Worked, uh, for some big firms for a while, and decided about 20 years ago to go out on my own. So I've been doing that as an independent industry analyst for that period of time. Fantastic, and welcome to the Gang Jack.

Great to have you here. Our next guest is, well, she's been a gang member since day one. She's the, uh, deploy hub, CEO Open Source ambassador extraordinaire, the one and only Tracy Ragan.

Hey, Tracy. How are you? I'm doing great.

It's good to see you again. Good to see you all. And then last but not least, batting cleanup.

He throws right-handed bat's. Left-handed plays shortstop. Occasionally he's up, what near Poughkeepsie, but Harris in New York, our Chief Content Officer, Mike Vizard, And, and coming off a lovely Father's Day.

So happy Father's Day to you too, Alan. Yeah, absolutely. Happy Father's Day to all those dads out there and all people who stand in for dads too.

There's a lot of people who aren't necessarily dads who take that dad role on and, and, um, thank you to all of them. Anyway, Mike, it, it was a busy weekend. It was a busy last week and it'll probably be a busy this week.

What are we, what are we kicking off with? Yeah, it's starting around Thursday afternoon, east Coast, I might think. com.

We had a few of them down for a couple hours 'cause it affected WordPress and all kinds of organizations were reporting issues. And Jack, you know, we're now here on Monday, and we're talking about hindsight, but I wanna start with you on this. Do we still have these kind of single points of failure?

I thought we were better than this at this point. Well, we'd like to think we were better than this at this point. The the fact is that we're not, uh, one of the issues that people fail to understand is that even though you may not be, you personally may not be a direct client of Google Cloud, a lot of the infrastructure that you use is a client of Google Cloud.

So that if Google Cloud goes down, even though you're not using, you know, Google meets or whatever you, you think you're using, if you're using Spotify, if you're using, if Cloud CloudFlare, if you're using a bunch of other stuff that's powered by the components of Google Cloud, you're gonna feel that effect. And so that's really what happened here. It was, it was an escalating problem that started at Google Cloud, but then quickly spun out to all of the other people that use Google Cloud services for, for things like identity, for instance.

Uh, that then brought down all of these services that, that people are used to that, that don't say Google Cloud on them. So this is not unique to Google Cloud. It's going to be unique to any of the services, the cloud services we use that are built upon other infrastructure kind of invisible to us as end users.

Uh, it just happened to be Google Cloud at this point, but it, it's been Azure in the past. It could be AWS uh, it could be almost anything, Even Oracle. So, so Mike, I, I got a few things, Ted.

com, it's not gonna work for you anyway. That's not our website. com.

But, and, and Jack, we're one of those companies that though we don't directly pay Google Cloud for our hosting, our specialized host provider actually uses the Google Cloud, cloud native, uh, format. And so it affected us. But Mike, I don't buy everything Google gave as a timeline here because we, we had a problem with Streamy Yard on, uh, Friday morning's Textron Gang, which was recorded Thursday morning at about 10 o'clock in the morning.

And it was already, streamy Yard was already being affected. And, and it was pretty much down most of the afternoon because of this Google Cloud thing. On top of that, CloudFlare Flare had some real issues.

Now, CloudFlare, of course, is, you know, I don't know, 26% of the internet goes through CloudFlare or something like that. But I didn't realize they were that dependent on a single cloud provider, namely Google here. I don't know if, if the CloudFlare incident is separate and apart seems too coincidental.

But I think that contributed to the overall malaise delays of, of all these sites, you know, is cascading pretty badly. You know, it's, it's a domino effect, Alan, right? Uh, you know, once one domino falls at the Google site, it, it's just a whole series of other dominoes that are dependent on that first domino.

And whether it's CloudFlare or whether it's others, whether, again, Spotify, you know, pick your favorite, how many sites use, use Capcha. Um, you know, that's a Google service. So, um, it, it's really an issue about interdependence that we don't see.

It's all invisible behind the scenes, but it's, it's really there. Tracy, is this bad engineering or is this just unavoidable nature of the thing? Well, I think it's a reflection of how important API management systems are.

Right? You know, um, this was, I I think the change some kind of a quota and their API management system that brought it down. What a simple update to create a massive outage.

So we have talked in, in previous gang, um, discussions. We've talked about APIs and we used to talk more about them, and I think we've forgotten about them somewhat. So this is a reminder how important those API management systems are.

And it even goes further than that because we still have issues with API security. This was simply a pre, it looks like a, a literally a change that kind of like the, when, um, when all the Microsoft servers went down because somebody updated something that changed a parameter that gave everybody the, the, the, the screen of death, right? The tombstone.

Um, but yeah, api I, APIs are important and these management systems have to be treated with some care. Mm-hmm. Stacy, explain the psychology of this to me a little bit.

'cause every time there's one of these incidents, everybody stands around and says, well, that's a wake up call for sure. And then about 24 hours later, everybody rolls over and hits the snooze button and forgets about it. Um, is there something that some flaw in our souls as it people that we can't quite wrap our heads around the fact that the cloud is a single point of failure?

Or, or are we living under some sort of delusion? I mean, I think it's, it's a matter of, well, how bad was it? All right.

What did that, how bad was the pain? How bad was the hurt for, for the company that I worked for? It was okay, we couldn't get into a couple of Google meets or, you know, so what did we have to do?

How is there something that we couldn't get around? And I think for most people, okay, it was a couple of hours and then we go on. Now, if it started happening more and more, if there, if the failure was more, more painful, then I think people start trying to make change.

But people are so reluctant to make change to try and get backup systems to try and diversify that. It's just much easier to put all their eggs in one basket. 'cause you think it's Google, they've got, they know what they're doing, they're never gonna let us down.

Or whether it's, you know, something or Microsoft or something else. And you've, you've chosen and that's who you stick with. Uh, but that to me just shows the flaw in that kind of planning that when you put all your eggs in one basket or when you rely on something so heavily, or ignore it, or just put your hand head in the sand and say, it wasn't so bad that we just go with sometimes the path of least resistance, whether we, even if we shouldn't, I'm trying to assess the total cost of this thing, and somebody will of course, naturally throw around numbers with fees in it.

But, um, to, you know, Stacy's point, uh, so I couldn't log into WordPress and I couldn't load a story for an extra day. You know, what did that really cost versus what did it really cost? Somebody like, uh, Spotify that maybe has a business model that's based totally on Google Cloud, and maybe they should be a little more, uh, aggressive about single points of failure than we need to be necessarily.

But Alan, what's your take on the math here? You know what, this is like talking about ROIs of security, right? I I never believed in them, even though I sat and did these ROI calculators that we gave to the sales team to use.

I mean, I look, you, you take your best guess, basically, and you, you know, and there's some, it's more, uh, subjective than objective. 5 x, right? And then you want to carry that across, but at the end of the day, no one's looking for an exact amount, right?

They, they want a ballpark number, usually a big number that does end with a B, you know. But if you look at things like, you know, over the years we've all read the Verizon data breach report and, and some of the other security reports, they'll tell you that network downtime roughly equates to YZ amount of dollars per hour. And, and you could use that as a, as a, you know, a starting point.

I, I don't think you could ever get your thumb on a, on a much tighter upward than that. But suffice to say, it's a big number, it's a major pain in the butt even for us, because Yeah, okay. All of our sites were, it wasn't just a few, all of our sites were down for a decent amount of time that it's hard to put a, a real number on it, but it definitely cost a significant mon money.

What might be interesting, just to, to build on that a little bit, Alan, from a, from a cost perspective, is if some of these folks that are so dependent on Google decide to, to go sue them, uh, you know, I could see that happening with, there are a lot of lawyers in the No, I, I, I don't think that look is America. Anyone could sue anyone, right? But mostly if you're a Google customer, they have SLAs in there and, you know, even with a five nine SLA, that's still a certain amount of time down a month.

And if you sue them, and if you read the fine print of your SLA, what you're entitled to is Google was down for two and a half hours. Two and a half hours is about 150 50th of your monthly bill to Google. So they're gonna refund you $2 and 53 cents.

Very sorry. Doesn't make up what your real losses are. Yeah.

I don't disagree, but you know, I, we're, we're probably gonna see some of that stuff anyway, just because, I mean, look, you, you saw this right? Delta, remember Delta sued, uh, CrowdStrike over the outage last year? Yeah.

So you, the thing about it is, is I, you know, I, when I see things like this happen, when we, when these come up and Google's done great, they have, I mean, I don't know if they've ever had this kind of, uh, of press in the last, I don't know, five, 10 years. They, they're actually a pretty consistent company to be relying on. But what if this is critical infrastructure?

You know, we, we we're talking about, you know, you might not have been able to get to a website or you might not have been able to hold a Google meet. Um, that's not necessarily, as Stacy pointed out, super critical. But what if this was our electrical grid Or a hospital?

Exactly. So how, how, what, what can we learn from this, um, to prevent critical infrastructure from having similar problems? I think that's really the que the, the conversation that we should be having.

Not all outages are created equal, and not all networks are created equal. Certainly. But what we learned, Alan, was the dependency across these systems.

Oh, absolutely. But there's a, there's a different mathematics involved when you're talking critical infrastructure, right? Over the years, I, I used to do some work when, when I, was it still secure?

We used to work with the good folks over at NERC and ferc. I dunno if you guys know NERC and ferc, those are the people who are responsible for running our nuclear energy, uh, nuclear energy plants. And I will tell you, they, they have real failovers and Plan Bs and options, right?

You should, if it's truly mission critical, you've gotta have contingency plans for when stuff hits the fan. And I, I think you do have that. And a lot of these mission critical, I, I frankly was surprised, and I'm not banging them in particular, but I was very frustrated with Streamy Yard yesterday, right?

We had live events going on that I had a stream that was pretty mission critical to my business. And, and the fact that they're solely dependent, it seems, on Google Cloud. And because Google Cloud was down my streaming, my streaming ability was nil.

You know, there's another piece to this as well. I, I, I don't dis disagree with anything you just said, Alan, about backups and, and having secondary, uh, infrastructure that you can rely on. I, I, and by the way, I, I would imagine Google and, and Microsoft and AWS have that as well, but one of the pieces that is apparent to me is that at the end of the day, someone screwed up.

This was probably a human error. You know, we don't have yet all of the details, but it's very likely that someone hit something or did or hit a button, or they shouldn't have, you know, the CrowdStrike example that you gave earlier, it was a human failing. And so, no, no matter how good our systems get or can be, we, we still have to deal with humans.

And the humans getting in there and messing something up is a real problem that I don't know how you fix. You know, we, we let AI run everything, I guess, but that doesn't work either. Before we end this conversation, I do wanna call out one thing.

There is an organization that benefited handsomely from all this. It's called Starbucks. And there was more people in Starbucks yesterday than any other day recently, because, well, they couldn't log in.

Well, but even if you were at Starbucks, you couldn't get on Streamy Yard. You still had your CloudFlare, I'll tell you two organizations that benefited from it yesterday. One's called AWS and one's called Microsoft Azure, because that's how people act, right?

Oh, they're down. I'm moving my stuff too. AWS or I'm not using Google Cloud anymore.

Yeah, We went to Zoom, right? Like, yeah. You know how that goes.

But as Jack said in the beginning, you know, the let he without sin throw the first rock into the glass house. I thought the other thing in the, and some of the articles that I read when I dug down, I said that the way they fixed it is, was they bypassed the per the, the, the changes that they had made. Um, instead of correcting the changes, they, they, they kind of did an emergency fix.

And reading the article, the whole thing said, said to me, why, why don't they have test impairments? Well, how did this happen? You know, internally, something really got whacked out.

Let's just say it got whacked out, because normally you would've changed these, you know, you would've updated this management API management system in a, in a different arena before you pushed it out to the entire world. So it ki it, it was a kind of a weird one when I, when I was reading what, what caused it, because it was, I don't know, I don't know what they could have changed. I have no idea.

Maybe, uh, they changed, you know, how much data could be pushed through who, who knows what they updated? But how did, how did you break that? Right?

How did that happen? Human Error. Yeah.

Human error. I guess it's, I guess it's, thank God for load balancers, right? 'cause we could shift things around, But what did they do?

Like bring down the number of concurrent connections or something. I mean, Oh yeah. I mean, I, I, I'm not saying they're lying, I just think there's more to this story.

Oh, thank you Alan. That's probably what I was alluding to. Yep.

Um, we gotta take a break. We're gonna jump onto our B block in a second. You're watching Text Trump Gang.

Hey folks, welcome back. And we're gonna return to a topic we've talked about in the past. It's called finops.

It's the idea that we're gonna take our finance people and our IT people putting together and manage our cloud costs better. com talking about there's a greater need for urgency from a consulting firm called Do It. That is the author.

And by the way, we do take contributions to our websites. And if you're watching this, we'll consider making a contribution from the content side. We'll make you famous.

But Tracy, the author, is making a case that says that there's just simply not enough urgency out at the DevOps engineer's point of view. 'cause everybody's kind of focused on just making the thing run, and the cost of it is maybe secondary. And my question to you is, A, do you agree?

And B, if so, what's to be done about it? So, you know, DevOps teams have been pushed for years now, um, uh, pretty much in two areas, not even innovation, agility and velocity. Uh, how do you push things out to end users, get new features out to end users as fast as possible?

Um, which is important because that's what drives business. What keeps, that's what keeps us competitive. Um, it, it is, it's, it what, it's what we do, right?

That's what DevOps do. We DevOps engineers make it possible for us to make quick changes to software. Now, when we think about finops being part of DevOps, or having these two organizations talk more, of which they do, by the way, we're now talking about more accountability.

And sometimes it's hard to be completely accountable when you're trying to move fast and agile. So we're shifting Now, if this is the case, uh, and I do believe that we should be adding more to the DevOps process, we should be thinking more about security. And this is another part of the finops discussion.

You know, what is operational impact? What is the change going to do? How, you know, is there some regulatory issues that we should be exploring?

And what does it cost? This is something we've really never thought about in DevOps. It's true because we have been pushed by upper management to get fixes out fast, not to be accountable for the cost of it, or even regulatory compliance in, in many ways.

We talked so many years and years and years, we had this, this discussion about separation of duties. And we tried to work on that. Now we have generating SBOs.

Sometimes we get that done, sometimes we don't. Most, most workflows don't even have that. So adding cost is going to be an issue for us.

And mainly because DevOps pipelines, as I have talked about many, many times on the show, need to evolve. It's hard to update DevOps pipelines right now when they're so scripted and there's thousands and thousands of them. So we have to do this in a different way in order for us to be more accountable.

We're not gather, you know, Orillia and Deploy up was probably the only evidence gathering store so that you can start doing historical trends and look at, uh, potentially add cost analysis in there. So we don't have the tools to actually incorporate finops and accountability into existing DevOps pipelines. I'm not saying that we shouldn't do it, I'm just saying that I kind of doubt if, if, you know, the C-Suites gonna say, yeah, put a bunch of money into that because OPS can start managing costs.

I don't know if DevOps needs to Theoretically. So Jack, whose responsibility is it to manage the cost? Is it gonna be to Tracy's point, the centralized IT team led by maybe a CIO?

Or is it gonna be the software engineers? And I don't know, I mean, you've been at this for a while, but is there a change in the tenant of the conversation about cost in it these days? Uh, there's always a conversation about cost in it.

The bigger problem in my view is that it's really hard to retrain people once they're used to doing something a certain way to do it differently, right? And so if you are going to get DevOps folks, it folks that have been concentrating on getting things done as quickly as we can, 'cause we have to support the organization and who cares about the cost to start thinking about, well, if I do X versus Y, I'm gonna spend an extra million dollars. It's gonna be a real problem, um, to get those folks to think that way.

And I, and I think management has a role in, uh, and a responsibility, uh, on that side. But retraining is going to be the, the, the key issue, uh, going forward. And frankly, you know, the, the folks that we train, you know, the, you go to school to learn software engineering, they don't teach you about the costs involved.

They teach you about here's the best way to code, here's the most efficient use of the CPU. But by the way, they all have cost issues with them. But it's not really about how do I do this?

The, the cheapest, fastest way. Compute cycles for most companies are kind of invisible. You know, they cost something, right?

But they're invisible. There's so many of them. We don't have to be efficient at what we do with them.

And I think that's the real situation here, is how do we evolve the thinking in, in, in the DevOps space to also consider, if I do it this way, what's the cost to the company? So I, Mike, I, you know, you know, there's an old adage, you keep banging your head against the wall. Either the wall goes soft or your head goes soft.

And that's pretty much what we're up against here, right? Let, let's take it from a people perspective. And Stacy, I'd be interested in your take.

And I don't mean to just pick on DevOps. This isn't a DevOps issue. This is an ops issue.

This is an IT issue. People are under such pressure. Get it done, get it done now.

Make it fast, make it work. We're gonna replace you with ai, right? You gotta make this happen.

They're not necessarily rewarded for making it happen the cheapest. They're rewarded for making it happen the fastest. And so if you wanna now kind of change that equation and say, it's okay not to be so fast, 'cause I want you to be cheap.

They look at that as, oh my God, the bing counters are in charging it, right? We, we, we go through that a little bit ourselves here. I had someone write me tell you, you still using your password manager?

We can shut that down and save money. You know what f you, I need my password manager. I'm not using I'm, I'm not going with that.

When, when your quest for saving a dollar starts cutting into productivity, you got problems. Now, I'm not saying there's not waste, but almost since the very first day that the cloud was the cloud, someone spun up an instance and didn't shut it down when they were done. And nothing has changed since then.

I've got one answer for you here. I feel like I'm talking to Dustin Hoffman in the graduate. Got one word for you.

Automation. We need to automate finops so that it's not necessarily the Porsche Schook DevOps engineer or the ops person who's responsible for, for counting the beans. We need to automate that so it gets done in there and take it off these people's already crowded overburdened plates.

There's even a bigger piece. I think, sorry for interrupting Ally. I just wanna ex expand that.

I, I don't disagree with you, but if you're gonna automate the process, you need to automate the entire cost process. It's not just DevOps, it's all of it, but it's also the end user environment, right? You need to, you need to, to to, to follow the, the dollars all the way through.

You know, what I think of, of, of concepts, you're giving these developers what feels to me like a ball and chain and saying, here, run with this and be as fast as possible and as agile as possible. And it's like if you're, you're carrying a bunch of weight and you, you're not as able to be that nimble, it's going to slow you down. It's going to, to run into that ability.

And they're also not necessarily exercising that muscle of thinking that way. And so when you say automation, I think, well, it's good to, to, to train them to have that, that, uh, idea, whether it's a notification of here's your budget and you're exceeding it and you know, what does that look like? But again, it comes down to that, that pain point and what, what's prohibiting you from moving forward in the way that they're designed to, to do their job?

And are you holding them back into to what's the advantage of that? What are you really paying for at the end of the day? And does the, does the cost outweigh the benefit?

Not always. I'm not entirely sure I agree with, I'm not entirely sure. I agree with the premise that I have to have a trade off between fast and inexpensive or at least some modicum of cost control.

But these things are not mutually exclusive in my mind. But Tracy, Well, The thing about it's is that we're already managing costs. We don't just not look at cost.

You know, IBMA couple years ago bought cube cost, right? To track the cost of, of containers, uh, and their Kubernetes configurations. But that data is not connected to the DevOps pipeline.

So, and, and most of these DevOps, CI/CD tools, they're, they're, were, they're, they're job schedulers. They're just job schedulers, and they have a log that goes with it. They don't have the ability to track data.

They don't version data. They don't even give you historical references other than where a log might be. And if a build was successful, that's what they, that's what these tools are doing.

So we will fix this. I believe that MCP servers are coming faster than, um, than we all imagine. And I do believe that DevOps and, and CI/CD as we know it, will be replaced with MMCP servers.

So that, right now, today, if somebody, uh, is using cube costs from IBM, they could connect it into their DevOps pipeline. So for every time a container gets pushed out, that version of that container, the cost of it is being associated right to the DevOps pipeline. It will happen, but we can't do it right now with our technology.

And it's not that we don't want to, it's just not possible. It literally is almost impossible to manually update all of these scripts. It cannot be done anymore.

Plugins were, are, are a huge, huge problem in the DevOps world. And to try to build a plugin for, uh, every time you wanna manage something or add more accountability like an SBO m or trying to track the cost of a container, and it's, and it's test or production environments, it's not, it's not possible to do. So it's not that we don't want to, it's so we don't have good tooling right now to allow us to be that agile ourselves.

We've been, we've been supporting agile development, but we are not agile DevOps engineers. Our, our DevOps pipelines are not agile. So I want to see this happen, and I will, I, I do believe that it will be, um, plugins will be replaced with the MCP servers, and we'll have context windows that will connect the pipelines and we'll have workflows that AI is managing.

And then we can say, I'm gonna add, I'm gonna add cube cost to my pipeline and it's not gonna impact my pipeline. I'm not gonna, I'm not gonna take a chance of breaking my pipeline by adding this one particular connection. I think we may be too much in the dirt here with, with this discussion.

So what I mean by that is, look, I I, I don't disagree with anything you just said, Tracy, but at the end of the day, if I add a component, whether it's a, you know, a, a a cloud component, a local component, and you know, a bunch of code, what I really wanna know from a finops, uh, uh, uh, view is how does that affect my entire business? It's not just it anymore, right? If I add a component, does that increase my sales?

Does that reduce my sales? Does it make my people more productive? Does it make them less productive?

I'm not talking just about the dev folks, the DevOps folks, 'cause they're certainly, that's important and, and managing that cost is important, but you really wanna look at it from a, a more holistic viewpoint and, and just tracing, uh, you know, the Kubernetes components isn't enough. It's how does that o overall affect my business? That's a really hard problem to solve, but that's where the real benefit would come to most organizations.

In the meantime, we're gonna get a bunch of AI agents that are wagging their fingers at us every time we overspend. Right, Right, right, right. Or just turn off your machine, you know, the agent should come in and say, sorry, and the, the quarter you put in the slot, you know that, that time is over.

Can't use it anymore. Something to be said there. All right.

Hey, let's take a break on this one, guys. I think we've, we've kind of covered it all. We, we'll take a break here on the gang.

We'll come back and let's go to our C blocks. You're watching Text Trunk Gang. Join Cruise Con Virtual on June 17th in 2025 for breakthrough strategies to address advanced threat intelligence, proactive incident response, exclusive bonus material and regulatory adaptation here from our keynote speaker, Admiral Michael S.

Rogers, former director of the National Security Agency, and an outstanding lineup of industry experts as they navigate emerging threats, the core principles of crisis management and the evolution of CISO Leadership. Register now for free. Alright, we're back in.

We're gonna talk about something that matters to everybody. It's called money and salaries. And once you get paid for your job, and we have a pair of posts.

com, talking about, on average, the DevOps engineers are making about 140 KA year. Now, that varies widely depending on where you are in the country and what kind of job you have. So the average is just that, an average.

com talking about how well platform engineers are making more than your average DevOps engineer. And maybe this is the new job title to get and go after and have. And, um, this whole space seems to be evolving.

Alan, I know you cover this space closely, but what do you think's going on here in terms of the hierarchy of IT folks and who makes what? You know, it's interesting. org site, which is a huge community site.

Yes, platform engineers is the platform engineer is a new hot title, and people are paying a premium for it. DevOps engineer. And whether you believe that that's the right title or not, but DevOps engineers have had surprisingly great staying power making also around one 40.

There's not a huge gap between the platform engineer, and I think that was one 50 maybe. Um, I, I think the, the, the fate look, they're both pretty well compensated positions. I think the bigger issue is how many openings are there for platform engineers?

How many openings are there for DevOps engineers? The interesting thing about platform engineers, it's a new title with an old job, right? We used to call these people CIS admins.

We used to, you know what I mean? They, they, uh, be it ever, no matter how it smells, it would still smell well, no matter how it looks, would it still smell is sweet? Or whatever the right Shakespeare quote is there about roses.

Uh, you know, we put a new title on 'em and we pay 'em a little bit more money. The bottom line is tech engineering roles are in demand still. AI hasn't quite replaced them all just yet.

Uh, I think it, you know, you're gonna have ups and downs and waves depending what's in vogue. And certainly platform engineering's in vogue right now, but I I, I don't think there's a big gap there. I think the bigger issue is how many openings are there for these roles and can people get those jobs?

I know a lot of my friends, not only in the DevOps and the platform engineering space, but especially in the cyber space, which has also been traditionally a full employed kind of vertical. A lot of my friends are having hard times finding jobs. Stacy, I, I know you've dealt with this and a lot of your friends have as well, no matter what they're paying, are there enough jobs out there?

I mean, we're told there's all these openings, but yet who are, it's taking people eight, nine months to find a job. Yeah, Well, and some of that is, is what the companies are going through. What's the hiring process?

You know, this is it. What are the perks around it too? This in-office work?

Do they have to come into the office to work? That's, that's one that's, uh, strong, is finding the jobs that are a right match out there for people. And there are jobs out there, but really it's like you have to know someone.

You have to apply over and over again, and it becomes really disheartening for people. So there are the jobs out there, but it's, they're just really hard to find. And then to make yourself stand out as a candidate and to make sure that you're getting your needs filled, whether it's being in office or working at home.

I see the working from home piece that comes up more often than not with these, with companies being asked to bring people back in, whether they need to or not, because especially I think for developers and engineers, they can do most of the work from home. And so people will sometimes turn down opportunities. The opportunities may be there, but if it's not fitting either their work life balance or the, the needs that they have in their day-to-day life, then they're not being considered or they're being considered, and then the wrong people get put into them and they come up again causing churn and causing issues internally.

So the, the jobs are out there, it's just, it's hard finding fit and it's hard standing out. I think there's another component to this as well, EE especially in the discussion we just had around, you know, platform engineering versus, you know, cis admins versus, uh, you know, developers. And that is the whole notion of presence.

Do I have to be there, um, to your point, Stacy, but to one more. I I think there's, again, another component to this, and that is, so that for DevOps, for instance, if I've got software to develop, I, I can, you know, farm that out to some group in, in India that'll work for a quarter of the, the cost and, and still give me my software platform. Engineering is a little different because you really do need to be on onsite.

You need to be present, you need to see what's going on from the hardware perspective, the networking perspective, the integrations perspective. And so, uh, and, and that's, that's also reflected in the salaries, uh, because if there's more competition, salaries go down, right? Uh, it's, it's, you know, it's just normal economics.

So it's a, it's a pretty interesting discussion, um, about what does it really mean that there are jobs available but people aren't getting hired? A lot of that I think is, is a discussion around do I outsource it or do I actually hire somebody here in the states? You know, the pol political ramifications that we're going through right now aside, I think that's still a major discussion in a lot of companies that I see having that, that, that that thought process going through.

And it takes some time for them to, to get through it. So the, there's another human factor here. I'd just like to mention both these types of jobs, DevOps engineers, and even more so for platform engineers, have a level of stress that can be not so fun because I've sat in these, both of these jobs and, you know, the whole term platform engineering, um, is the idea of bringing into the DevOps process or bringing DevOps more into creating these, um, self-service environments.

So development teams can get onboarded quick more quickly and many other things. How, how to better streamline your production environments. It's kind of an expansion of the site reliability engineer role in my opinion.

But when you're talking about DevOps, this is an important role. It's compiling and making sure it's, it is building and deploying very, it can be very stressful, it can be very hard, it can be, it can be frustrating. And platform engineering even goes farther into managing these live environments.

And our live environments are becoming more and more complex. So in terms of these two jobs, uh, it doesn't surprise me that you can, that they're, that people are hiring people and more remote, uh, situations. It doesn't surprise me that the salaries are sitting.

I think that it showed between 140 and 200,000. 'cause they're critical jobs and they are stressful different from a software developer. So if you're, if you're out there looking for work, there are jobs out there.

But one of the other problems that we're having right now as an industry is many dev, many companies and the Arties community have just been doing this job seeker, uh, series. Many companies rely on LinkedIn now to do their hiring. They use LinkedIn as a primary platform and software developers, platform engineers and DevOp DevOps engineers.

Were not storytellers. And your LinkedIn profile has to have a story. You have to look interesting, you have to get noticed.

This is a real problem for, for, for engineering types. We're we don't do that. We're very dry.

We wanna put some five bullet points out there and leave it at that. And they're all acronyms. So if you are out looking for a job, look to services that help you create and build your LinkedIn profile.

It's not just about your resume anymore. Make sure you have references, because every single person that's listening here, that's been in this industry and is looking for work today have, have people they know they've worked with. Get you references up, make sure you have something that pops on your, on your banner.

It is a silly thing to ask for somebody super technical and has been solving problems for big companies for years and years and years, but it doesn't work to have a list of acronyms. So that is my big push for you today is spend some money on your LinkedIn profile if you're struggling with, uh, uh, finding work. Yeah, no, I mean, you know, good advice, Tracy.

I, I, I will tell you, I'm of an age where, you know, it was always the, uh, headhunters who would call you up or the exec, you know, search people would say, Hey, you're interested in, I've got this great position, blah, blah, blah, blah. Or if I was looking to hire a a for a position, I'd go out and find someone who's gonna go find and, and it's expensive proposition. Well, that's been totally replaced I think today with the LinkedIns of the world.

But, but as you said, not everyone is that savvy to sell themselves on LinkedIn. And, and you know, there's probably, there should be a course, there probably is a course on that somewhere, Stacy. Yeah, there's lots of people it that, um, that specialize.

Even just helping people with their LinkedIn profiles. I, I struggle with it. I'm not a big poster, you know, online or, you know, I don't post to my socials very much.

My presence is difficult. And I was submitting for a, a publicly, well, how many followers do you have on, on Twitter? Sorry, I can't call it X, but still X Twitter, whatever.

But how many followers do you have? And I thought, well, what about the content of the proposal? No, it's about my followers.

It was all about social media presence. I said, that's not me though. I'm not out there spewing information and posting everything.

And so I had to kind of think about that. Like, how do I, you know, who am I? And, and I'm not somebody who's comfortable just posting every day and putting myself out there, but I watch the people who do, and, and they do, they get noticed.

So you have to be strategic about it. And I, I love that advice. It's like, how do you put yourself out there in a way that strategic stays noticed, but also you're posting something that's meaningful or you're designing your, uh, your own profile in a way that's meaningful, has the information, has the titles, it has the recommendations in a way that, uh, doesn't seem too cumbersome and represents who you are.

And yeah, there are companies, there are people that can help you through that. And it is worthwhile to get it. 'cause there are, there's little tricks to it.

There's little ways to put things in there that can be more effective. Uh, and it becomes back to that networking and to people know that you're available and what you're looking for and who you are so that you stay in someone's mind when, when something comes up. Oh, I know, you know, somebody that, that can, that does, does this, you know, DevOps or platform engineering.

I know somebody or I've seen their posts. Yeah, and just a tip on that. One of the recruiters said, or actually two of them agreed, don't put open to work on your, on your LinkedIn profile.

That was one of those little tricks that I went, really? I know, I know. And most of the people who were on this webinar that were looking for work had had that listed, had they were posted that they were open to work.

So don't do that because then it, it, it, it turns off the, uh, the recruiter, they won't even, they'll just bypass you. So student, I mean, who's to say who's, what is my question? It's like, so I'm a DevOps engineer and somebody posts a job for a platform engineer.

I'm like, sure, I'm a platform engineer who's to say I'm not? I think you gotta look at what the, the requirements for the job bar. And, and that brings up something else.

You know, I love when you, you know, looking for a platform engineer with 12 years experience. Well, you know, platform engineering's been a thing for three. Um, so, and we had this with DevOps too early on.

DevOps engineers 10 years experience. Well, DevOps has only been around five. Uh oh, and by the way, you have to have a PhD and two master's would be next.

Um, there's a bigger problem in our tech space. We see it in cybersecurity as well. Uh, you know, does experience trump education?

Are we being realistic in what the prereqs for a particular job are? What happened to just strong oral and written language skills? Right?

I I still think that's communication skills is very, very important. Uh, if you're teachable and coachable, I, I can make you anything just about, so I, I then my 2 cents right there, A lot of companies are dealing with recruiters too, who may not be necessarily technical. And so coming your point on, it's like if there's a checklist of things that I'm looking for, okay, yes, there we go.

That checklist, the, the degree that checklist, and sometimes that's what recruiters are looking at. They don't necessarily understand the nuances of what the actual hiring manager may need, though. They work their best to do that.

And a lot of the, if you're just applying for jobs off of websites, you get lost in the batch. Like when I've hired for roles within three days, I had over 300 applicants and there could have been the most amazing applicants in that pool. I didn't have the time to really look and go through them, and quite honestly needed the recruiters so much.

So that's also an upfield battle with some of these highly technical roles that are also nuanced in ways that the front door doesn't recognize. I, I would just say we're all great communicators now. We have chat GPT, right?

Exactly. Exactly. All right.

On that note, let's end this. Um, guys, great discussion today. Tracy, Stacy, Jack, thank you so much, Mike, as always, thank you.

I hope you've enjoyed, this is a great way to kick off your Monday. As usual, we have a full text on TV lineup immediately following today's show, so stay tuned for that. com.

Um, you can also download it on iOS, Google Play, Amazon Fire, apple tv, Roku, or what have you, or on YouTube, maybe a text on tv. But no matter how you watch it, thank you for watching it. We'll be back tomorrow with more gang.

But for now, this is Alan Shimel. We're out.