73. Agentic AI Spells the End of Dial Twiddlers – Tech Field Day Podcast

Guy's gonna apologize for not apologizing. And he is going to tell us that AI is good for AIing things. Jay would like everything as code, including the entire business.

I'm not sure he wants his weekends as code though. Join me on the Tech Field Day podcast as we discuss with a twiddling all the dials. It's really what your business is about.

Welcome To the Tech Field Day podcast, where we bring together a group of ITE technical experts discussing a single idea around key concepts in the industry. This podcast features a variety of perspectives from members of the Tech Field Day delegate community, and it's often recorded in association with one of our events, our Tech Field Day as part of the RUM group. And this podcast has also published our sister company site, text Strong tv.

On this episode, we'll be discussing the premise that you aren't in the business of twiddling the dials. But before we dive into the discussion, let's see who's on the panel today. And my top is Guy.

Yes. Hi, Al. Um, good to be here.

Guy Courier. I'm a, uh, analyst at Futurum Group and, um, uh, infrastructure and Dial Twiddling is one of the things I cover regularly. And Jay, Hi, I'm Jay Q role.

I'm the Chief Product Officer at N Access Tech, and we twiddle dial so that our clients don't have to happy to be here. And of course, I'm Alistair Kok. I'm an event lead here at Tick Field Day and longtime invent dial twiddler.

I've had my career in, uh, twiddling the dials and then teaching other people how to twiddle the dials on various technologies for the last 20 years. And it does seem like the dial twiddling the depths of the technical knowledge is less valuable than it used to be. That going back to the days back when I used to have here and, uh, long before I was involved in Tech Field day, uh, I would be assembling servers.

I'd be actually putting the CPUs inside the servers when there was an upgrade or adding additional RAM to them and hand delivering those servers into the data centers. Well, here in rural or semi-rural New Zealand, you might be lucky and have a rack. Otherwise it was just a cupboard.

Uh, but I'd be delivering this hardware directly into the customers and going through the entire build out process of installing operating systems and doing all of the migration of their data. And there's a huge amount of very detailed knowledge in there. And yet, as I've progressed through those 20 years since building automation to hide all of the dials, widdling, and then consuming services where somebody else has automatically twiddled the dials for me seems to have been a big thing.

But I've kind of noticed over the last few years that the cloud started off being a very simple thing where you just bought in t-shirt sizes off the rack and has now become pretty complicated with a whole lot of dials to twiddle guy. You also cover dial twiddling. Is there less or is there more dial twiddling?

And is that actually valuable to a business More? And no, it's not valuable. Shall I expand?

Um, so, uh, yeah, yeah, I think, I think one of the things you've identified is, uh, uh, really interesting. And the other thing that you've hinted at is even more interesting. The thing that's really interesting is the dial tool.

Loing has gone upscale, if you like. Um, it's not swapping out subsystems anymore or, or, or CPU or what have you. Um, but, uh, um, there's a fair amount of on the ground operational work that's, uh, done in your average data center right now, let's call it the level below site reliability engineer.

Um, and so maybe that's the floor and it's a higher floor than it used to be. Um, but the other thing that you hinted at, I didn't quite say directly, is that the, um, rectification, the increasing abstraction of services, including really low level services up into cloud-like platforms and orchestration systems, has made it a lot easier to get access to a whole lot more and fine grained dials to Twitter. And so that's really to me, where a lot of operational efficiencies get sacked.

And in fact, I don't think we're really answering the problem now with ai. I think we maybe even are exacerbating the problem in some ways because AI has looked to as this answer to, oh, there's so many dials of Twitter now, it's also complicated. Oh, woe is us.

What are we gonna do? And, you know, incomes management or whatever else say, oh, we're just gonna have an agent do it for you. I don't really think that addresses the problem, but from the standpoint of more dials to twiddle and more dial twiddling going on, absolutely it's exponentially this and it's a problem.

And Jay will explain why. So with that setup, I will tell you a small story. Uh, I'll change all the names to protect the innocent, but, uh, in reviewing a private cloud, I, I did some splunking around, found out that in this situation, uh, the, the client's actually standing it up the old fashioned way.

They, they're home rolling, not their encryption. That'd be awful. Not anyone's ever written that, but they're, they're home rolling their Kubernetes stack.

