TCG070: The Effort Illusion: Why AI Tools Reward Expertise, Not Shortcuts

Hello, and welcome to another episode of the Cloud Gambit.

I just got to ask of on, how are you doing and how are you dealing with all the rain

that we're getting?

It's just the only thing I can think of right now.

You know, it's been a little wet, and today it's mostly windy.

Yesterday it was the worst, which is like 38 and raining, which to me is like the worst possible weather.

So today it's just been super windy, but I'm game for anything that means spring is on the way, frankly.

Yeah, I made the mistake.

I thought this area of grass flash stirred around our mailbox was, you know, solid and everything.

And I went to step on it and I kind of just soaked into this nice, a little bit of mud

about a few inches deep messed up one of my favorite sets of shoes, but that's okay.

You can always clear it up.

So this episode, so we've kind of been on this tear lately about, you know, agents are taken up all the hype.

Bay, IMCP, it's high, high, pipe machine everywhere you look.

And there, there seems to be, I'm going to try and frame this the best way I can.

So there's kind of like a split in tech in our circles right now, where you have like one side that's,

you've got folks claiming that AI writes this production stuff, you know, they just stepped away

briefly to get coffee and do the laundry and they come back and it's like, hey, we got to start up.

Let's roll.

And then this other side of the coin, everything's slopped, everything the AI touches,

slopped it, slopped that, everything's slopped, slopped, slopped.

You know, and if you've worked in technology for longer than

Chad GPT's been around, you kind of get to see these trends of like usually,

there's, it's somewhere in the middle is where the kind of the truth shakes out

between these crazy extremes.

And it's, you know, honestly, that area right now to me is even more interesting than either

these camps, I think want to admit.

But today we're going to do our best to dig in to that, maybe that messy middle ground with someone

who's been building with these tools, you know, calling out the hype a little bit on, on socials

and, you know, I think has some real opinions about what actually works and where we actually are.

So welcome to the podcast tank.

How are you doing today?

Good.

Thank you.

Thank you.

Thanks you on.

You know, great getting ready for spring.

Can't wait for spring myself on up here in Boston.

So 38 degrees would actually feel good for me right now considering the temperatures.

And you guys were just buried under a huge snowstorm last week, right?

60 inches, maybe in about a month, and it's been maybe zero degrees or a little bit less.

That's brutal.

Pretty intense.

That is intense.

Yeah, well, again, you know, thanks for joining.

You've got, you've kind of got one of those careers that matches almost sort of my, you know, career

and events career in a sense where you started and I'll just say like infrastructure, like you

went deep in infrastructure.

And then you were a, we're deep in security for a while at Cisco.

And now you're, you know, you kind of pivoted to start up space, browser security.

Do you want to take us through just kind of your, you know, it doesn't have to be exhaustive,

but just a little bit about yourself and a little about your career trajectory?

Yeah, yeah.

So currently I'm head of product at Conceal, where as you mentioned,

it were browser security companies, specifically in the enterprise browser space.

So yeah, it's a vibrant ecosystem with 14 other vendors by now,

only in a few short years and there's a lot of action happening there.

I actually started off as a never-engineer a long, long time ago, like my first job was at a

Nobel netwear slash Unix shop doing old, very old ethernet type things.

And then I can continue that trend with infrastructure through a number of places,

MX Pepsi, you know, kind of places and I end up in AT&T, you know,

of heavy, heavy infrastructure, service provider infrastructure there.

And then I started paving it over to security just because, you know,

I think we're like a lot of us, we just want something new and different.

And there's a lot of, you know, you to realize that there's a lot of

overlapped with security and networking as well, you know,

the network engineer typically also does the firewall and the VPN and some other things.

And so there's a lot of overlapped there as far as infrastructure grows.

So I joined Cisco and at Cisco was part of the CTO team for security business group.

And I had a lot of fun.

We were CTO groups are forward looking teams.

And so we do a lot of emerging technologies.

So I had an opportunity to spot some trends with GTNA in the early days.

I wanted to plant the seed and get people involved in Cisco to get involved with the with ZTA.

