Viktor
00:00:11.319
Yeah. developers do the tools for all the people. It's always a developer, so it's not my people. who made Kubernetes, and I'm not talking about docs, but kind of who wrote Kubernetes? Well, developers, not ops You have to write code those are not my people. Right.
Darin
00:01:34.264
Viktor. How many times have you talked to somebody in an operations team or a, a broader meeting with an operations team and you recommend a tool or a process or something in that line and they say, no, we don't wanna do that. But yet in about two years later, that's the complete industry standard.
Viktor
00:01:51.429
All the time, but here's a kick, because there are teams like that and there are other types of teams and other types of teams don't need me, so I don't speak with them that much.
Darin
00:02:06.850
Right, because it's not a right fit potentially, or they're hardheaded, one or the other.
Viktor
00:02:13.225
yeah. Let's say that you bring in somebody who will, you're the boss, and you bring in somebody who will convince this team to switch to Kubernetes, right? The fact that you're doing that means that that team doesn't want to do it now, if that team wanted to do it. You wouldn't need to bring anybody. They would just do it. I mean, there are other cases that, okay, I can bring a person just for this specific to help us with this specifically, but when the goal is to convince, by definition, you're convincing people who don't wanna be convinced, there is no reason to convince somebody who is already convinced.
Darin
00:02:50.892
and what we're trying to figure out is it's not that ops are bad people. They're not. I was an OP for years and. Loved it, but I was more concerned about just keeping things running and not always bringing in new things because that's how big our team was.
Viktor
00:03:08.132
I feel that describes all the teams, all the teams. Uh, I want to change some things, don't wanna change some other things and are perceived by, by other teams as, as being bottlenecks and they're never a bottleneck.
Darin
00:03:24.849
if we think about it this way, we had mainframes first. We had micros, blah, blah, blah, you know, the whole jump. We had client server, but then we started to actually get into what I call real server things, because up to that point, speaking from an operations perspective, all of that was basically bare metal. Right. Client server was effectively bare metal. The server side was, but then we got virtualization and people would start saying, well, no, we're not gonna be able to, even though we can slice and dice up a server, that's not the best thing to do. We're not gonna get good performance. And then we had containerization come into play, then we had cloud come into play and then. All the variants within the cloud, but then eventually we had Kubernetes that you were just talking about there. And this has been putting pressure on, at the end of the day, it's a server. All of these things are servers except for cloud, right? 'cause if you're, if I'm consuming not somebody working at a hyperscaler, okay, it's a little different. But what, can we, I mean this, this is nothing new. These are just the standard transitions over time. But how can we help ops people like. Can't we just slow down and stop because I gotta go fix somebody's mailbox on the s the exchange server 'cause it's messed up.
Viktor
00:04:38.299
you know, that's the problem. If you slow down and stop, then your house burns, burns down to the ashes. You cannot stop. You need to keep doing whatever you're doing so that your house does not burn down. you cannot stop and really think about this other thing, We are all optimized for just the right amount of people to extinguish small fires, there is a different potential problem, and that's that. We are more likely to accept as human beings things done by our people than some other people. That's how we operate. So if you take application developers, they're more likely to accept, I dunno, some, not just library, library funky stuff that 'cause who, who did it? Well, application developers developed that library. Right? Kind of like they're, they're my people. They know what my problems are, They did this thing and I'm gonna go for it. It's cool. Now, who does the tools for ops? Ops people?
Viktor
00:05:57.421
Yeah. developers do the tools for all the people. It's always a developer, so it's not my people. Who made the who, who made Kubernetes, and I'm not talking about docs, but kind of who wrote Kubernetes? Well, developers, not ops You have to write code that those are not my people. Right.
Viktor
00:06:21.589
Not my people, unless, unless we start thinking of everybody being a developer, and that's where things change a lot. I don't if you notice that most of the time I don't say developer, I say application developer. Mostly to distinguish somehow, and I know that the name is not right, to distinguish from application developer from other types of developers who are, or developers who are specialized in some other types of tools. Maybe platform engineer would be, uh, platform developer, it's a developer. That's the point. And once you start thinking it like that, then. Things change drastically.
Darin
00:07:06.324
Well, wouldn't you say or agree to the fact that usually developers, application developers, or developers in general are usually the bleeding edge of whatever the new thing is compared to every other team around them.
Viktor
00:07:20.349
My personal experience, and I cannot prove it, is that, the developers are more likely to. Change by their own free will than other teams. But now I'm biased. I've been developer most of the time. No matter what I did, I always consider myself developer. So maybe I'm biased, but I feel that other teams like I I've, I feel that we had more. Knows from, let's say DBAs, when there were some changes related to databases then from developers when there were some changes happening. How we develop, and I'm using DBAs as example, right? Applies to almost everything else.
Darin
00:08:05.919
because A DBA has a very specific way of working. In fact, I classify A DBA, known as a developer, but an operations person.
Viktor
00:08:16.659
Yeah, it's just that I feel that everybody should be developer. Everybody should write code. Things change drastically. going back to my Kubernetes example, Kubernetes basically came in a way from SRE in Google. What are SREs to Google in Google? Uh, somebody, I forgot the name, came to Google one day and said, what if we try to solve operational problem as, uh, see operational problems as development problems? That's sre.
Darin
00:08:51.553
What's been one of the things that you've sort of walked away from? It's like, nah, I don't wanna do that. This seems silly, right? We're we've been telling people, talking about people not wanting to do things. What's one that you've said? No, no, thanks.
Viktor
00:09:04.264
I'm not sure that I often say, I don't want to do this. I like playing with stuff with toys. I love it. it could be one hour later or one day, or one week or one month or one year later, she started playing with it. Something saying, no. There are, there are ideas that I think. Are no in my head. Right? And I know that many, for many other people, it's yes. Like VAM could be one example, right? I'm not judging now, vam. I know that many people love it, right? In my head, that's a no. it wasn't no kind of like, I'm not going to touch vam. It's kind of, I spent some time, whatever the time is with vam, I have certain level of understanding, not an expert, and it's a no, but never from the start. You wanna play with a toy, right? have you ever met a child to whom you would say, Hey, I have a new toy for you. No. And it's wrapped, it's in a box, and the child says, no, that never happened. Right? Now the child can open the box, fiddle with a toy for two seconds and say, throw it, throw it behind, right? And say, uh, no. But not without opening the box.
Darin
00:10:14.966
And I think that's where operations comes into play in this is operations, how can I say this? Their rewards are not in line with playing with toys. Their incentives, their rewards are based on stability and not making the CEO sad about being missing something.
Viktor
00:10:39.267
There are two things I don't buy in what you just said first. I don't think that's limited to ops. I think that to some degree or another exists in all different segments. types of teams or whatever you wanna call, call it. Um, second is that everybody has a different excuse, but essentially an excuse. Or explanation, why not? So yes, ops will say this and that because I deal with production. But you think that security folks don't have good enough reason as well. Why this? This is a no. Or other teams like testers, right? Kind of like, we cannot write test code. Kind of like you need a human touch, otherwise you will lose variability, or whatever the the reasons are. Everybody has a reason which is different, and you somehow, and here here's the key aspect, you by belonging in. Whichever team you belong, you somehow think that your reasons are more valid than other people's. Yeah. Kind of like what they say. That's silly. Kind of like that. That's not a good enough reason. Right. But my reasons are valid. My reasons are right. Reasons.
Viktor
00:11:50.157
Yeah, because my reasons are always correct. Other people's reasons are nonsense. Mine. Mine. It's normal. That's, that's, again, that's human.
Darin
00:12:01.447
Welcome to corporate Think. I know you're calling it human Think, but Okay. Yeah, sure you're right. 'cause we're all right all the time. So if we're all right all the time and we're all wrong all the time.
Viktor
00:12:11.145
We are all, for example, not all, but many of us are in some poli or some side of political spectrum, whatever it is, I'm, I'm not going to, but we all think that actually our political beliefs are based on valid reasons why other people's political beliefs are based on wrong reasons, right? I am using that as example, not to start discussing politics, but just the first thing that popped in my mind completely unrelated to corporate something, something we operate like that as as, as people, right? Kind of like, oh, I'm, I'm vegan. I have very good reasons, and kind of like everybody's else's reasons are nonsense.
Darin
00:12:45.985
Speaking of nonsense, who gets blamed when there's downtime for an application operations or developers?
Darin
00:12:56.246
And there was a party thrown for the, for the developers when they shipped that final piece of code, they got their toys, they got their nice little badges and metals and everything else, and operations is dealing with the fallout.
Viktor
00:13:07.741
Yeah, but you're not falling into the same trap. You think that I cannot come up with the reasons, uh, sentence that starts with who gets blamed for dot, dot do. And the answer to that would be some other team who is blamed for us missing the deadline for this feature that was supposed to be delivered on this day, which is extremely important. If you miss that day, then uh, bad things will happen. And then the answer is no, tops.
Viktor
00:13:38.393
What I'm trying to say is that, yeah, going back to what I said before, yeah. Your reasons are more valid. Oh, because I'm production. Right. Kind of as if, as if other people are not, other teams are not blamed equally. One thing I know in corporate environments is that everybody gets blamed equally. It's just that it feels like, like I'm blamed more than others. But I think that the corporations are very, just in that sense, kind of like nobody gets to avoid being blamed.
Darin
00:14:07.667
exactly. Plus you don't get fired or get yelled at for putting in a technology that just works and doesn't break, but you could get chewed out for, Hey, let's go do this new Kubernetes thing.
Viktor
00:14:21.463
First of all, if you don't change the technology, nobody can prove that that change would definitely provide benefits, cause until you do it, you cannot prove it. Definitely. Right? You cannot prove that going cloud from on-prem would result in those benefits unless you actually do it. So not doing it. means that you cannot prove that I'm doing it wrong. if I was right and we move to the cloud, then I will be blamed for moving to the cloud. So kind of either that's a good decision, but you cannot prove it's a good decision or it's a bad decision. And if I do it, somebody will be able to provide information to prove it with data, why that was a bad decision. So I cannot win.
Darin
00:15:10.502
Well, here's another way. You can't win. Let's say you are an ops person and monitoring is a big deal for an operations perspective.
Darin
00:15:17.522
Agreed, but what if there's no way to monitor what the new thing is that's coming in, what do you do?
Darin
00:15:27.937
But I'm an operations person. I can't stop it. I've got six VPs yelling at me to get it in.
Viktor
00:15:33.427
oh. If your primary concern is to have stable production, the best way to accomplish that goal is not to change it in any form of way. No new releases. You cannot make it more stable than not changing anything.
Darin
00:15:50.400
But we have to change things because we have new features coming in. We can't just stop.
Viktor
00:15:54.127
Oh, no, no, no. Of course we can. Or maybe we cannot stop, but we can make it miserably slow. Of course you can. Okay. It's moving. Yeah. I know that eventually we will have a new release, but let's make it three times a year.
Viktor
00:16:13.166
No. No, because that you live in previous century. I'm a person who lives in 2026. Be reasonable three times a year.
Darin
00:16:26.141
Okay. One. No. Fair enough. The other reason why I don't like it as an ops person is I remember six months ago every weekend for six weekends in a row, we had 3:00 AM phone calls and we had to get into the stupid war room.
Viktor
00:16:40.891
And it was always because of those developers who just decided to develop a new feature. If we didn't have that feature, we wouldn't be in that situation, darling. I,
Darin
00:16:54.031
But the developers are gonna say, well, this is what business wanted. And business is
Viktor
00:17:01.771
Yes, yes. But it's not what I said. Right. And I know that that will happen, but as long as I didn't make a decision, I can, I can, I, I can respond to you afterwards with I told you so. So it's not that I think that we will never make new releases. I know we will, but if I say that this is unacceptable, no matter what it is, when it fails. It's your problem.
Darin
00:17:31.193
Speaking of failing, let's, since we are in 2026, company has now put in a new AI system. Fine, whatever. I can't write a runbook for that because it never does the same thing twice. How am I gonna solve for that?
Viktor
00:17:51.808
Pretty sure for a simple reason, because we met in person. I touched you. I know that you're human flesh, so I know that you exist as a person right now. Somebody else, maybe, you know, you could be generated by ai, maybe you don't exist, and then you are perfect. Could be. But in your case, ma'am. No, I know you.
Darin
00:18:16.431
So where's the healthy line between caution and doing nothing? Like where can we actually, we've been poking at each other for a bit here. Where's the right or the right way? Or a right way? 'cause there probably isn't the right way.
Viktor
00:18:35.001
Small chunks. Constant small chunks. The real problem is that. Somehow companies always have those big, grandiose plans, which are going to move everything to AWS. Why, can we move this fund service? Can we maybe develop this new service over and run it there from the start? That's a chunk. That's something I can do. But then no, 'cause it doesn't, you know, when you do a company meeting or. Speak to shareholders or whatever it big plans sounds so much better than, oh, this what we are planning this week, this one thing. That's all. Except that next week will be something else.
Viktor
00:19:26.433
That's next week We are gonna learn something this week as well. This important kind of imagine that. I, I know it sound does not sound something we like doing, but imagine we'll learn something and then we will be better informed next week.
Darin
00:19:42.539
isn't this the basis of how we can just break that pattern, that cycle of finger pointing? It's the Spider-Man meme. Uh, instead of three Spider-Man, there are now thousands and thousands of Spider-Man pointing at each other. obviously breaking it up into smaller chunks helps. When we brought virtualization in, at first it was rough. Then it became normal. We brought cloud in. It was rough. Then it became normal.
Darin
00:20:09.411
I'll say that we brought Kubernetes in. It was rough and it's still becoming normal.
Darin
00:20:16.043
So don't solve it all in one day. Is that one way to think about it too? It's like what is the smallest chunk we can do right now? Even though it doesn't go like much, it gives us the foundation laid for the next step we're gonna take.
Viktor
00:20:28.778
just to be clear, you need both. So you cannot do small chunks alone. You need to have some kind of vision, not the detailed, necessarily detailed plan. Not every whole architecture written down in PowerPoint and, but you need to have a vision. This is where we want to go in. Whatever the future is, And then you can do those weekly chunks and that's fine. That's perfect. But one without the other. Kind of like, I cannot just do random things every week, Let's this week explore mainframe. Why not? We got rid of it five years ago, but. This week, why not? Right? You need to have some kind of vision. It's just that you don't need to need to be so detailed as, people think.
Darin
00:21:15.881
I mean, typically ops is going to adopt a solution, a tool, a process, whatever, when it gives them more superpowers. Rather than taking those things away, right.
Viktor
00:21:32.104
If you talk about real superpowers, those are teams that build their own tools. They have true real superpowers. That's Google superpowers type of stuff, right? Kind of like I'm so powerful that I cannot even use existing tools 'cause my power goes beyond that, which is a very tiny, miserably, small percentage of. Companies, but that's true. Superpowers. Kind of like, yeah, we are building Borg because nothing remotely like that exists, at least in public. But then you have a what's the what, what would be the just below super, superhero and then that, those are the powers, huh? sidekick Yeah, exactly. You get psychic powers. When you adopt existing tools, yes. Sidekick powers. Oh, I like that.
Darin
00:22:26.422
I think another thing too that matters is as developers, you and I go to conferences all the time, well used to, and that's where we'd learn new things and we'd say, oh, we can try this little bit out. The same is true for operations people as well. Operations, people going to operation centric things are gonna go a lot further. And hearing people talk about, yeah, we've been doing this for 12 months, 18 months, it, it's been fine. Versus a vendor coming in to pitch 'em every other week,
Viktor
00:23:04.512
Yeah. You know, it's, it is not something I prepared carf, like it's coming. Uh, out of my mouth. Uh, the same, uh, with same velocity my brain is processing. But yeah, small chunks, vision that can change because if vision does not change, that means that we are not applying what we learned in those small chunks, right?
Viktor
00:23:29.149
Because that's the whole point. Do something, learn something from it. Apply in the next one. And just by applying lessons learned, your vision changes. Not necessarily overnight, but also incrementally.
Darin
00:23:44.146
Another thing can happen. You're talking about small chunks. A variation of that is shadow adoption. We usually talk about shadow adoption at a a shadow it, which is sort of a negative towards operations. 'cause if we're doing shadow it in a, in a company, that means we're trying to bypass ops.
Viktor
00:24:04.251
Yes, those are the funky people. Those are the people using AWS while you're still running mainframe on-prem. It's just that they cannot tell you about it because then you will yell at them.
Darin
00:24:14.423
But those are the people getting around it. But I'm talking about inside the operations team itself. Even within the operations, you're gonna have those rogue shadow people. It's like, oh, I heard about this thing called Terraform. That seems like that can make things easier than going in and pointing and clicking in the console. Should we do that? Let's go try it.
Viktor
00:24:34.248
Yeah, so what you're, what my brain is interpreting that you're saying is that when we as decision makers think about the roadmap, what we should want to do, what to improve, we just consult with, what was done in shadows last year. And if it's still being done one year later. So if the shadow persists, so sometimes shadow appears and disappears. Sometimes shadows persist when they persist. That's the proof. Adopt it. Adopt any shadow that didn't disappear within a year. That's your roadmap.
Darin
00:25:17.021
That almost sounds like a, a wonderful way to run a business. Also very chaotic at the same time.
Viktor
00:25:24.201
What is shadow infrastructure's, shadow development, or whatever you wanna call it? Uh, depends on the group. What is that? If not illegal? Center of excellence.
Darin
00:25:34.889
You're not wrong. It's exactly what it is. if I, as a team coming outta operations for a moment, if I as a team can actually get things done faster and I've removed my bottlenecks, going back a couple of episodes and I'm, I'm shipping. And my, my boss's boss's bosses is happy then, isn't that the right thing to do?
Viktor
00:25:55.485
Exactly. So maybe there should be some kind of rule. You're not allowed to do shadow something, but there is a one year moratorium to it. Kind of like if the crime committed is more than 1-year-old, it's fine.
Darin
00:26:12.569
Okay, I'll, I think some legal departments would have a problem with that, but, okay. We'll, we will go
Viktor
00:26:18.434
No, I'm pretty sure that there is, even in legal kind of outside the fight, right? Isn't there some timeframe after which you cannot charge somebody for a crime?
Darin
00:26:33.689
Yeah, it's, uh, I can't remember what the phrase is, but yes, there is, there is that. It'll come back to me in a minute. So we talked around all these other general tools. Let's talk about AI and operations again today in 2026. It's still early, early, early, early, early days as compared to the other places where AI is being used.
Viktor
00:27:00.466
Yes, I, I would, I would actually frame it slightly differently, less concrete, and that's, hey, there is data in, in one or very few places to fetch from and there's a lot of, it makes sense out of it. when we start doing, going into multiple places, that becomes. Slightly more complicated. So I'm excluding those, where there is not much data then my brain, if I'm experienced, can process it in no time either also. But if there is a lot of data, very few, maybe even one source of data, then that's where AI shines absolutely shines.
Darin
00:27:36.403
Let's go even simplistic to that. sure. You and I can write bash scripts all day long. Do we want to, I could have Chad, GPT or Claude crank out a bash script that has much more, Input validations and everything else that I always forget to put in as a general developer nowadays, I've got a better script out in the backside.
Viktor
00:27:59.646
I feel that. The biggest problem when we, if you now switch to AI operation subject, I give impression somehow when people talk negatively about AI in operations, they somehow assume AI instead of me. And then we come to, Hey, it's not reliable, it's not this, it's not that. It's not good. And I feel it's the other way around. And I, first of all, I don't understand why people think like that. I think it in a way that it enhances me and then, hey, I get this almost instantly, almost for free. And let's say it's 50% correct. Would they let it run it? Replace me if it's 50% correct. And I'm only 60%. I'm, I'm over 60% Correct. Because I'm not also always correct just to be a hundred percent clear, but I'm, I'm maybe 70% correct. And this is only 50% Correct. It cannot replace me. Yes, of course it shouldn't. Uh, but if you look at it from the perspective, it's 50% correct. So basically I, if I'm behind the, in the driver's seat and I get those 50% for free, then I can focus on the other 50%. Isn't that beneficial? Anything that does part of your work isn't that beneficial? Even if you have to review it and correct it, if the amount of time spent on reviewing and correcting is bigger. Then the amount of time you need to do it yourself, then that's a bad deal. But if reviewing and correcting takes less than doing it yourself, then you're winning. Right. Then it's beneficial.
Darin
00:29:39.604
Absolutely every day of the week because it's bought me back a little bit of time and it gave me more time to think because even, even if it's not perfect, it's like, oh, I actually need to do this one little thing. If I can feed that back and it rewrites it for me, that's still gonna be faster than me writing the change potentially.
Viktor
00:30:00.620
Are you now going to rewrite enterprise rules? Thinking? What are you thinking, man? If you think that you can think you're supposed to follow the rules. You're not the first one here. The rules exist for a reason. Following the rules does not require thinking.
Viktor
00:30:21.265
Of course you don't. Exactly. We go go to the go to startup. If you want to think kind of like, we are not here to think, we are to make, make sure that this works and we make sure that it works by following the rules and we have the rules. We don't know why, but there must be a reason. I mean, we don't know why. Why? Because to understand why we have those rules, we will need to start thinking.
Viktor
00:30:51.450
Oh, that, then you're in a loop. If, if you reach that point and start questioning at that very point, man, you, you are not in a good place that you're going to end up in an institution that is other than, than the institution where you work.
Darin
00:31:07.421
What would it take you today to trust AI to completely replace a human in a workflow. Not everything but a workflow. A basic workflow.
Viktor
00:31:19.766
I don't see us being even close to it. Now. I might be wrong, just to be clear. maybe I'm wrong because I have certain opinions. I have certain demands. I have certain vision that AI is not giving me, and now we need to discuss whether, actually, maybe all that I'm wrong in all those. that's in an option, right? It's possible, but if I'm not and I'm not, because I'm the one using it, not the other way around, then yeah, I'm needed. Now, what I hope is that the ratio, so when I work with ai, part of that work is spent on thinking what I want to do next while it is doing something, and then I check. Validate, say yes or no, and then repeat the process. Right? Think, validate, give maybe additional instructions, repeat. Now, what I want to, the, to increase the ratio of the first, let's say for the sake of argument, this is completely invented. Let's say that I'm spending 20% on thinking right now and 80% on, uh, validating. Correcting, giving additional instructions and so on and so forth. If I can get to 90% being thinking and 8% being telling what I want and only 2% being correcting, that's amazing. That's what I want to get. I'm not sure that I will, we are nowhere close me not being involved in it. And I feel that whomever says that that's, this is going to sound harsh, whomever says that today, they just let AI do stuff. I feel that they're not experienced enough and that's why they're doing it. I could be delusional. That's option number one. Option number two. I easily find flaws, in what AI is doing, which is normal. I find flaws in what people are doing. Just, to be clear, that's why we work together, We have code reviews. One person reviews code of the other, not because one is better than the other, but second look gives you additional feedback.
Viktor
00:33:45.004
Yeah, exactly. So you could have two. Equally good engineers and it's still valid to do code review, right?
Darin
00:33:53.096
I would say even if they're not equal, I mean that's even probably where it's even more
Viktor
00:33:57.176
It It could be, yeah. It could be less experienced person reviewing, more experienced person committee. Yeah, perfectly valid. Exactly. So I dunno the future, but right now I'm not out to the picture. I'm just much faster. I spend much more time thinking.
Darin
00:34:16.354
So if you're a skeptical person by nature, which I am, and this could be a skeptical ops person, developer, fill in the blank, doesn't really matter. I have a couple of thoughts for you. first off, your skepticism has been correct before it has been, but it's also been wrong before.
Darin
00:34:34.474
So try to know which is which come, come to your senses, for lack of a better term, and realize that you're not perfect. Uh, Victor's perfect, but nobody else is perfect. another point is ask yourself what evidence would I need to see in order to be convinced that this is true? If no evidence would change it, that's a red flag. one more point. The thing you're resisting is probably coming anyway. Do you want to get on the train and ride it out? Or do you wanna just have it run over you? You have the choice
Viktor
00:35:10.439
because then you can, if you choose the latter, you can share the office with, John. He's a DB two expert.
Darin
00:35:16.796
exactly. If, if it's gonna run over you. Right. Either you get on or, or, yeah. 'cause if it's coming, it's coming. If in your organization it might not be coming, and that's fine.
Darin
00:35:34.432
Now, if you're trying to get some buy-in, like if you're on, if you're on the other side, like it's a developer trying to convince OPS or other management, trying to convince ops, stop saying this is the future. Uh, ops has heard that before. It doesn't mean anything. It just doesn't, Lead with control, observability and feedback. In other words, talk the language of your operations person if that's not their language. are you sure you have an operations person?
Viktor
00:36:06.441
exactly. I mean, it needs to be their people, not somebody's else's people speak the same language.
Darin
00:36:13.916
And finally, as the outsider, you have to accept that OPS is going to adopt whatever it is on their timeline, not yours, like it or not. Now, if you're a C-level and you can force it, that's fine, but please, please, please, please realize that if you're forcing something, that means something else is gonna fall off.
Viktor
00:36:36.832
I might push back on that one. Not all people are equally good. To execute some vision, some people are better than others. Not that some people are better in general than others. That's what, not what I'm saying, what I'm saying for this specific vision, some people are better than others, right? More aligned with the vision. Their experience is closer to that vision, what's not right? if the vision never changes, then almost everybody in the company ends up being the right people. because those who were not over time go somewhere else or get transformed, get influence, get indoctrinated, whatever you wanna call it. Now the question is, when the vision changes and it's changing all the time, then what do you do? Kind of like some people who were keep being good fit for that vision. Some people not. And that's normal. That's human. No hard feelings. You're fired. You know you need to give a pitch before you say the last words. Kind of like it. It lands better, right?
Darin
00:37:44.158
Yeah, feel warm and fuzzy and then you're fired. Yeah, that's the one way to think about it.
Darin
00:37:52.048
So here's what we can assume that ops resistance is always probably going to be in place, always probably, if you've got a good ops team, they're gonna be resistance to change, and that's a good thing. You Okay. You're pausing there for a second. But I, I'm gonna say it's a good thing because I want, if that's what my money maker is, ops to me is not a cost center. Ops to me is value more valuable than probably any other team in the company.
Viktor
00:38:18.640
It is not a cost center. Uh, I don't want to go in more valuable, uh, discussion. It could be a long one, but it's not a cost center. I agree on that one. But, we have three servers and I'm resistant to change 'cause this works. But we need hundred servers. The change is coming, man. Kind of like we have kind service. We cannot manage it with SSH anymore, It's not that you are resistant for a reason. No, you are, you're ignoring the necessities we have or the opportunities this might unlock, right? Because switching from aging to, let's say Kubernetes, uh. Might be a necessity 'cause we simply need to have thousand servers or 10,000 servers. Kind of a hundred does not cut it. Or can you imagine which business opportunities will be unlocked if we can run close to an unlimited number of servers? And so it can go both ways, but simply it changes all the time. you cannot be conservative. Or you cannot be only conservative, let's say like that. You need to balance. Conservative is a bit the fact that time moves forward.
Darin
00:39:41.760
often very rational, but eventually it breaks Due to the company requirements, right?
Darin
00:39:53.881
It's rational. From an operational perspective, not necessarily. I might not see it as a legal person. I might not see it as rational, but from the operations, it's rational because this is going to affect me and everybody else because I know the dirty underbelly of the beast.
Viktor
00:40:07.681
and. Now we are entering into a different type of a problem with your last sentence, and that's that I strongly believe that most people are rational and thinking logical and all that stuff. Very often those rejections are because the reasons for never really explained Why, why do we want Kubernetes? We don't want Kubernetes. This works. and nobody told us that actually there is a need for 10 x number of servers. Nobody explained it to us. Kind of. So my ex, my explanation not to Kubernetes for our three servers is perfectly rational. Because. I never heard the, the other reasons. you never brought to me the explanation why we are doing it. You just came and said, uh, we need to start using Kubernetes. Because why? Because, it's cool or because, that guy, what's his name? Kelsey Hightower is. Explaining it really well. I have no idea what the explanation was, but That's so good. We need to do it then. Rational explanation is no.
Darin
00:41:26.692
especially if they heard the hard way. You'll understand that if it's a different conversation, we could spend hours talking about this. my heart goes out to operations people today. I was mainly ops until the mid two thousands, like 2005. I cannot imagine, imagine the pain and suffering you've been going on since 2005 until 2026. I, I just can't, and I'm just glad I'm not doing it anymore. That's all I can say. So what do you think over to the Slack workspace? Go to the podcast channel, look for episode number 3, 4 0, and leave your comments there.