And because of that, they're, uh, bypassing all the wonders of, uh, insert vendor name, cloud foundation. Uh, they're bypassing all the wonders of blueprints and other available automations that would've simplified their lives, not because they're trying to do it one sprocket at a time if you, and so when I found out this, I realized that's really taking away a lot of what the business is actually requiring of, of them, which is time to market. And so for them putting it together one stick at a time, uh, we're, we're really robbing the future of what the possibilities would've been for them to execute upon that to get those business aligned applications up and running in that environment.

So I think of it just as, what's the time to value? Um, what's the speed of return on the invested capital? And you're investing significant capital, so how can we shorten or lessen that time window to get that return?

So I describe the environment where there's more dials to twiddle, but, uh, uh, a and Jay, um, uh, I wanna, I wanna ask you guys, um, to me there are two reasons for this phenomenon of what that horrifying situation Jay just described of homegrown Kubernetes. One element of it is we want it to be exactly how we want it to be, and off the shelf or even customized or whatever, it's all expense and it comes out to the same dollar amount in the end or whatever. That's not really true, but we'll leave that aside.

And it has to be exactly how we want. That to me is like, let's say the good reason, the good motivation, the bad motivation is the unconscious desire to twiddle vows. It's fun, it's interesting.

I'm gonna loan more. So I'm asking the two of you. Um, sorry, Al, I turned the tables on you.

I'm asking questions. Um, which one, what, what's the mix of those right now in your experience? Because I still feel a whole lot that it's emotion driving it, it's just fun to do.

So we come up with the justifications for, I definitely wouldn't underestimate that social part, that part where it is. I've always twiddled with the novel knobs. Uh, the thing that defines me as a professional is that I have a deep knowledge of where all the knobs are and where to twiddle them.

That absolutely is one of the factors and in overcomplicating systems, and I think that's one to, to face up to and to start to, to view is that the knobs I want to twiddle need to be more abstracted. So they need to be less about the underlying technology and more about how they serve business. And that, I think is the, the kind of message from Jay as well is that there's that time to value and, and that, um, return on investment.

Uh, I mean, this is why we're in business is to, to return some value, right? Uh, I'd add an another complexion to Jay's comment about time to value isn't sufficient. It's also, uh, the sort of return on investment or the return rate on that investment.

And so this is what sometimes leads us into the feeling that we need that perfectly crafted solution that is gonna be the most efficient return on the money we are spending. And there's, there's always this balance of how much you overanalyze getting things perfect and the wasted energy and, and effectively money and time that you spent perfecting something versus the return you get from it. Uh, it really is one of those, those things where there isn't a single answer of, of you should always work with the standardized tool because the standardized tool is cheap to deploy, but it's then more expensive long term to operate maybe for your specialized use case.

But I think there's also a psychological thing. The same thing is that desire to twiddle all the knobs and be the, the expert in the knob twiddling is also the feeling that we're all unique snowflakes. Our business requirements are unique snowflakes.

And so we've gotta build a unique snowflake of an environment or an application to fulfill us and not sure that really fits together very well. Jay, uh, what about, what else, uh, do you see in this at, at different levels within organizations as well? Different skill levels and different, um, management focus as well?

I think there's, there's more of a twiddling knobs as you are lower down towards the technology and, and less interest in the knobs as you move up into more of the executive and business oriented case. I think of it maybe as a slider. So if we started off with the notion of that the very, very lowest of low level, you have a troop, uh, perfectionist twiddling every last knob to its most extent, uh, optimizing, constantly refining, going for it, then you have a practitioner, uh, that's there to maybe get some things done.

Uh, maybe you have a professional, uh, there with a business angle to try to really accomplish what the, what the business is asking for. And then you maybe have like a pian, if that's a word we could use to describe someone that is not only aligned to your earlier point about just the return investment, but the ongoing compounding return from that capital that we deployed. It's now supporting a named application.

We can tie that back to top line revenue. Uh, we understand what the impact is to the bottom line, and they've really taken this down more of a TBM or technology business management perspective. So getting there is the hard part because, uh, as someone who also does love to tinker, uh, I, I do, I do cherish my weekends, the finite amount of time I get to go, go on the console and get things done personally for my own projects, it is, uh, it is a temptation that I fully understand and grasp.

Uh, but at the end of the day, you know, the things that we have to do for the business really require us to put on our pian hat and, and probably put some of that perfectionist hat, uh, away. Uh, was it, uh, uh, perfect as the enemy of progress. I think I've heard that other, uh, term of ps.