And so, you know, fast forward with ZTA is now the architecture that I help build and put forward is part of the product they have today secure access.

But I started seeing some gaps.

And so I looked at enterprise browser for those gaps planted the same seed again.

But to answer your question about startups, I mean, I wanted to do more.

I wanted to go deeper because a lot of incumbent organizations, they typically don't want to interrupt the story.

They're growing and they have billions of dollars invested.

And so if you want to do any kind of disruption, you really have to go to a smaller organization.

That's how I'm ended at Conceal.

Awesome.

What as far as being on the product side always think this is interesting because I think everybody I've ever talked to has some different response.

Of course, but you know, those skills that you sort of curated earlier in your career with like networking and, you know, really hands on technical and those different areas did, did any of those translate to, you know, product leadership in a sense.

So did you have to relearn things?

Absolutely.

I think a lot of us in the network engineering space, we work very closely with customers.

And we're also customers ourselves like before joining Cisco.

I was a customer of Cisco.

And so I can count a number of times this year, many people can, that you look through all of these vendors that you buy from, you say, this is horrible.

I wish it had this.

I wish it had that.

You know, you're the customer, you know, what you want and what's going to fit for your organization.

And so all of those things carry over, especially from a customer standpoint.

I don't think some people don't realize that PMs are better, are very well suited to being customer, very customer focused and being close with the customer.

And so I think all of that transition that I had being a customer myself for a long time and then having customers with my own really helped me put the customer hat on as I transitioned and did it into product management.

I love that.

One thing that jumps out too is, I've seen different types of, of course, in work with different types of product, leadership in the past, especially, you know, bigger tech companies and startups.

And usually there's PMs that have like never built anything, they're very organized.

And there's still good PMs too, like I've worked with one recently that's not overly technical.

But this person is extremely organized and knows enough where they can connect all the dots.

But then I've worked with some incredible product leaders that are still building, they're still writing to code.

They're still getting their hands dirty on a day-to-day basis, both in the job and out of the job.

Do you have any thoughts on that?

Like how does being technical, like actually being technical, like not, you know, I've read some hacker news lately, technical change the way you make product decisions.

Well, first I can tell you that both sides of those coin, whether it's a technical PM or a non-technical PM, the common thread is bringing clarity.

A PMs, in the end, the PMs main purpose is to bring clarity to whatever part of the organization or all of the organizations that they're trying to tie together to push a product vision forward.

So whether you're technical or not, I think that's a common thread.

So the technical product managers, I think that they'll fit, you know, the product management is kind of a really broad category.

And you can have go-to-market product managers, you can have business side product managers, technical product managers, and so on.

So I really think that different facets of PM fit into different spaces.

A company like, let's say Cisco or Palo Alto, they have all of those art types, PMs, right?

And a startup, I think that a startup product manager who can actually still write code and build things is more prevalent because technically startups don't usually hire full on PMs.

You see they have an engineer that's like a product-minded engineer that can face customers and has product taste and can think in opinionated software and so on.

And so if you get a great PM that's very technical, I think that feels that same role.

Well, I think one of those important things we have to think about and it's a, sometimes underrated under appreciated skill in the PM.

You mentioned taste, but also it's understanding the customer deeply enough that you can build something that really solves their problem.

Because a lot of times what a customer needs is not as exciting to build or they need a lot of unexciting things to make the exciting thing useful.

And I find that there are times when a tech company will build more for the engineer than for the customer.

And so you've got to have this balance of not only interesting what's technically feasible, but knowing the pieces to build that may not be exciting or sexy, but that are absolutely going to move the needle for the customer.

And I think a lot of times tech companies get that balance wrong and the ones that really take off who are the ones who figure out and strike that right balance between usability, taste and functionality.

Yeah, I think a great PM is someone that gets past what the customer says that they need and gets into the why someone does what they do.

Why does an admin do what they do? Why does the security engineer do what they do?

You kind of get past these layers from get past the customer saying, I need this or I need that.

You try your best to avoid solutioning things right away.

