Viktor
00:00:00.000
the answer to your question can be yes or no, right? Pipeline is broken If the answer is yes, whatever you're gonna say, say, say it after this. If the answer is no, that means that you're not aware of it. The answer is always yes. You just might or might not be aware that it's broken. This is DevOps Paradox, episode number 3 3 8, the assembly line problem. Why adding AI to one step breaks everything?
Darin
00:01:22.441
Imagine this. You're working in a team of developers. You've picked up Cloud code, you've picked up Cursor, you've picked up, fill in the blank AI tool. You are actually seeing real performance results and turning out more, let's call it good code and completing more features than ever before. However, these features aren't getting into production. Why is that? Viktor?
Viktor
00:01:46.538
because somebody else is blocking you. It's as easy as that. I, I, I don't think you should have said even the word AI in that story, right? That story is exactly the same with AI or with anything else, right? We have, let's say SDLC, like software development life cycle, right? And there are steps there like, Hey, figure out what you're going to do. Uh, figure out how you're going to do it. Write some code. Write some tests, run, run those tests, and all other tests confirm that it works. locally create a pr, somebody reviews it, merge it, uh, cis run CDs run. Uh, we observe what's happening in production and so on and so forth. Right. Not going into details of SDLC, but there are a bunch of steps, if any one of those phases, let's say, is going faster than the others. Then that something else becomes a bottleneck, right? Doesn't matter whether we are talking about AI or if we are talking about, you switching from punch cards to Java, right? And that speeds you up tremendously in how fast you can do something, right? The story is always the same. It's just that with ai, we are potentially, and I'm repeating, potentially seeing. Improvements we haven't seen in a long while. Right? So those problems may be, are more evident.
Darin
00:03:13.872
I like what you said there. The story is always the same. Plus you probably gave some people going, what's a punch card? go look it up. Punch cards existed before tape. If you're asking what tape is, we need to have a longer conversation, but the story's the same. There was a book that came out in the eighties called The Gold by Gold Rat. We had Phoenix Project more recently, meaning in the past 15 years. The story's always the same. It's the SDLC. So we think about a complete SDLC. That means somebody thought of an idea and that idea has now turned into something real and people are using it. Those are the two ends. But in between those two ends of that pipe, that pipeline, wherever you wanna call it, we have. Business analysts, we have developers, we have lawyers, we have security people, we have operations people. We have blah, blah, blah, blah, blah, blah. And if at any point during that gets sped up, the people downstream of that are getting more pressure because things are flowing faster. What's funny though is then the people that are upstream of that don't realize, oh, I could be doing more, but we don't tell them that.
Viktor
00:04:30.879
And you know, what is the most common solution to those problems, to eliminating bottlenecks. The lead of that team says, I need more people. And then you realize that actually very often, more people, sometimes you do need more people, but very often more people does not speed things up. Very often, you know, there is that joke about how long does it take? Nine, nine women to to, to make a child
Darin
00:04:57.477
certain things just don't math. And the thing that we have to think about here is, okay, we, created more capacity at this one station, but the station downstream hasn't increased its capacity to accept more. Therefore, that station is the bottleneck, but. You know, we moved the bottle. In theory, we moved the bottleneck from development down to qa, but that's all we did is we just moved it. It doesn't eliminate it. We still have a bottleneck in our full pipe.
Viktor
00:05:30.604
So here's my theory, the most effective and nothing to do with ai. Just to be clear from the very start, the most effective way to to go fast is to be the only person involved in SDLC, A single person. There is nothing faster than that. now when I say single person, single person cannot know everything, but that means that. The system is done in a way that that single person can do everything, including both things that are that person's core competency and things that they're, they're not right. Kind of, Hey, do we need to wait for code review? Well, no. Whatever the solution for not waiting is right. Do we need to wait for tests? Somebody is, uh, to execute tests? No. CI Jenkins Kit Cab actions, whatever you're using, is going to do that. Do we need to wait for Joe to deploy it? No. That will be done by Argo CD Flux, whatever, right? Do we need to wait for somebody to give a blessing that it's really working in production? No. And so on and so forth, right? If one person can convert idea into that idea being served to users. That's the best possible outcome. Now, I'm not saying that only one person should work on a project. This is important here now, right? Multiple people work in a project. I'm just saying that for a certain feature or bug fix or whatever, there is only one person that's the best approach I can imagine.
Darin
00:07:16.106
But to sort of lay out your example there, you talked about using Argo CD to take care of the deployment part of things. Somebody at some point, yeah, for example, but somebody at some point had to put that plumbing in place.
Viktor
00:07:30.846
oh yeah, a hundred percent. But there is a difference between. There is a difference between somebody coming to your house and setting up electricity so that you can press a button to turn the lights on and off, and a very different situation when you need a person sitting next to that button and turning it on and off every time you need lights.
Viktor
00:07:56.171
Okay, so there we go. There is a difference between setting up electricity with a button and having a bottler in your house. Right.
Darin
00:08:05.686
There's a big difference, but I think where we typically see most of our speed ups happen is always at the front of the pipe. Let's go to the very, very, very front of the pipe. You know, a business analyst doing research to figure out what it is that we're gonna implement. Used to, that was all on paper. And then we got word processors,
Darin
00:08:29.472
and then we got. Modeling software to, Okay, again, without saying ai. Now those people can actually create true prototypes or reasonable prototypes as compared to what they could do in the past,
Darin
00:08:42.606
Right? So over time things have sped up. If you look at the development side of things, we used to have, again, punch cards, tape terminals, VT 100, I love you, Amber, not green. Then we got many computers, micro computers. Mainframes, personal desktops. Remember, client server, most people don't anymore. We had the web, we had mobile. Now we've still got web, but we're able to generate out more and more code than we've ever been able to do before with fewer people.
Darin
00:09:17.593
And that's, I mean, AI's helped, but we've had that, you know, once we move to something like Power Builder or Visual Basic, or being able to put things just in Excel. having all this tooling made things faster, but then as we keep moving down the pipe, you know, you need people to check it out. Going back to your example of, it's great to have a single person be able to do the whole thing, but we can't do that in big enterprises.
Viktor
00:09:39.665
I wouldn't say we cannot do that. I would say. We don't do it. We dunno how to do it. We don't want to do it. There are many, reasons for that, but we cannot do it is most of the time not one of those. Right. now the problem with those bottlenecks, really, I think one of the big, there are many problems, but one of the problems is that typically you see the bottlenecks on the right side of you. And not on your left. So you mentioned, uh, somebody figures out what the feature will be and so on and so forth. You don't see that. You see the feature coming to you. feature comes to you instantly. Feature request. Did it take a minute, a day, a month, seven years to get to that feature? You don't know and you don't care. you just received feature request. That's cool There cannot be a bottleneck to the left of, left of you, right?
Viktor
00:10:43.964
Bottlenecks are always to your right because that's what you notice. That's what affects you, So if you're a developer, bottleneck. Are testers, I mean, depending on how you organize, right? If you're a tester, bottleneck is whomever is deploying that stuff to be tested. if you're writing those feature requests, bottleneck are developers who simply cannot, implement that feature fast enough. So it's always to the right and always to your immediate right. If, if you are the one writing feature requests, you are bottleneck car developers, not testers, not tops people, because they come later. You, you don't know that kind of like, I just gave this to this person or this team and it's still not, uh, available to my users. Kind of like that team must be the bottleneck, all this is completely wrong. Just to be clear. It's completely untrue, but that's how we perceive it.
Darin
00:11:43.560
let's go into perception just for a second. Again, we'll pull AI back into it. Right now you can get AI coding tools. I'm just broad brush for a pretty reasonable price. 20 to a hundred dollars per head per month. Right. We would agree with that number.
Darin
00:12:07.470
Okay. But because those economics are for, some companies are still too high, but they're not unreasonable to me. But we don't have those same kind of tools today for operations. We don't have those same types of tools today for security reviews. I mean, it's, they exist, but they're not as mature as what we have on the development side.
Viktor
00:12:29.820
I would actually split them into two categories. One being much more perceived as more mature than the other. one category, uh, is AI and AI tooling agents, what's not. that need to operate on a context that can be generated from what you have in front of you, agents for development work very well. What is the context? Well, I'm running cloud code or cursory in this project. The context is that project that's 90% and I'm being generous here, or pessimistic actually, that's 90% of what you need. Go. And, and I said, well, that's, that's what I need. Cool. Kind of like, yeah, I, I can do that. I would probably put security scanning. And I'm repeat scanning, not security in general into the same category, kind of, Hey, what do you operate on? This image or this repo, or whatever it is, those manifests. Can you tell me whether there is anything to be fixed from security perspective? Of course I can. But then you have other situations where context is not. Directly accessible and freely available. Ops is a good example. Like what do you need to operate something successfully, right? Well, you need information about your AWS account. You need access to a cluster. You need access to run books. You need access to best practices in your company that are currently in your head. Or you think they're in your head, in your head, but it's actually only a small percentage of it. And you need some company policies, uh, some patterns, and so on and so forth, right? that changes drastically the out of the box usefulness of current state of ai, not ai usefulness AI outta the box usefulness because you need to work more to make it useful. You need to figure out how to give it the context it needs, right? Because all of a sudden for those people, it's not, ah, it's, it's this ripple, everything you need to know, it's, it's in this repository. Go. Why? Why are we talking about this? Just, just do it. It's easy.
Darin
00:14:50.017
Let me pose something to you and I wanna see if you agree or disagree. Hopefully you disagree.
Darin
00:14:58.272
would say, okay, we'll, we'll see. So either, okay. Companies, or I'll even say as humans, we tend to optimize for the things that are easy to optimize for, whether that's the constraint or not
Viktor
00:15:14.572
Yeah, we kind of like it's, it's so much more pleasant to work on easy. So solving easy problems than solving hard problems. Of course. That's, that's human nature, what you just described.
Darin
00:15:26.470
but if we're spending, or if companies are spending all this money right now to solve the AI development problem, but they're not solving everything down the line, aren't they messing up?
Viktor
00:15:37.505
Uh, they're messing up big time. Yes. Because then, then we get to those bottlenecks. So then we get to that conversation, how this theme. Is 50. Uh, let, let's, let's be pessimistic kind. 25%, 20%, make it 10%, 10% more productive, right? And I'm not seeing features being delivered to my users 10% faster or 10% more, and so on and so forth, right? That's because, again, Specific step or phase of SDLC being faster does not make SDLC faster?
Darin
00:16:16.483
especially the closer it is to the front of the pipe. but closer to the end of the pipe, it should be right. We were talking about your single person and they've got Argo, they've got all the security scanning in place to where everything is quote unquote, officially automated.
Viktor
00:16:33.033
let's say that we look at it from the developer application, developer perspective, but this applies to every other expertise, right? And let's say that your team is optimized to, write code for three features a year. Uh, sorry, a month. No, make it five. Five features a month. currently your organization is optimized for that, meaning that on average. There will be five new features added to the backlog a month. On average, you will write code for five feature features a month, and on average testers will test five features and ops will, deliver five features and, uh, to production and observe it in what's not right, and so on and so forth. So we are optimized for five features. Now what happens if one of those manages to do 10? But application developer, I, I can develop five, 10 features. Yeah, but I got five, I have five in my backlog, so let me go and watch Netflix, or you increase the backlog because there is always more. And then you say, okay, but testers just tested five feature features, so that's your bottling. So unless everything. is improved. Nothing is improved. It's as easy as that, except except lives of those who improved. They become man Awesome. Absolutely bloody awesome. Imagine if you can do double the work, but bottlenecks are both left and right of you. What does that mean? That means that you have 50% of free time, and that's awesome. You can watch Netflix.
Darin
00:18:19.140
Or you can think about how to make things go faster the next time you're doing something. That's what you should be doing. Not watching Netflix, more free time. Yeah. To watch Netflix at that point, I think I've already sort of alluded to this. We spend the time doing easy things, easy optimizations, but we should be really to help out. We need to focus where the constraint is first and not the easy stuff. Right.
Darin
00:18:48.201
Even though that's probably the most painful, the most meetings involved, fill out all the other blanks, but that's the reason why it's called a constraint. We're trying to open up the constraint.
Viktor
00:18:59.093
except that really In organizations that exist for a while, usually there is no single constraint because of that optimization I mentioned before, right? The number of people, the technology we use and so on and so forth is optimized for this, whatever this is for this assembly line. I imagine it's a factory, right? You don't have a single bottleneck anywhere in the factory. I mean, you might, but that. That's then really problematic factory, right? No cars are churning at this rate. There is no bottleneck except everything becomes, if everything becomes bottleneck. Now, that's not fully true. Just to be clear, kind of like we might end up with steering wheels having much bigger rate of failure than, than some other parts of the car. But in general, assembly line is optimized. It could be proved, but the assembly line can be proved, not a specific step in the assembly line.
Darin
00:20:04.185
Well, we think about the overall cost of trying to fix the whole assembly line. We, we, we can't fix the whole assembly line at line at once, even though we need to. So we focus on one place, but then we start cascading something somewhere. You make one change in the pipe and something will change downstream of that and potentially upstream.
Viktor
00:20:24.490
Yeah, but that makes sense to do, to be clear, because it's very hard to understand the whole system, how it works. It's kind of in bigger systems. There is no single person who understands kind of, I really understand the whole system, kind of like bigger systems are impossible to understand too many moving pieces. So what you can do is say, I'm going to optimize this step. And that's okay. As long as you understand that that's not the end goal, that you're doing that for two reasons. First, to optimize that phase, that step, which is kudos, great. But the second is to be able to surface then what should be done next. Okay? So we optimize this, whatever it is, and that will surface some bottlenecks that there may be before or after, or, or wherever. Right? And then that allows you to see more clearly what should be in the next optimization. So as long as it doesn't end there, it's, there is no, the problem is not trying to optimize any of the steps. The problem is thinking that that's the end game.
Darin
00:21:30.378
Well, everything you've talked about, I've talked about up to this point is doing everything sequentially, right? We, we look at our space, we look to the left, we look to the right, do what we can, but shouldn't we be doing this in parallel? Shouldn't there be a reasonable, as much as I hate these centers of excellence in companies, shouldn't we say, okay, let's look at our whole pipe and figure out, okay, what do we need to do across the whole pipe? Even if it means we gotta slow down on one in order to get the other one caught up first. Okay.
Viktor
00:21:59.793
The up to point. But not really. 'cause you know, the problem with complex systems is that if nobody really understands in all the detail, the whole system, then you cannot predict how will any change to the system really affect the rest of the system. I'm getting philosophical here now. Right? So what you can do is poke the system and say. I'm, I, I'm going to change this thing thing and then I'm going to see the effect of that, and then I'm going to better understand what's happening, right? And then I'm going to poke that other part and I'm going to see the effect is, so while, yes, I do agree that companies should be thinking of the system as a whole, and how do we optimize the whole assembly line that should be balanced against. The admittance that didn't really, we cannot figure it all out at once. Right. The only thing you will accomplish with that is, okay, so, and this is now central of excellence story and, uh, uh, digital whatever, uh, uh, initiatives the companies have is that, okay, so what did I accomplish? Well, it's been three years. And we are still working on it. We're still trying to figure it out, It's, we all become philosophers in a company. Oh, no, no. I think that we should do this. Oh, no, no, no. I think no, but yeah. You forgot this part. Oh, yeah, but maybe not. I dunno. Is that how it works? Okay, let's check it. Let, let's, let's gather next week again. That's usually how it goes. And it doesn't work.
Darin
00:23:48.914
Well, you're making my next point for me. Uh, we need to be looking at actual flow of whatever's going on, not just the activity. We spent three years of looking at, you know, poking and doing things, but we actually haven't done anything.
Darin
00:24:06.220
Wait, fix your, fix your language there because doing stuff can apply to activity as well as flow.
Viktor
00:24:11.370
I feel that you need to combine both in terms that you cannot go to either extreme. You cannot just say, let's do random stuff and see what happens. Right? Only exclusive with that, right? You cannot say, oh, uh, I will be planning forever. what I feel we should be doing is that we should be focusing on one thing at a time. At least one team should focus on one thing at a time, but still have certain level of understanding of, of the system as a whole. Right? How does this affect kind of like, okay, I cannot, I cannot optimize everything at once and I cannot be planning, optimizing everything on at once. Forever. I can focus on this thing and that's fine. The problems arise when, that's the only thing I understand. The only thing I know. That's going back to the bottlenecks left or or right of you, right? If I focus only, if you don't understand the bottlenecks left. If I don't understand the bottlenecks right, then my effort is going to be a waste as well.
Darin
00:25:11.700
bottlenecks will just keep on. Piling up. But let's think about this. What if there's a place that we can't actually do any kind of automation with yet think legal even though there's, you know, certain things we can do, but we think of the typical places to where things start to, to truly bottleneck legal, deeper security reviews, those kinds of things. What we're not doing is we're not planning for enough slack in the system. For those things to still flow. Again, we wanna go back to that point. We don't want activity 'cause we could backlog legal and never ship anything. This is always the funniest thing to me in some places, right? Uh, we've made a promise to ship on January 1st. That's great. Legal needs it by the end of September. Well, we're not starting development until December, right? We, we don't have these kinds of things built in when we're actually going through the full process. We're not looking far enough ahead, fi potentially five years before.
Viktor
00:26:04.651
you just measured one example of those bottlenecks that prevent attempts from really showing benefits, right? You said legal. Cool. How often did you hear from engineers? Uh, sentence is like, oh, we cannot, cannot use cloud because of this or that. Right? we cannot do this because of this and that. Right? That's when you are trying to focus on your own optimization. while other parties are not, right? I heard many times things like, oh, for legal reasons, we cannot do this, I never heard anybody saying. For legal reasons, we cannot do this. So let's go and speak with legal kind of, maybe we can change it. Maybe there are different interpretations of this thing. Maybe we just got the memo and never actually bother to do anything about it.
Darin
00:26:56.477
You mean actually run projects like we're adults instead of kindergartners? Is that what you're saying?
Viktor
00:27:03.237
No, the other way around kindergartners would be gathering together and playing and doing stuff. Right. We act like grumpy adults, kind of. I, I'm, I am 87 years old, kind of like I'm not speaking with anybody, especially not people my age,
Darin
00:27:26.460
and that's the problem. Who should own this whole pipeline? Redo. We, we've heard digital transformation, centers of excellence, all these things, but yet in most places, nothing ever happens. When it's all said and done, it's still the same thing five years later.
Viktor
00:27:43.616
Because at best, those attempts are done by people who are. At the best on the same level as other people. So you have a head of testers, head of, application, developers, head of ops, head of security, and at the best, somebody comes to you and say, Hey, can you lead the center of excellence? Kind of like figure it all out and you're going to be at best at the same level as those people, right? So you are just fighting for power, kind of. Oh, it's you against me. it needs to be above, it needs to be whomever is in that center of excellence or whatever companies call, kind of innovation centers needs to be above all those people so that we figured it out. Now we are gonna do it What happens is that we figured it out, but they don't wanna do it. almost all those innovation centers ends up with. Yeah, I had a great idea.
Darin
00:28:51.774
to so, so what, what happens to the people, the departments that are the bottlenecks that don't seem to be able to move forward? Are they more important than ever, or do they just get squeezed out or let go?
Viktor
00:29:16.860
So in practice, what happens is that, yeah, because of this and that, we cannot, this is great. Kind of what, what you guys are doing is absolutely amazing. Oh, I'm, I'm. I'm supporting this a hundred percent, but we are special. We cannot do that, we need more people. The only way we can solve this is more people kind of like you. You can red code faster with ai, so that's great. but for us, whatever we are doing without naming names, it doesn't work really. It doesn't apply. Yeah. there is no other, because sometimes that's true, right? But kind of, and there are no other things we can do. So we need more people and we cannot get more people because kind of we are already, you know, we already have big headcount, so, well, I dunno how to tell you this, but nothing, there's nothing we can do. actually, you know what? We are gonna give Joe 20% of the week. He's one of the 20 people in this team. He, let's do that. Let's give Joe 20%. Maybe he'll come up with something that's in practice. In theory, I would be the worst boss, I would say. Okay, you cannot do it well. Uh, it was nice working with you. Let's find somebody who can.
Viktor
00:30:41.708
No, I think that uh, people would not see it like that, but I would see it as doing everybody a favor because, ideal situation is where you are happy at where you work. And that work fits your profile, your understanding, your experience, what's not, right? So if you just changed how we operate this company, 'cause I say so, and this is different than how you work, what makes you happy, then you'll not see it that way. But I'm doing you a favor by saying thank you. It was nice working with you because. You will end up land in a company that actually better aligns with what you want to do. So let's not try to align the company where to the way you want to be and work, but let's find people who are aligned with how we operate here. Everybody's happier.
Viktor
00:31:46.032
It's a good thing. I like being happy. I like being happy much more than being miserable.
Darin
00:31:51.486
So let me pose this to you and we could swap out AI for any other number of things. AI adoption is actually a systems problem, not a tooling problem, right? And AI could be flopped in and out for any new technology of the week.
Viktor
00:32:07.352
I dare to find me an example where it actually something applies only to, to one. One group. It might be more focused on one group than the other. Yes. But that applies only to one group. That never happened. And it's always perceived like that. Always Kubernetes. That's only for this team. Nobody else needs to understand what's going on. Kind of like, 'cause they, they're gonna deploy it for them. Cloud. Oh yeah. We need cloud architects kind of like everybody else. Business as usual, right. it always affects everybody to different degrees, but it's most of the time perceived as something that is domain of only one group.
Darin
00:32:46.315
Well, speaking of one group, one of the big things again, right now because of the economics being reasonable is people are trying to add AI to development instead of thinking, how do we make the pipeline more efficient so that developments is no longer the bottleneck.
Darin
00:33:06.208
it's, and, but, but, but focusing on just one without the other isn't helping. We've already talked about that.
Viktor
00:33:13.003
Uh, it might help. So, uh, it does, it's not helping if it's very tense. Right. But it might happen. It might, it might help to surface those bottlenecks. we accomplish this with this team. Now it's your turn, Oh, it's not the same. I know it's not the same. Yes, I fully understand, but it's your turn. I'll give you margin, kind of like we expect 15%. Now you can go to 20% of improvement, or 10 is also acceptable, but it cannot be zero.
Darin
00:33:48.749
Again, this is nothing new. This just happens to be the latest tool on the block.
Viktor
00:33:53.393
Yeah. And it becomes easier over time. Because let's say that you have 10 groups in a company, right? And let's say that one adopts something and everybody else kind of, no, no, not for me. that one team sees improvement. You will have difficulty to convince that nine other teams are wrong, right? But if over time you will manage to convince one other team and then it'll be two against eight, and the more that number increases when it becomes. 50 55 against five, then the number of arguments in defense of status quo start diminishing
Viktor
00:34:33.916
logic. I know, I know. Logic never gets us anywhere. I know that, but you know, I'm stubborn. I keep trying.
Darin
00:34:42.356
Well, I think the, the companies that figure this out are gonna have much happier developers and probably a lot less stale prs just sitting around waiting to be merged in.
Viktor
00:34:51.893
Just wait. it's going to happen. I don't know when, but it's not such a distant future. There will some gains, some companies are going to emerge, transform. Either transform themselves or emerge as something completely new companies and they're going to start, uh, causing problems in the market for everybody else, and that's when the choice will stop being a choice.
Darin
00:35:19.167
this has taken me back to the early days of Netflix, Uber, Lyft coming onto the scene and showing up at conferences and people actually doing some of the things that they were doing. Obviously not the full thing, but people saw that and it became normal, like. One of the biggest things out of, again, not just Netflix, but other places, was feature flags. Now we could argue that feature flags still aren't being used today, but that's a much longer conversation. But it's not abnormal to see feature flags today. It was before then.
Viktor
00:35:56.020
Yeah know a while ago I was in European Broadcasting Agency or something like that, it's called Right Where, it's some, some kind of agency with different broadcasters in Europe kind of work together and what not. PBC being an example that typically people outside Europe know of. That was long time ago. and I was trying to pitch them certain things and the response was, yeah, but you know, kind of like, we understand how this works for, uh, for others, but this does not apply really to us and so on and so forth. And that was in early days of Netflix. Still denial, I bet. That none of them would gimme the same answer now.
Viktor
00:36:42.826
Yeah. Kinda. Oh, people are not going to, stream much. Kind of like, uh, they're still going to prefer watching television. Cool. Kind of. I, I cannot counter argue that. I mean, I'm now talking long time ago, just to be clear. I could not counter argue because it's my personal opinion. I think you're wrong, but hey, prove me wrong. You cannot, just as I cannot prove you wrong now, now I can now, now, you cannot gimme the argument that, oh, people prefer, uh, watching, uh, live television over streaming. I'm not saying nobody prefers watching live television, but you cannot say that, Hey, streaming is a niche. I have data. And then, then you, then you can rekindle the conversation. Okay? So, but what do we need to do to make it happen for real?
Darin
00:37:29.561
And we as technologists. Probably would get very frustrated. It's like, come on, can't we just get this done? We will be able to get things. But the broader ecosystem, the broader company, it's like, Nope, we're not ready to do that yet. Going back to Netflix, Netflix didn't start out as streaming. They started out as DVD delivery That then turned into streaming.
Viktor
00:37:50.986
the strange thing, what you just said. It actually happens in most companies that, did you notice that whichever team you are speaking with when you visit companies, they're always, oh, we would like to do this, but the rest of the company doesn't want to. And it's always the team you're speaking with that has that opinion. Right? I bet that you could rarely speak for the team that says, no, no, no, we don't want this. No. Oh, we want to change things. We would like to do this and that. But you know, the rest of the company, they're not on board. And it's always the team you speak with. And the only logical conclusion is that actually almost every team has that story. Every team has idea that they should do something differently. And the only conclusion from that is that. Simply, there is no company alignment. Kind of like everybody goes in random places and everybody has a convenient, actually, I think that is important. Each of those teams want to do X, whatever X is, but can conveniently avoid doing X because they can use company as an excuse, oh, I would really like to do this, you know? But I cannot do it because of those other teams. It's always like that. Isn't that so convenient? You, you never have to do it because you can never do it.
Darin
00:39:24.524
And if, if your head is starting to spin because you're thinking Viktor, what are you saying? Welcome to corporate. I was gonna say corporate America, but that's corporate worldwide. And I don't think that's any different anywhere in the world.
Viktor
00:39:38.227
I feel that you and me, that in our privileged in that aspect is that we both worked in consulting and we have both worked with quite a few different companies, often very large, and we have perspective that many other people don't have. Right? They're aware of the environment they're in. And once you visit and work with many, many different companies, you start noticing patterns and say kind of, no, you're all the same. You all complain about the same things. You all have the same problems, and you all think that there are no solutions to those problems.
Darin
00:40:17.654
And if cons, source, of course, as consultants we're able to tell you, of course there's solutions. You just don't want to do them.
Darin
00:40:28.543
So where do you stand in this right now? Is your pipeline just so broken beyond repair that you'll just probably retire at some point in the future and just let it sit there and crash
Viktor
00:40:39.383
Wait, wait, wait, wait. And uh, the answer to your question can be yes or no, right? Pipeline is broken If the answer is yes, whatever you're gonna say, say, say it after this. If the answer is no, that means that you're not aware of it. The answer is always yes. You just might or might not be aware that it's broken.
Darin
00:41:05.636
So what do you think? Head over to the slack workspace over the podcast channel. Look for episode number 3, 3 8, and leave your comments there.