So that's what I think about that. Part of the trigger for this conversation was I was talking about my transition from being a very technical person doing building things, building things like my auto lab, you know, infrastructural automation and building solutions to companies, to my current role with Tech Shield Day, where I'm an enabler of people more than anything else. And that sort of feeling of fulfillment from working on the physical building the solutions to, or technical solutions to, to business problems is, uh, the thing that, that goes away is the big, big risk is we bring somebody technical into this role and it, it kind of feels that internal thing of, I, I really do feel internally that, uh, twiddling the knobs, understanding the depths of the technology is a vital thing for me.

But yet, as I was transitioned from teaching on-premises infrastructure to teaching the web and, uh, teaching in particular AWS uh, training courses, was this stuff changes all the time. You're never going to be the most expert, the, even in a single product, you're never going to to be the most expert, let alone across the hundreds of products that are out there. And that's kind of where I see the, the return of the, the knobs twiddling, even in cloud where everything's supposed to be a service and you're just not supposed to care, is assembling together.

All of these pieces feels a little bit like we've abstracted away what we used to care about and now we've made something incredibly detailed to care about that is new and different. Are we actually making any progress in this guy? Or are we just redirecting our knob twiddling energy?

I think that, well, so let me bring AI back into this, um, this time of that. Apologies, I usually apologize. Um, it, so I'll start with this.

Um, I think it's evident that the best users of AI understand how AI works. They might not build models, but they understand the fundamentals of how a model works and whether it's generated generative AI or predictive or whatever it is. Um, they know what, what mechanism is being used and that allows them to use that tool better.

By the same token, that's not so obvious in AI for some reason. Maybe 'cause it's simulative, so it fools you really easily, but it's relatively obvious in other disciplines that those who have practical hands-on experience in it like you do out in dial twiddling, um, can understand better how to direct others and what's important. And that's not important.

So, um, are we just twiddling dials higher up? Um, I don't think that's our goal. I think we wanna continue to abstract further and further, so to speak, not just with technology, but with operations or like culture and how the team works.

But I think that, um, that, so that takes us out of the, the, um, fine-grained operations part of it, but nonetheless, we need to be able to evaluate and understand what's going on. And we need to accept, um, differences in ways to operate, differences in styles, differences in approach, and accept some of them to keep the grand picture in play. And all of that does require a bit of a mi uh, a dial twiddling mindset to, to, to, you know, to put not too fine a point on it.

I don't think you should ever really escape it. But the short answer to your question is, um, that is our goal, especially with the advent of ai to bring it back to that, is to do, do less with, um, tactics and more with policy to set policy. And then to Jay's point earlier, um, we can hobby with the things that give us pleasure and learn through doing, through twiddling those tiles.

I'm getting tired of the word twiddling, but yeah, we can learn that way and make our policy decisions and our guidance more effective whether we are guiding people or ai, sorry to say, or a mix. So I think of this in a couple of different ways. Uh, the first is that being able to know what's going on, whether it's an AI workload or any workload that is new, uh, to an organization, there's a, there's a freeing concept around knowing what's going on.

But I also think that, uh, getting to observability traceability, uh, we, we actually may not have time for everyone to become fully instrumented aware and a PhD and big masks. We may just actually have to use some of the AI ops capabilities that are being shipped by some of these vendors that allow us to plug into our on-premises infrastructure to tell us what we need to know using small language models that know exactly what one needs to know about what's going on in this environment and may not necessarily know who, uh, won the 1985, you know, world Series. Um, uh, those of you who have chat boutique, go figure that out.

But, uh, I think it puts us on a policy as code path as we all aspire to be more businesses code. Um, if, if we, if we don't go down that path, I do feel like we'll really, really be back at the beginning of our conversation where, you know, I'd really like to move forward, but I really don't understand fundamentally what's happening in silicon right now. I don't understand the electrons passing from, you know, point A to point B or statistically point A to point whatever.

I think of it as we, we just have to set aside and trust that these platforms that are available in market right now packaged are gonna help us move faster and, and be better in our business. And to your earlier points about moving or shifting up in the business value conversation, it makes it practitioners, uh, into more pragmatic going forward. That sounds a little over abstract though, Jan.

I mean, when I hear businesses code, I wanna flee. I I don't want to be in the businesses code. Um, I want to be in the, well, you know, I'm, I'm not gonna get all mushy and say, oh, it's about people.