When two engineers get in there, the first thing that they do, they're engineers and they start solutioning.

I can do it this way. I can do it this way. There's 20 different ways to do this.

But a PM, again, bringing it all back to PM main focus is pretty clarity.

You know, it doesn't jump in right to the solution and gets past the layers of what the customer is not with the customer needs, but just much deeper than that.

Yeah, yeah, it's it's a hard balance. You know, I've seen it. It's like, yeah, it's a tough one.

So one thing I wasn't actually going to bring this up, but then I thought, you know what?

It would probably make a lot of sense to the audience.

But let's talk just a hair about the space here in this browser security space.

Because I think it's kind of having a moment right now or through the past few years.

And you know, I think you're, you know, the startup you're with now takes a, you know, obviously a fundamentally different approach from like the traditional proxy models of things.

So for folks who aren't deep in the browser security world, what's, what's like the core idea behind putting, putting security directly in the browser instead of, you know, routing everything through a proxy.

Yeah, absolutely. So core idea is that if you are familiar with secure service edge, should they have a few pillars, data loss prevention, CASB, teaching a, all of that is predicated on getting your packets and getting your data over to their proxy fleet.

So that they can inspect, align some security controls on that months, CASB, DLP, all kinds of things, right?

The, the main idea between putting in in the browsers, you're taking most of the SSE functionality and you're moving that over into the browser where there is visibility.

Because if I am, if I am able to, if I have a service and enterprise browser service that can see into the DOM, then I can stop copy paste where in a traditional SSE service, you would not be able to.

I can prevent file up below and download at the point of the site, or the last inch is what it's sometimes called.

And so essentially, you're, you're not just moving a lot of the cloud security functionality over the browser with us all the visibility, but you're also enabling more areas of data loss and more areas of CASB and so on as well.

Defense in depth.

One of the big industry changes that that's happening that's driving a lot of this is that most apps now are delivered via browser, right?

Like there's the idea of the executable installed package on your end point is just not something that we do as much of anymore between web-based apps.

Cloud apps, all the functionality that you can have in your browser, you know, 15 years ago when we were all doing our diagrams and Vizio, we couldn't have imagined like a browser-based tool like Lucie, where we could build things in a browser.

But ultimately, when you think about the end user experience, nearly all of their apps are in the browser.

And if they aren't yet, they're transition technologies to deliver that app in the browser.

And so then you remove, or you create the ability to be more cross-platform with your endpoint, still secure the critical services that you need to secure.

And that's a huge difference from where we were, you know, years ago, where we were having to install an agent to, you know, an agent to do all the things, right?

Which was a nightmare in and of itself.

And you raise a good point, Yvonne, you know, one of the pillars of enterprise browser is agent reduction.

Because if I can provide you zero-trust access to private applications, if I can provide you the same level of verdict for CASB and DLP in the browser, then why am I sending packets anywhere else?

I could just, I could just have that happen there.

And for us, I can seal our novel approaches instead of having proxies at all, which is traditional for GTA, like E-Scale or some others,

is that we're just using a centralized control plan with a distributed data plan.

So essentially, we create quick tunnels from the endpoint right to the application connector.

We don't have to see anything in that data flow because we already see everything in the browser itself at the last inch. So really exciting.

Well, I was just going to say if you're talking about cost at an enterprise level, right?

If you can use more lightweight devices that don't require the compute intensity that regular PCs or desktops do, and then we used to burn how much of that compute capability within agents to secure and manage those devices, right?

You completely shift the paradigm and you lower the cost and improve manageability across your entire fleet. So it's, it's a big deal.

Hands down. Thanks for that. Thanks for that overview.

And I guess we got to get to the topics we were going to, yeah.

So I think what I actually like, I've been kind of interacting with you a little bit on LinkedIn and we've been talking about some of the, just some of the hot takes and different things that we see online and you've had some pretty awesome responses to some of these.

I think the first one, the first one I wanted to cover was the Spotify one.

So Spotify made, you know, they were making ripples and headlines, et cetera.

Recently, because they're basically claiming they're afraid exactly how it was framed, but basically their best developers haven't written code sense.

Lunch, right?

Yeah, like December or something. All thanks to AI, you know, you know, and that they got a lot of reactions.

Like if the point of that was to get, yeah.

So when, when you saw this headline, first of all, like, what was your reaction and what is, what is real there and like kind of like what is corporate messaging or is there a distinction?

I, you know, those, whenever I see those headlines and I, you know, I like set posting them about them because, you know, like a lot of headlines, they're clickbaity, right?

Like, hey, you know, this, this team has been written code in months and it could be true.

But I think that the reality is what, what doesn't get talked about a lot is that they're not saying that this is an easy button.

And those, those engineers that are obviously still well employed have a tremendous amount of domain expertise.

And so what they're doing, if they're writing less code, what they're doing instead is they're planning, planning, planning, planning and planning and then searing and adjusting and looking for things that are going wrong.

And because they have so much domain expertise, they're able to see where and when things go wrong.

That's a good, so you kind of made the distinction.

And I think this is the, I think this is the right one. I'd love to get your thoughts on this to have gone.

But there's, like what you're basically saying is there's a distinction between, you know, we have our best engineers and it's just not writing code.

They're just letting you run the thing. And then, yeah, we have our engineers and they're using AI to write better code faster using their domain expertise.

Is that kind of the skinny of it?

Okay.

What are you talking about?

Well, and there's, there's a fascinating article that I'll show you the link to it.

And there's been more talk in the industry now about how AI doesn't actually reduce work.

It just increases the velocity and the intensity. And there are now actually concerns about people building with AI that is actually going to increase burnout because the speed of,

of production has increased the point where people don't exactly have the capacity for it.

I know last week I was in a team meeting and I used the word frenetic when talking about how so many people interact around AI.

It's like they get, they get ramped up and they get in this gear where it's, it's, they're almost overstimulated and overstimulating.

And I think like we've not figured out the right meter yet for working with AI.

And I think it, yeah, it's powerful and know those engineers.

And frankly, your most senior developers often write the least code.

Anyways, they're writing specs.

They're overseeing other developers.

They're doing architectures.

They're doing code reviews.

You know, so we also have to like, what's our base right here?

You know, and so a lot of times they're, they're managing those systems.

But Hank's exactly right that they have domain expertise that they're bringing to bear.

And AI doesn't just do its thing without proper guidance and instruction.

Right. And bringing clarity too.

You know, one of the things I can add is that it's, it's not only just, you know, some people with domain expertise, but it's also involves people that can speak with clarity.

If you're someone that maybe you can't write in a specific coding language or something like that, but you are very crisp in knowing exactly what you want and how all the legos fit together.

And in what order those legos fit together and you can piece them together, then you, you can talk to your coding agent and that they can help you with a plan.

So there's another side of that to domain knowledge, but also being very crisp on what you want.

Yeah. There's a lot of, there's a lot of research and just kind of like evaluating the, the extent of how much you give to an LLM and what it will produce.

And like, there was a, somebody a researcher from Stanford, I believe, that was talking through how like the right thing to do is if you can't take that spec and that requirement and hand it to a human, and they can't produce what you want, and the AI is not going to be able to produce what you want.

You know, pretty, pretty clear.

This kind of like leads into the next thing I wanted to talk about, which was actually, it's in very nicely, but Kelsey Hightower, who we all know and love, been around forever, just been just a huge example in the industry and he's done so much.

He's the old standard, I would say, of distinguished engineers.

Yeah, he is the, the distinguished engineer.

But he had a post on LinkedIn, and I, again, I forget how it was framed, but something like,

Jin Aai is kind of like a slot machine as a default, like this is it's, you know, default behavior, you have to actually put in a little work.

Imagine that quality in, get your quality out, and then you replied with,

isn't, shouldn't that be the standard? Like, why shouldn't something require work?

Yeah, why shouldn't something be hard, right? Why shouldn't something be difficult and take a lot of work?

I think it's worth something along the lines what I said.