Um, which it is, but I just don't wanna get all mushy about that. But that's, that's not what I was saying. What I was saying was that, um, your, your, your dips and dives and hobbying are really necessary in order to make the, the, the best kinds of higher level decisions and guidance.

And I mean, don't we want our team members to be able to do that? So that, you know, to put to, to, to put AL'S hat on right now, you know, if, if he didn't make it clear, he's, he's now a puppet master orchestrating all kinds of other people to go and do things with tech field day. That's what he does now.

Um, he used to be a real worker and now he's just getting motivating people and coordinating and things like that. But no, but seriously though, um, one of the things that Al can do as a team leader is to enable the team members to similarly be puppet masters for whatever tools that they have, but they can't really do that if they dunno how those tools work. And I feel like you're going a little too far, Jay, in, in terms of trying to abstract out what the teams are trying to accomplish to, to the level of, you know, business guidance as opposed to, you know, serious architectural and operational decisions in the technology.

I, I, I, I get it. I get it. It's, it's high level, but I would also counter that the businesses code would be what are the essential operating KPIs, OKRs that we all agree as a business that we're gonna chase after.

Now, how do I take that, make it real for the amount of infrastructure that we've deployed on premises? Do I know exactly where that capitalist went? What's, what's that mean for I'M business and is it tied back to a metric that matters?

If it is simply like we have the capability, we have the ability, we can do that, we can do anything, I go back to all my BLEs enables possible, permissible, sustainable, repeatable, advisable, and if we're just sticking here in the art of possible, we're never gonna get advisor. And so that, that's my only pushback is if it's not advisable for the business, why are we even going down the path? But I also seed, I, I admit there is some experimentation that makes us all better over time too.

I just, I'm trying to figure out where, where's the balance in this. Um, so that's, that's sort of my retort, And I don't think there's a single balance point. And I think that's one of the things is within a team, you're going to have those different personas, those different roles, and the larger the team, the more diverse the roles are going to be.

There is probably always going to be a role for somebody who has to optimize the thing that is business critical, really expensive and needs some very careful dial control. But there's also gonna be a role for the person who sets very abstracted policies that then filter through, I think, you know, understanding that there isn't a single answer to what level of skills you require, uh, and what skillset do you require is, is really vital here. Um, particularly as we then start to see that there needs to be conflict between some of those roles as well, that there will naturally be a conflict.

And that's something I see in my current role, uh, between the, the different constituents. And, you know, one of the things we, we often think is everything's gonna be harmonious and everything is gonna be beautiful and all, all gonna be rainbows and unicorns. And that that simply isn't the way groups of people work together.

And understanding that is an important part. Yeah, You don't even want that to be the case. That's, that's, you know, we're, we're talking about, um, certain kind of disruption and, and di dis disease and discomfort that, uh, leads to innovation.

And innovation is a word, right? But the idea is that you can gain, uh, uh, greater value the earlier you can move in new directions that are productive. There's moving in new directions that are not productive and the value that gets wasted there.

But, uh, I guess I'm coming around to your point, al, which is, you know, ultimately like here we are, um, we, we need, um, multiple levels and multiple perspectives and that creates, um, an unsettling environment. Environment. But environment as workers, we wanna, we wanna, um, deal with that.

It's silly to say get comfortable with something uncomfortable, but we wanna deal with that and welcome it. Um, and uh, and as, as leaders, uh, we want to both foster it and help everyone, you know, deal with it. And then, then you have more of a virtuous system there.

So, so to get back to dial twiddling, it sounds like we wanna both twi, it's like the Schrodinger's dial twiddling, we wanna do it and we also wanna not do it while at the same time Schrodinger's dial the dial that you are both twiddling and not twiddling at the same time, depending upon whether you observe it afterwards. Yes, there you go. Schrodinger's style.

Oh, that's Great. That's great. And of course, you only know afterwards whether it was worth making that change on the dial because until you no Result the Heisenberg no, that would be the Heisenberg dial Heisenberg style.

So we're coming to the conclusion, I think that it's, it's that uncertainty of, of the dial, the need for all of those dials, all of the knobs and the switches, and that there is definitely going to be a desire for simplicity and a desire for getting to a state where we can just describe the result rather than having to look at every single setting that makes up that result. And that's the, the everything is code, policy is code, infrastructure is code. Um, guy was loathe having a business as code, but now it's a direction to head towards.