And I think if you look a lot of out there, what's in the hype is that people act like they one-shotted, they basically wrote a few sentences and they got a billion dollar company.

But what I've seen in reality is that they're, you know, that someone's built the 100th to do out in a one shot or they replicated catchress.

And those are, that's cool things for someone at different technical level.

That's probably a lot of fun.

Oh, look, I replicated my favorite game or this or that and a few lines and that's awesome.

But to your point, my comment and Kelsey is, you know, that you still have to put in the hard work.

There's not an easy button. There's not a slot machine waiting for you. You could just turn out, turn out things constantly.

Yeah, I think that's created a problem too. Like, there's all everybody wants to be a Kelsey Hightower.

They want to be like an influencer. So they're doing everything they can to word and craft.

And they're probably using all of them to craft these things in the most clickbait, you know, way that they possibly can.

And when you look at actually the reality and kind of like what I wanted to get to, but this is like, is it, do you think that this is like a slop problem in AI or is it a people problem?

I think that AI just allows things that have always happened in technology to just happen faster.

You've had code, you have code that comes from humans. That's amazing. But you also have slop code that comes from humans.

You know, you have one engineer being a code from someone from five years ago. Oh my gosh, what the hell is this?

And I think the AI just allows that to happen faster and just with more people in many cases with a lot less domain expertise.

And so I think that this no matter where the hype is, it's always true. You know, bad data in is bad data out sloping is slop out for AI and same thing with humans.

If you, if you, if you're planning and your architecture at poor or non-existent, then your network infrastructure on the other end is going to be poor as well.

And we, you know, we have things like the Pareto principle or what people understand is the 80 20 rule, right? Like 20% of people do 80% of the work.

And that's because 20% of the people are your most capable folks. And I don't think that reality is going to change.

What may change is like you may have 20% of the people doing a significantly higher percentage of the work because AI is a forced multiplier, right?

But, but you have to know not only what you want to produce, but how to interact with the system in a way to get it to do what you want.

And if you're not careful, if you use those tools poorly, you're just going to create more debt. You know, we've always talked about technical debt in our world.

And if, if what you create is subpar, then that's going to be something you have to come back and deal with later. And so I think, you know, we're still just trying to figure out the boundaries of these tools and how best to use them.

But I don't think we're going to get to a point where it's like, oh, we've got one person and that one person can do the work of 100 people.

And like nobody else is, there's not going to be anything else for anybody to do. I just, I just don't think history bears that out. And I think we are just going to be more productive with what we've got.

Right. And that brings back to your point about the stress of, you know, even more work instead of less.

And I think part of that is because people who had projects, they didn't start and didn't want to start for a long time, they suddenly able to do it.

I mean, I haven't projects in ever. And I'm actually completing them. And that adds to my increased work, I guess you could say.

Yeah. And all the little things too, I think for folks that have managed infrastructure or done like DevOps, built pipelines and stuff.

Or man, like even knowing and understanding get to the fundamental level, it's like you under, you see like a lot of projects that are coming out of the woodwork and you go and learn like the way that they're building PRs make like no sense.

The way that things are getting organized makes like no sense. I mean, you have like 20 features, ham jammed into like one PR, like there, it's just bad, bad software, like development hygiene.

And that does well.

And while you take that down a year and even the LLM is going to have to go through and figure it out like what was what was going on here, what did we do things this way?

Of course, it's not going to say that it's just going to try and find whatever it is that you're looking for.

But yeah, I mean, all those little things still end up being very important. And you can use AI to actually help drive some of those things.

But it doesn't mean like all the little things, all those little details end up being very important to the outcome that you're trying to get to.

Absolutely.

And I guess on the other side of the coin.

So talking, you know, Kelsey Hightower is just incredibly practical and incredibly like principled with how he thinks through problems and describes problems.

He's still writing code and he's drawing a lot of distinctions.

Like really, I wouldn't say that he's all the way on one side or another. I'd say he's like more on the practical side.

What is reality? But when you get to one of the extremes, I'm going to bring up the Matt Schumer, something big is going or something big is happening or whatever it was.

And he's like, that's where I brought the example of like, hey, I'm plugging in these instructions and I'm going to go get coffee and I'm going to come back and I got this beautiful thing coming up.

And, you know, he's, you go through and you read that article and there's actually some things in that article that I think are actually spot on.

But there's also quite a bit of it that I mean, even like the fortune came back and said his assumptions are kind of like fundamentally flawed in a sense.

Yeah.

But where do you land on this one? Is he describing the future or is he kind of like selling fantasy because he is a tech CEO in their hand?

I think that the articles like that. And even, you know, you mentioned Kelsey Hightower and where he stands to are incredibly nuanced.

I mean, you said it yourself, this, you know, the article has some great points in it. And it also has some points that seem a little too overhyped and nonsensical.

And I think people love predicting the future, but rarely are it will be grounded enough to actually have a directionally accurate vision.

If you're, you know, all the way on completely on the hype side, then you're not really it's you're less likely to be grounded in reality.

You can still make some great points.

I think great technologists are able to look at an article like that and say, okay, there's a couple good points and here's a couple bad points.

And I think that the people on the either side, they will only see only all this side or only all that side out of the article.

You know, people will be like, no, no, no, everything is bad. This is terrible. We should burn down the AI coding agents. We should never use them again. And then somebody else going, yes, soon, I will be liaising about it came in islands on the beach and hitting the easy button and just, you know, I'm going to build a billion dollar company.

I'll be honest, though, that seems pretty boring and purposeless.

Yeah, absolutely. Yeah, because the journey, there was a quote by some someone I can't remember, it might have been Churchill, maybe, but something about the journey being part of the value or the journey, you know, it's all about the journey essentially.

I totally like about the destination or you're right. Yeah. And I totally, I do like my one of my hobbies outside of tech, because I just need to get disconnected and get hands on is like to build things. I have like a shop and I do what working and I love building like I'm working on something right now been working on for a few weeks here and there.

And I love building it when it's done, not that I don't care about it, but it's just like here you guys son or you know, to my wife or whoever.

And but the good part for me was like putting all that together and there's something valuable about that journey and enjoying and going back to your career to actually enjoy the principles and the work of what you do for the industry that you're in, you know, just slapping something on AI doesn't make it.

You know, isn't going to make it more enjoyable or less enjoyable.

Yeah, I mean, you know, even in some, but I, you know, in a few of my own projects, I, I've called out in a few messages where I've said, wow, I'm glad I'm watching that I'm glad I'm steering things because it would go off the rails on a feature or some little function.

And I'd have to say, well, I'm glad I caught that stop it and say, no, no, you should be doing this instead.

So I always find it odd when someone's like, I've had my agents running for three days.

You can plan forever, but you'll never capture all the inevitabilities in that plan.

Yeah.

I have a quick question for both of you.

What's the most, do you have any like dangerous assumptions that you think people are making about AI productivity right now?

Dangerous.

What, what I was thinking is that the thing that articles like the match humor article overlook is the importance of people and hierarchy and compliance and large enterprise organizations and those organizations are not built and structured primarily as technology organizations.

Like we like to talk about how every company's a tech company and that was the phrase a while back.

But companies exist for more than consuming and executing technology.

And I think because so many of the folks in this industry are so tech focused, they have on blinders about what real work is like and what real enterprises are like.

And how hard it is to change entrenched systems and processes.

And it's not that those things I don't think will change over time.

I believe that they will.

And I think there will be some instances where you have an entirely new types of industries birthed and old ones die.

I think like that's a life cycle that we're going to see accelerated.

At the same time.

A lot of these big organizations exist in the current form for a reason.

And you can't just rip all that out and have them continue to function and meet their objectives.

And so I think that there's a hubris around that.

And it's also a strange kind of naive tale around how our big organizations actually function and what they exist to do.

And I think that's a big thing that a lot of our folks in the epicenter of this conversation about AI.

Just completely it's not even on the radar.

But that exists in the real world.

Yeah.

That's a bad one.

I agree.