Uh, yet there's still a need to get into some of the weeds now and then, and there's a need for people who understand the weeds. I think, uh, we are a long way away from being able to just hand all the reins over to an ai, and that's probably a good thing because the time we hand the reins over to AI completely, it means that these humans are no longer so necessary. Uh, and I think, uh, humans are kind of important to us.

We certainly see far more innovation from that, again, conflict between the people and the, and the humans. Now we're heading towards the, um, heading towards our time. And so I just, lemme give you an opportunity to have one last thought.

Jay, do you have one last thought to add to this conversation? I do think that in terms of the number of nos, we all all have a choice, many more choices now, uh, around the constraints and the affordances. You know, we can procure a product experience, we can get an engineered product experience that has a lot less knobs, uh, because it's been pre tuned, pre optimized, you know, for our safety protection, uh, uh, like the, uh, like the airplane where you have to have to have the dog and the cockpit.

And what's the purpose is to basically, uh, you know, keep the, keep the pilot very, you know, you know, happy during the flight because they don't really do as much. And then, uh, viciously attack them, should they try to, you know, arrest the controls of the plane at any point in time, keep them away from those controls. So, uh, at, at the risk of saying, uh, it's, it's gonna get, uh, less knobs exposed to us over time.

I think the appetite for knobs will actually decrease over time. Um, any, any recent interview you might have done with, uh, uh, level one candidate and your organization to matriculate, uh, they may not have ever put together a pc. They don't know what a board stiffener reason is for a server.

Um, so some of those concepts will, I, I think go the way of people that can identify token ring at a distance, people that know what, uh, different ethernets, uh, interfaces look like. Um, but over time, I think what the product experience will be for infrastructure buyers is much more refined, uh, again, much more of a product engineered experience. And I think that's a good thing.

Um, and I think there will still be, you know, enough dobs and dials and things to twiddle, uh, but, uh, a less less so, um, going forward. That's my perspective on the market. No, no.

Yeah, I guess I think you're right, Jay, but I guess we might wind up reframing what didn't you used to look so much like a bunch of dials as dials now, and there will be, again, that floor will go higher up in terms of what we're doing. I, I, I almost, I almost see it as so, so it occurs to me that a lot of what we deal with, with the people, part of people process technology in, in, in, in, you know, our industry, um, a lot of what we deal with is mindsets that tend towards the more extreme positions. And we've all dealt with this, that passion seemed to run high among the, the, the, you know, um, the, the tech operators and architects and so forth.

There's only one way to do this. I mean, how many times have we heard this? This is the only real way to do it.

All the other ones, you know, we should be able, Alice smiling. He's, he's probably the most recent of us to be like in the room there, um, discussing these things. And, um, maybe the takeaway I'm getting from this is that that tension that we were talking about is something to try to foster a little bit in our, in our industry.

This is one example of it, um, which is you twiddle the dials or do you just, you know, use the platform where, where's the bending point? Um, Jay, I think your guidance, um, in general around ensuring that you make good business decisions and that what level of detail you're getting into in operations and tooling, um, should be based on, you know, where your value point is and what your goals are and all that sort of thing. That's completely correct and it's the sort of thing I say all the time, but I'm also kind of feeling like you can only get out of your team and your organization, what it's able to produce and, and, um, uh, sh shifting what it's able to produce takes a really long time.

So in the meantime, fostering this idea that a tension between what you want to be doing and what you must do and recognizing that and realizing that it's all not, it's not all one or not all the other, that would be a really great thing to see more of in our industry because I think we do tend more towards more extreme statements and positions because that is what we believe in and what seems the most fulfilling to us. Well, thank you all for joining me, particularly Guy and, and Jay, uh, and for this episode of the Tech Field Day podcast. So Guy, you clearly care about these things and want to discuss them more.

Where can people continue the conversation with you? com. Um, you'll also find me at text on TV doing sometimes the podcasts over there or webinars, and of course find me on LinkedIn.

And Jay, where can people connect with you? org. com.

org. Awesome. And of course, I'm Alistair Cook.

com site on Tick Field Day, as well as on Demi Tess nz, which is my own personal much, uh, neglected blog too. Of course, LinkedIn is the place I've been publishing a lot more content. Thank you for listening to this episode of the Tech Field Day podcast.

If you enjoyed the discussion, please subscribe on YouTube or your favorite podcast application so you don't miss a single episode. Do consider giving us a rating in a nice review. com and slash podcast.

We'll find the podcast. Of course, you can always find us on Techstrong tv. Thanks for listening and we will see you next week.