I take it maybe a little step further as I think that people who are very, very tech focused.

Sometimes they forget that much of the world is very on tech focused.

They just, you know, just give me the EXE is a phrase that I've heard used before.

They just, they want the outcome.

And in some of the hype that you hear, it is almost as if my Nana is going to build her to do out for herself using AI coding tools.

And I think that there's a heavy disconnect at least for now, at least for a while, where what tech thinks is going to happen for seven billion people is very disconnected.

You know, it'll happen in tech circles at different levels.

You can see it all the folks open claw and all kinds of things that are out there and that, you know, the heavily used.

And if you go on Twitter, you think that that's all everyone everywhere is using.

So this is a great bubble bear.

Well, I think there's a real opportunity for folks who are AI aware, who also understand a user base or an industry to build a thing that's actually useful.

Because right now, we're nowhere near getting close to that because there are things that are incredibly useful.

And I think about things like a full self-driving, what's going on with Waymo?

I mean, there, you know, there's some really phenomenal technologies that 10 to 15 years ago, like even five years ago, we didn't know if we'd ever get to full self-driving.

Right. And we're still all the way there, but man, have we made progress? Right.

There's a huge opportunity for people who can map, like I said, a user group and a use case, using AI and creating a whole solution that works for grandma, for the school teacher.

For we lose sight of even how tech illiterate a lot of college educated professionals are.

And I've got plenty of examples of this, right, from my personal life.

But, you know, it's like trying to explain to somebody how bill pay works, right.

A college educated person struggles to understand how their bank bill pay works and then how it's going to impact their bank balance in the timing of that, right.

Those folks need solutions that just work that don't require deep cognitive understanding from a technology mindset.

And we are nowhere near there yet with AI. I think we'll get there, but I think there's more path to fraud than what the hype is telling us right now.

Yeah. I mean, where I think we're like early PC days, like how the early PC days was I make reference to Pentium before, but even just the whole thing about early PC days.

I think if you take away technical versus non technical people, I think if you can do systems thinking, logical thinking, like that, whether you're a technical person or not, I think that those are the people that are going to win.

Now, I equate that to Legos, not technical and non people alike, they've built some amazing things with Legos, all drivable cars and all kinds of stuff.

And we wouldn't think of these dangers, technical people as technical people. And I think that people can think like that are the ones that are going to win out.

I love that. That actually, so I think I don't know if this is you or not, but I'm going to bring it up anyway.

I think you had made a prediction or just kind of a take on folks hiding behind like process. I think like in curious, like media arc or see like.

Yeah, I did. I made a lot of comments, got a lot of thoughts on the media.

What does that look like in practice? Like can you explain that a little because I thought that was interesting. And it kind of it's an angle that I hadn't really thought about.

I'm trying, I'm actually, I'm trying to remember the specific post it was about.

I think it was like something of the effect of for folks who never had the depths of the trade or the curiosity, but they're like in a big process door, you know, back to kind of what we were talking about with a processed big organization.

They can kind of hide behind those processes and not, you know, just kind of like go on with the current things, right?

Yeah. So if people who are uncurious, I think that those are the, you know, you could say that curiosity is feeding a lot of the hype.

But I think that it's the curiosity that's going to get us to these better places that we're thinking about that are down the road.

And the ones that are, you know, way on the other side, this is all bad and doom and gloom and everything.

Those are the ones that, you know, they're, they're very uncurious people and they'll use any process or pain point that they can to tie behind.

And, you know, use that as, you know, hold something up and say, we, you know, we don't need to progress any further because the customer obviously doesn't want this or it's too hard or this isn't, you know, this is the direction that we should go.

And I think that that sentiment's going to take down a few organizations along the way if we're not careful.

And that's always been the case with transformation technologies. I mean, if you've worked with organizations who are doing, you know, the buzzword for what the past five, six years has been digital transformation.

You're working with organizations that are trying to update the processes, introduce new technologies, change the way that they do things like that.

There is always a contingent of people, you know, 30% that are going to be your, your Lager, your late adopters, things like that that are, that are going to have to be shown the way.

And that, that always exists, but there's tons of opportunity for folks who want to be on the front end of that curve and not so much the innovators, but it's the early adopters that often win the most.

So they let somebody else go out and do all the deep exploration, go super deep, and then they look at what bubbles to the surface from that, and then they take whatever that is and do very practical things with it.

I think that innovation curve is accelerating, though. And I think like you've got to be dipping your toe in the water and understanding what's out there and what the capabilities are.

But then applying other knowledge that you already have that you cannot get from an LLM to make something that's really meaningful.

Yeah, I think that sums up a lot of our careers. If you think about it, it's that driving curiosity, you might, you know, the beginning about my career and everything. I literally got into tech and network engineering just because someone else does anybody know anything.

And I raised my hand and said, I know some things and I barely knew anything. And then suddenly had this ethernet network with Nobel and I was reading all the docs and everything and just boom, boom, boom.

And that curiosity is basically sums up my entire career. And I'm sure some of yours as well.

Yeah, one of the big, you said something too on, I think, LinkedIn or Twitter about how your network engineering and Linux skills are going to stay relevant. They're not going away.

And this is one that's just so hard for me because it's the only, it's like the main advice I give folks is learn Linux, go learn the CLI, learn the file structure, learn.

You know, you don't have to be a systems admin, but learn your way around a little bit. It's going to help with everything. It's a very valuable skill that just fans across network engineering system at like all these different building pipelines in cloud, whatever it is that you're doing.

I touch Linux every day with this stuff in so many different areas and it's like, okay, what else? I don't know about that. Like what else? Like what about the AI stuff? And like, well, yeah, but Linux is just super important. So do you think what is your idea, like as far as the fundamental skills, like if you could give a new, like a college graduate some advice on what to double down on with time.

And what would you say?

I probably, I think Linux is probably the best skill that I would keep re-upping on and also consider that a lot of what is in and around Linux is networking in itself, people build whole systems and whole proxy fleets to span the globe.

And those are really nothing, nothing more than, you know, thousands of Linux boxes, you know, holding up, holding up SaaS environments.

I, you know, I think earlier on at least in my career, there was a lot of focus around vendor routing and switching and that's still very important. I'm not saying that it's not very important.

But there's also been a long transition there to to Linux systems and Linux networking.

Those networking fundamentals are the same when it comes to protocols and different protocols and how things operate over the wire, but they're just, you know, they're just shifted over to Linux.

It's very hard to have any real domain knowledge and networking today without base level knowledge of Linux systems.

Yeah, so I'm totally with you on that one for sure.

I think we're getting to the top of the hour.

This is, this has been a great conversation.

Are we missing anything of on? Is there anything that we didn't hit?

Oh, there's always more to talk about.

I think, like, I think the idea that we are going to be a skillless populist in the future is silly.

Like, you know, they may be different skills.

Yeah, right.

They there will still be skills and there will be things to learn.

And I think I'm just going to double down on what Hank was saying about curiosity to learn into curiosity.

And now, and there are times when it's more important than others.

And this is one of those times when it's really important.

We're going through a time of geopolitical, economic and technological change.

Like, everything that could be changing is changing right now.

And the best way to approach that is not with fear and not to go hide in a hole, but with curiosity that's trying to figure out how do we solve all these problems.

And I think, I think that is probably a good place to land.

Nice.

I love that.

Where can the folks find you, Hank, if they want to?

I know you have a blog and I know you're on Twitter and LinkedIn.

Yeah, I do you better with my blog.

I think like a lot of people I need to do better and I want to do better.

So my blog that I'm trying to get back to is Hank is a service cloud.

But lately, yeah.

But lately, I've been writing articles to LinkedIn's article service for now.

So I think people you can define me there or on Twitter or X or whatever people want to call it.

Awesome.

I will link those in the show notes.

Thanks so much for being responsive on LinkedIn and coming on and chatting with us about this stuff.

We love the perspective.

Yeah, thank you very much for having me both of you.

Thank you.

Thank you.