Tim
00:00:00.000
the whole Agile and DevOps for me is a philosophy, it's an ideology, it's a mindset, and it should really be injected and spread across multiple silos. If anything, it's to bring silos down. So the risk of creating titles, like you're alluding to, is that it actually creates a new silo, and it's an anti-pattern
Darin
00:01:22.664
Viktor, it's been a few years since we've been doing this podcast. In fact, in 2025, this will be our 1, 2, 3, 4, 5, 6th anniversary. Most people think about, okay, this is DevOps paradox. That was a book that you wrote a while back. We decided to use it for this podcast title, but for some reason, people still think that DevOps is a thing, but it's in the title.
Darin
00:02:02.574
And we needed help with this discussion on today's show. We have Tim Beatty on from Stellify. Stellify. Is
Darin
00:02:11.284
good. Now, before Tim was co founder and CEO at Stellify, he was working as the global head of product for Red Hat Open Innovation Labs and did a lot of travel for that and saw lots of people. Let's ask Tim. Tim, is DevOps really a title that someone should have?
Darin
00:02:36.892
Have a nice day. Uh, so where, where, where did this twist come from? Now you've also co authored a book too, but it's like, why do people think, and let's go and throw another one in there since we're making half the world unhappy. Agile also shouldn't be a title. Right?
Tim
00:02:54.417
I've seen both Agile and DevOps become buzzwords, huge buzzwords. And when buzzwords emerge, people create titles to sell themselves, like that. Agile and DevOps. I think I have seen and met some very good DevOps coaches and Agile coaches or facilitators, and they've maybe put those buzzwords in their titles. Maybe, maybe it helps them, market themselves. but when I see things like the DevOps engineer or even the DevOps team, or the Agile team. It suggests a silo is being set up to create, this pocket of Agile or this pocket of DevOps. And the whole Agile and DevOps for me is a philosophy, it's an ideology, it's a mindset, and it should really be injected and spread across multiple silos. If anything, it's to bring silos down. So the risk of creating titles, like you're alluding to, is that it actually creates a new silo, and it's an anti-pattern
Viktor
00:04:01.420
I understand. Agile coach makes sense to me. DevOps coach makes sense to me, because it's a person who can explain to you a thing or two. Makes perfect sense. Now, what is curious is that We did get DevOps Engineer. I hear that a lot. We never, and I think it's completely silly. It's completely against the idea of DevOps. But we never got Agile Engineer. I never heard Node. js developer saying, I'm an Agile Engineer now, right? So it feels that DevOps is going even a step further in that, uh. Nonsensical hype adoption or something like that. Because I hear DevOps engineer all around. Everybody's a DevOps engineer. Whatever you were doing, doesn't matter. It's completely irrelevant what you were doing. You're a DevOps engineer. Let's face
Tim
00:04:53.643
so I agree. And I, I love the idea of coach. Now here's the thing. I think a great coach should be trying to do themselves out of a job. I think a great DevOps coach should be trying to enable, facilitate DevOps practices and set up the technology if they're, you know, setting up, you know, containerization or virtualization as a part of that. That could be a part of their job. but they should be doing it with a view to the teams around them that they are coaching or enabling being self sufficient. on that. Might work for some coaches, but for some others, they might, that might, that that might be fearful. That might be, how do I, how do I keep justifying my existence? How do I show the impact? And maybe that's how, you know, a DevOps engineer is either that coaching role, and it's just been maybe mislabeled, or there's a real misunderstanding. And whoever's brought that role in has thought. You know, this DevOps engineer is going to make DevOps a thing here. It's, they are going to set up DevOps. And any questions about DevOps, we'll send to the DevOps engineer and, uh, and that'll be kind of siloed and, and containerized over there. And that's wrong. You know, that really, And I think that's the thing that really brings down the whole point of DevOps, which is about bringing development and operations together, and, creating collaboration and creating fast feedback loops and all sorts of things. the DevOps engineer. Uh, I, I don't know. I, so I think it's just very confusing. and I often, when I work with clients, I am the first to say, when I see all these roles on LinkedIn, you know, the DevOps engineer or the, the head of DevOps, it's a bit of a warning sign for me.
Darin
00:06:40.509
direction. So, I think we all agree that the coach, so Agile coach, DevOps coach seems reasonable, right? You need some help getting started. The flip side of that, that as far as I can remember, there was never something called a waterfall coach. Right? I can't now, okay, Scrum Masters and everything else, blah, blah, blah. Okay, whatever. But I never heard of a waterfall coach. Is it because waterfall was something that was concrete? And what's easy to follow, whereas we'll go to its cousin, Agile isn't, it's just more of a concept. Am I, how far off track am I on this?
Tim
00:07:22.899
Well, I mean, I think there, it may not be called a waterfall coach, but there are lots of bodies and certifications and frameworks, like Prince2, you know, like Microsoft Projects, the Gantt chart, all of that stuff. Helped facilitate and introduce Waterfall. why was there not a Waterfall coach? I think that the difference with Agile and DevOps is that it's trying to drive, they're trying to drive, kind of self organization, self directing, self correction, self learning The nuance between Agile DevOps and Agile is that idea of empowering and facilitating others to think a different way. Whereas I think Waterfall was a little bit more of a top down, it's a methodology, you follow this. So there is still training, there's still education, there's still tools, but it's sort of the project manager or the program manager gets that and then they install that Waterfall. governance in place almost. And it isn't, everyone else just follows them. Whereas it's much more of a collective when we have agility and DevOps culture in place.
Viktor
00:08:37.638
it. It's also because Waterfall is not really contradicting how managers were used to work outside software industry, right? At least back when I was young, most managers are not. People who ruin software, right? Oh, I'm a manager, right? I can manage whatever you want. And if that's software, that's fine. And how do I manage? Well, I define requirements of something, whether that's a building or a software, doesn't matter. I figured out who's going to do it. I figured out how they're going to do it and the steps A, B, C, D. And then, then it is done and he, then I track time until it's finished. Right. I feel that there was never a need for Waterfall coach, because Waterfall is not conceptually different than that same manager working on anything else.
Tim
00:09:34.755
Yeah. And it's just, it's very methodical. It's very, It's like following a recipe. You just do this and do this and do this and, you know, time this and, you know, tick this off when it's been done. So, uh, there's a lot more complexity, I think, involved, when it comes to, embracing agility and, and, uh, more kind of collaborative practices like that. Hmm.
Darin
00:09:55.861
I don't know. The way that both of you just set it up, I could have replaced Waterfall with Agile or DevOps and the same thing would have happened. The way I've seen them implemented in most places, that people still try to apply the Waterfall or the top down methodology in something that inherently isn't supposed to be top down.
Viktor
00:10:15.458
That's what goes to my nerves and I, I might be offending somebody here. Almost certainly be agile that. Over time, we got people who figured out something like Scrum, doesn't matter, or whichever other methodology. And then that became religion and kind of, if you're not following this, you're not doing it right, right? Oh, it needs to be, I don't know, five minutes stand up. It cannot be six, it cannot be four, because the higher entity over there is Decided that that's how we should be. And I feel that all the people, whether that's right or wrong, it's a separate discussion, but all the people that follow certain agile methodology up to the letter are going directly against the idea of it, like directly against the concept that we should, and this is my interpretation of, of it all kind of, first and foremost, we should be adaptable. We should adapt to changes. Right? And then somebody comes and say, no, no, no, no, you're not going to adapt to anything. If you haven't done a standup today at seven o'clock in the morning for five minutes, not a second longer or second shorter, you're not, you're not the team player.
Tim
00:11:40.206
It's a really good point. And, I think what you're. Stumbling upon here is a difference between Agile and an Agile method, or being Agile and doing an Agile framework. Now, when I've coached teams, to adopt Agile, do often start with one of those frameworks, like Scrum. I respect the frameworks. I think, you know, the frameworks have become famous and globally adopted because there's good stuff in there. And I do, especially for immature teams, I say, look, let's, let's follow the rules at least for a month or two. Right. And, you know, the scrum guide has got a lot of good thoughts around, you know, durations and the order things happen in and how, you know, how many weeks and so on. And, uh, so I do like to respect that. Now, here is the indicator of a maturing team, a team that's becoming more high performing. When they come and say to me, hey Tim, why do we wait two weeks to do a retrospective? Why do we have to do these every other Wednesday afternoon? Would it not be better if, if we did these retrospectives a bit more regularly? Like, you know, Or, why don't we just have a real time retrospective board up, which is a practice I love to adopt the team start to realize that actually we could adapt this and make it better for us. you know, another one, why do we wait to the end of the Sprint to ship the release? The product note I'm sitting over there, on day one of the Sprint, we might have, we might have, um, got this cool feature done, so why don't we just go and Talk to the product owner, make sure the definition is done and satisfied. And if everyone's happy, why don't we just push it into prod now? You know that again, this is us maturing and adapting the framework. one last example. Why do we do these stand ups every day? These 15 minutes? Okay. It was good. It got us, got us talking every day. It was a good ritual. But hey, we do mob programming now. We're, we're, we are always working in pairs and mobs. So we're kind of in sync with each other. So do we really need that? Now, when this sort of thing happens, I think, well, let's adapt the framework. so I kind of think agile frameworks, they're almost like guardrails to get you started, to keep you on the straight and narrow, right? And that's a good set of guardrails. But bring the guardrails down when you can become, you know, higher performing and you're maturing to a level where you don't maybe need those guardrails as much. Now Waterfall, I think, is a set of guardrails which are pretty rigid and they, they're going to stick around, you know, these phases are going to happen no matter what. So it's difficult to bring down guardrails with Waterfall. And I guess it's the flexible nature of Agile and DevOps, that allows us to bring down those guardrails at the right time.
Darin
00:14:26.767
Many times we hear about big A, Agile, and little a Agile, right? Am I doing, doing the frameworks or am I just trying to be Agile? I was just thinking, I've never heard us talk about having a big D DevOps and a little d DevOps. Is that even possible?
Tim
00:14:43.036
It's a very good point. That's a very good point. I think, you know, Agile, as I understand when the 18 guys met back in 2001 and built the Agile manifesto, some discussion about what they called it and, uh, I believe if the story is true, adaptive was the word that resonated the most. but one of the guys, I think it was Jim Highsmith, had already written a book about adaptive theory and there was a concern that maybe he would get all of the consulting and all of the money if that's what they called it. So they came up with Agile. And I think the nice thing about Agile, it, it's kind of a, it's a, it's an adjective and it's a noun. So you can be agile, you can use agile, you can do it. So it's a quite, quite an agile word. DevOps is a little bit more, how do I put this? it's a bit more of a, it's a bit of an ugly word, really. And I, and I think, I often find people think DevOps is this techie thing. Um, especially business people, I, they, I can't, you know, get them to, they're not interested in learning about DevOps and I think they're the people that will really benefit from it. So, I don't know, it's, um, I suppose it came from, you know, merging these two words together, development and operations. So the way the title was structured was a little bit different to the way the title of Agile was structured. Maybe that's why we haven't had the little D, big D. Uh, but, but I think the same challenge exists of doing DevOps versus. being advocates of the DevOps philosophy, which is probably the longer way of putting it, and that's what I try to coach. It's like, let's embrace this philosophy. Let's embrace this ideology. and let's use these methods and frameworks to help us achieve this idea. And it's more of a world of continuous delivery through DevOps.
Darin
00:16:34.955
I think Viktor, the next time we have Patrick on, we're going to have to ask him that question. Since he was the one that coined it anyway, just because. I, it never crossed my mind before. It's like, okay, I'm used to big A, little a, but why not a big D and little d? I don't know. I don't know. Anyway, Patrick, we're coming for you next on that.
Viktor
00:16:52.883
I feel that Agile is something that is thought through in terms of. Rules, in a way, right? Oh, this above that, that above this, and so on and so forth, right? Well, I feel that DevOps is a much broader idea, right? Uh, we cannot have teams like developers and operations living in complete isolation. Uh, we need to somehow enable self sufficiency. Right? Without really prescribing, Hey, I value this more than that, which is what Agile did. So I feel that that's part of the confusion. And I also, people freak out when I say this, but I think that Agile is, sorry, that DevOps is in a way, improved version of Agile on a single point. I think that. One of the important, maybe not part of Manifesto, but one of the most important things of Agile was, hey, how can we make those teams self sufficient, right? How can they move at their own speed without depending on the rest of the company and waiting for something to happen, some miracle to occur, right? But in practice I think that that failed miserably because Agile team simply forgot about half of the company. You have developers, you have testers, you have some kind of a manager, product owner, whatever it's called, and they move And there, they work as one entity and they move at their own speed, and then they say, okay, I did the last commit for this release to git repo, I'm done, we are finished, success, big party, two, two, two week sprints, finished, let's move to the next thing. As if, that's it. You know, like, as if they completely forgot those things, that, you know what, but that thing needs to be built. That thing needs to be deployed. That needs, that thing needs to be observed in production. You know, there's so much work done. And you are subconsciously ignoring all that. You're done. We never got to the definition in Agile teams, in practice, of what is done. And whenever I spoke with people and, okay, so what's your definition of done? I never got the, the, the answer that says done. It's running in production successfully.
Tim
00:19:44.469
and I would go one level further than that. Running in production successfully and being used. You know, that feature is being used and adopted. Yeah.
Viktor
00:19:53.359
I agree. That's what I meant successfully. Kind of, you know, broad definition. Kind of, we are observing it in production and it's running correctly and all the metrics are fine and users are using it. What's not right?
Tim
00:20:05.149
I, I'm the same when I, when I, um, when I run workshops and I like, I love, I love the practice of definition of done. I just think it triggers this conversation and you get such a variable answer. You know, for some people, it just means, well, if I've done, it means it works on my laptop. I've checked the code in, maybe not even checked the code in, maybe it just runs locally. And as far as they're concerned, I'm done. but it should be thinking about, you know, running in production and being used. you triggered a thought there because I wrote a blog post several years ago and I, I got a bit of heat over it because I, jumped on the fact that people were adding Sec into DevOps, DevSecOps. And then I'd seen BizDevOps or BizDevSecOps. And then we talked about the designers and it was BizDevsDevSecOps. And I, and I made this point, it was all a bit ridiculous that, you know, we were doing this and I think, I think some people thought I was advocating, I was saying, look, I sort of look at the two ends of this value chain. One, there's some users, and at the other end, there is those users getting value from features that are deployed and used. And I think a DevOps philosophy, and others might disagree with me, is about everything between those two steps. You know, and that, that is basically incorporating, you know, what people would say is design thinking and agile development and development and operations. And it's finding Ways to bring that collaboration and silos down so that we can get value flowing through that chain as regularly as possible. And uh, yeah, so I always cringe a bit when I see DevSecOps and biz DevOps and all of that. Yeah. It's funny.
Viktor
00:21:49.353
I feel that that's ridiculous, right? That's people misunderstanding. What's the point? The point is to deliver this thing to production successfully and confirm that it's running successfully, that users are accessing whatever. Let's say observe it in production. If you define it like that, what do you mean DevSecOps? I mean, if you think that security matters, then you're part of that chain, right? Whichever part of it is missing, you need to become part of it. DevSecOps is, in practice, yet another silo. Okay, so this is how security people can continue working by themselves and tap themselves on a shoulder to say, now we deserve bigger salary because we are not security experts anymore. We are DevSecOps.
Darin
00:22:39.269
I'm just sitting here trying to not bang my head against the desk because all of these things just send me sideways. I'm trying to temper myself right now. Just, um, I'm being calm. Why does this continue to persist after all these years? I mean, I've seen agile coaching come and go and come and go again. waterfall scrum pretty much sticks around. Like I'm thinking airline manufacturers. I want them to follow waterfall methodologies to the nth degree. Now, doesn't mean I don't swizzle some agile. Within some of those steps, but I want to make sure the wings are on. I want to make sure the wheels are on, uh, before it ships. And I don't know that agile is going to cut it that way because, you know, we're talking about agile, it's like, well, okay, it's ready to go. My part's ready to go. So why don't we just ship? Cause not everything else is ready to go. Okay. Let's play this out for DevSecOps. Let's say it is true. Uh, and I'm working in a regulated industry, pick bank, broader finance. I've got a new app out there and I'm deploying it worldwide and I'm capturing lots of personal information and we ship it without getting it approved by security, governance, legal. And we launch in Europe and guess what? Now I've broken every freaking rule that exists in Europe right now.
Darin
00:24:20.907
Oh, it does. I'm not saying that it does, but I'm saying it's a more rigid rule. structure than what I've seen with most Agile structures. Am I way off on that or did I just have a bad experience?
Viktor
00:24:39.447
Yeah, I mean, they're doing as waterfowlish as it can get, and it failed big time.
Darin
00:24:57.317
Well, that's it. There's a lot of other broad things within Boeing. And again, I'm not going to throw them under the bus, but just stating that, you know, high level, that's why I want really structured things for things where life and death matters. But most of the time that we write things, it's not life and death. Or is it?
Viktor
00:25:26.086
Uh, but I'm still going back to the, my previous question. Now I'm, I'm putting you on the line, Darin, kind of like, why, Why do you believe that, well, let's forget about belief in practice. Do we have any indication that waterfall gives you more, more secured safety?
Darin
00:25:50.886
Yeah. The answer is no. There's no, based on what I've seen, the answer is no. Do I think more top down gives me more safety? Depends. Am I really going off the rails?
Tim
00:26:05.538
Well, I'm, thinking about the airlines that you're talking about and safety being paramount importance. And, and to be honest, you know, any industry safety is important, but I, I want to turn what really is safety and how safety can prevent, some of the disasters that we see in the news or, you know, big problems happening. And I think it's actually lack of safety at the team level and the individual level, because any movie or documentary I watch about any disaster, you know, whether it's a Challenger space disaster, whether it's about the Boeing planes falling out of the sky, I look at what was the real problem there. It was that the people developing the parts, developing the technology. did not have safety to feedback, to challenge, to say no. Yeah, so the pressure of top down leadership, the pressure of a rigid plan, overtook what the actual cleverest people, the people who were building this technology were all sitting and thinking, they could see problems. They were being rushed. They weren't putting the kind of infrastructure in place that they would want. They weren't being given the space to write automated tests. And ironically, the, the fear and the command and control, and the lack of safety that resulted in that had a ripple effect into actually putting a lack of safety into the product that resulted.
Darin
00:27:45.250
have time. I've got pressure. I don't have time to write tests. I've got to do all these things. I've got to ship because somebody made a promise.
Viktor
00:27:52.586
Sometimes it's not, it's not necessarily that, Hey, you should always write tests and you should always do this or that. I think the key is what. Tim just said the ability to, um, say something, right? Sonos is a good example. It failed big time, right?
Viktor
00:28:17.996
there we go, right? And even they admitted it, so we're not fresh talking now, anybody, right? Uh, and what was the problem there? Uh, what I can tell you actually what's not a problem, and the problem is not that nobody knew that it will fail. Right? Many people knew and were, uh, expressing their concerns about how bad it is. It's just that they were never given an opportunity to do anything about it. Which is the result of following the plan, right? Plan was made. even wars are not done in waterfall model anymore, right? It's not kind of, this is the 60 day plan, go invade and do this on day one, do this on day two. Right? Even military, which is probably the most rigid institution that exists in this planet, is actually more agile than waterfowl ish. Kind of, this is the plan, go on a field and then adapt. Do what needs to be done.
Tim
00:29:25.607
two thoughts that sparked. First of all, I completely agree around wars. this is the dark side of, of agility. You know, I look at the way terrorist organizations organize themselves and they set intent. Uh, they don't tell people what to do and when to do it as such, but they, they set a vision and an intent. And. The, the, the teams out there, the groups of people pick up on that and execute. Um, that was one thought. The other thought, I think on, on the, you know, the, any, any organization hasn't got time to write tests. Yeah. And I agree sometimes that's, that's the right decision. Um, I work with many organizations and I, I love to run a practice called priority sliders, but. Or trade off sliders, I think I'd last seen call it. And this just visualizes and gets alignment on like what's important to us right now. And it might be, I'm a startup with my runways running out. I need to ship something live. I need to test a concept. The tests, all of these tests and infrastructure robustness, it's low priority at the minute. So I need to visualize and communicate that to the team so they know that and they can build that into their work schedule. if I'm an airline or a bank and I'm working on some absolutely critical update that could, you know, destroy our product or cause absolute turmoil in the market, if we get it wrong, All those automated tests are pretty important. And I think it's all a case of relative, prioritization, which will change over time. It will change based on lots of different conditions. I think the important thing is to get the alignment and to visualize that so that everybody is working towards those priorities. And that's what will drive whether or not we build in these practices at this point or not.
Darin
00:31:14.626
But doesn't that get us back to the safety thing? Okay, let's, we were talking about other agile things, the Andon cords that were popularized from Toyota, right? Somebody on the line could pull anybody, like if something's going sideways, they pull the cord.
Darin
00:31:30.516
And we like to say that we're doing that, but if you are a junior level developer, that's 19 levels down from the technical architect, That only knows how to use Visio or what does it draw IO nowadays and PowerPoint. Then you see something, you try to say something, but now you got to go up 19 levels to actually make any kind of effect. And it's like, why bother? It's like, I'm, I'm, I'm nothing. How do we help people that either believe or structurally are at the bottom of the literal bottom of the food chain? And they see something. They don't have as much power as somebody that's putting a car together,
Tim
00:32:20.040
I mean, I think that's why I love those practices like the And, Encore, and Stop the World event. great leaders will encourage those kind of behaviors and that kind of mindset by really, driving those practices and, um, encouraging those practices. And it has to, it has to start with the leadership. The leadership have got to create that. Entire ecosystem of psychological safety and, need to show. To others that, that it's, it's okay to, to call out, you know, and recognize the people on the ground, even the, even the 19 year olds, that's, you know, just an intern or something, if they're working close to the technology, they know better than the leaders. They're, they will see those problems before anyone else. And it's okay to report them up. And I think there's lots of tools that, can help visualize and help. Create those little feedback loops, and it's really up to the many levels of leaders to encourage that culture, so that safety is observed and also experimentation is embraced. we want to encourage the idea that we should try things out. we want to get better. We want to continuously improve. Gosh, in today's market, it's harder than ever to beat competition and being challenged all the time. , the only way that we will stay relevant is to innovate and experiment. but that message has gotta come from the top.
Viktor
00:33:46.415
Problem with transparency, right? In a non transparent situation or team or company or whatever. You know, you can pull that cord and say, I'm not continuing without tests, but if company is not transparent, you're going to feel very strongly about it, right? If company is transparent and you know that, for example, you have only two weeks leeway, runway until you go bust, you need to release this, even if it's not tested, then the situation becomes very, very different. And very often, at least I didn't, long time ago when I worked in similar companies, I had actually no idea what's going on, right? I really did not understand what are the true business goals of a company. And without that, how can I pull that cord and say stops, world stops? I have no idea.
Darin
00:34:43.949
but we're sort of still stuck in the same problem though. Tim, what you were saying is, I believe is true. It's got to be coming from leadership, but then we get back into the top down thing again. So we start, we get into this vicious cycle of, okay, we, in order to have safety, the safety needs to come from the top down. So that's good. The corollary to that is. Bad leadership will allow anything to happen,
Darin
00:35:12.122
or not. Well, they, they not allow, I guess it's both, uh, not allow anything to happen, but they also allow anything to happen because they are checked out. They're more concerned about getting on the back nine of the golf course than they are about making sure that they, you know, actually make sure the company is successful. I mean, it's, it's, it's a very fine line, I guess, again, based out of where I've worked over the years, it's the places where I've seen, where it's been smaller companies have been more successful in shipping faster, more successfully, we'll say it this way, done, than I've seen with bigger companies. Now bigger companies will get there, but instead of it being six months or maybe a year, it's five to 10 years. Like, okay, here's, here's one that's very close right now. at time of recording, SpaceX has been launching and launching and launching. Forget all the politics. It's amazing, right? SpaceX just goes. Blue Origin got their first rocket up with a test with, uh, New Glenn went up. Now, You think about it, those are two, probably going to be the two major ones. Think about, we'll go back to Boeing. Again, not to throw them under the bus, just stating facts. Last year, they launched Starliner. How many years did it take to get Starliner up? They had two astronauts on it. They went to the space station and they got stuck because Starliner couldn't get back. So now they're going to come back on SpaceX. SpaceX. From day zero, looking from the outside, I don't know anybody on the inside. It's very interesting how it appears that they came out of nowhere, but in reality, they've been turning. And if you go back and look at each one of their little launches, each one of the little ships to launches to now, you know, number seven of whatever their big ship is, is scheduled to launch again. I have to say, when they caught it with the chopsticks on whichever number that was, five, holy cow. I didn't think I would ever see that in my lifetime. But now reusable rockets from a SpaceX perspective, New Glenn, by the way, I heard what they weren't able to capture. That's fine. That was their first one. Think back to SpaceX's first one. It was a complete failure. Their fail videos are better than sometimes their actual success videos because they're Not, not with people. Unfortunately, people haven't been heard. Why am I going on this rant? Uh, just because something is been around forever doesn't mean it's always going to win. This is the Boeing versus SpaceX at this point. SpaceX is eating Boeing's lunch in that area. Actually, they're eating everybody's lunch and dinner.
Viktor
00:38:19.799
When disruption comes and eventually it comes to every industry, I would say that what you just said, opposite of what you just said, being around for a long time is a, is a problem
Darin
00:38:33.299
It's a detriment, right? It's a detriment at that point, because you've got, you have built out this whole big thing over the years and you follow this process. And then here comes a bunch of snot nosed kids thinking they can do it and they actually do it, and you still can't do it.
Viktor
00:38:52.349
In practice, we saw that it's very hard, close to impossible to counteract disruption when it happens. Every time we saw a big disruption, that meant disappearance of those who were here for long, the industry is. Like, we are seeing that now with, with car industry, right? Mercedes is closing, uh, factories, the, probably the most important car automaker in the world, because they, they cannot react to disruption.
Tim
00:39:31.343
it's funny that you, Darren, you, you raised a space race. I heard a story about. The success of the moon landing in the sixties and, um, the story was around, I think the president of the United States at the time, I think it was Kennedy, doing a site visit to NASA. And he was visiting the engineers, the designers, the architects, everyone. And then in his walk around, he saw a janitor in the corner of the room. And he went over and he introduced himself and he asked the janitor, what was he doing? What was his role? And he said, Mr. President, I'm helping put a man on the moon. And I think that mindset is what achieved that success. Everybody was focused on the outcome. Everybody was focused on what is the big thing, the big moonshot landing that we're trying to do. And I think, With companies, uh, legacy companies, sometimes that gets lost with the many silos and the structure and the organization and the competing leaders and the politics that people lose focus of what is it we're trying to achieve. And I think, so some of these newer companies, they, they are relentlessly focused on the outcome. And, um, you know, back to Victor's point earlier around the transparency across the organization. So that people can see what each other are doing and they work with each other and they, they understand what they're, how they're helping achieve that big, big milestone, that big hairy audacious goal that they're trying to achieve.
Darin
00:41:14.832
But then once they get into that rhythm and they achieve it done, then they think they're actually done. I think that's where we all mess up, right? Because in reality, nothing's ever done.
Darin
00:41:33.267
Like it, it's, I mean, it's, it's, it's done for now. It's done for today. It's not done. I think the only time we're done is when we're six foot, six foot under the ground, then we're done.
Darin
00:41:49.846
but, okay. So that actually, let's spin it differently. We, we say that semi jokingly and some somewhat morbidly, but now you've got like James Earl Jones. Signed away his voice for eternity, for usage, and his kids and his grandkids and everybody gets residuals off of him. I mean, what used to be done, death, can now maybe be never happened,
Tim
00:42:21.813
never done. Yeah. I mean, I often say. Products are never done until you shut them down. You know, there's always going to be maintenance, improvements, enhancements, ideas. And you're right, even when people, man behind the voice goes, there are now ways that, that things will live on. So. but the adoption and the usage, may change over time. And this is where I think strategies right from the top continuously evolve. So what might be the focus this year to get done, it'll be different next year because something else will have changed, the market will have changed, the environment around us will have changed, competition will have come in. So strategies are continuously evolving. so the most successful companies are where communication of strategies and feedback and learning from the delivery is in a constant, system of work. So it's continuously adapting and that's back to that word, adaptive and how adaptive organizations succeed.
Viktor
00:43:27.533
here's a question. It's been quarter of a century since we were introduced to Agile, right? When do we give up on companies transitioning? When do we say, okay, so will there ever be a moment in the future, if not now, that somebody comes and say, Oh, maybe I should try this thingy. And then we say, I mean, it's too late for you, man. give up.
Tim
00:43:57.940
So this is my personal approach here. I give up whenever I look at an org and I think it's so simple, what you do is so simple, I don't think you need Agile. You, you, this, this, and you know, I am not anti waterfall. I actually think there's a place for it in many organizations. And I think, don't, why, why are you, you're, you're, you're adding a headache. You're adding complexity where you don't need it. Just, follow this methodical process. So, this recipe, just keep doing it. Okay. If your context changes and it's something not so simple, then maybe we'll, we'll look to introduce it. So that's, that's where I give up. The word Agile, I don't know, I'm seeing a lot of negativity towards the word Agile or the word DevOps or the, you know, and it's been replaced over the years. You think, you know, Agile is kind of replaced by DevOps and then platform engineering and site reliability engineering has come in recently and, OKRs have come and gone. product thinking, product mindset, product organizations. There's a lot of focus on that. So they get dressed up in different, different words. I, I guess I try to avoid the buzzwords and say, well, let's not try and be agile, but, but talk about the behaviors and talk about the, kind of the concepts and philosophies of. iteration and collaboration and incremental building and connected outcomes and things like that. Cause that seems to resonate much more.
Darin
00:45:24.639
I think what you were just explaining there is leadership. And I'm using leadership in a broad term, not necessarily the C levels, but leadership is not painting a, this is going to be too buzzwordy, painting a vision clear enough that the people are able to take it and run with it.
Darin
00:45:46.899
That's because they don't know because they're answering to somebody higher. That leadership's answering to somebody higher versus, okay, Hey, we've got this website that we need to get shipped, or we have this application that needs to get shipped. And its purpose is to make sure that the user of this application is able to transfer funds from one account to the other without fail. And that's it. That's all we're going to do for this first launch. Go. Now we know there's going to be lots of rough edges around there. We're going to have legal to me. I could take that and run with it. Now I have lots of questions, but it's very clear what that is. And it's pretty rare that I ever hear it that clear.
Tim
00:46:30.716
Yeah. It's either that kind of granularity isn't understood or known by the leadership or I don't know. I see an awful lot of, uh, leadership's vision. being written down into an email, they hit send to all employees email list. And they think that's it. I've communicated my vision. I think everybody in the org will have now downloaded that vision into their heads and they fully understand it. what they don't realize is that there's usually a lot of nuances, a lot of conversations, a lot of research that's gone into that. And there's no way that can be communicated in one email or one all hands meeting. And it will probably change. It'll probably be out of date very soon. So this is where, the collaboration from the leadership and it being a two way conversation between the leadership and the teams and the individuals on the ground and feedback loops being built into it is where strategies will succeed. So it's, yes, communicating very precise things like the example you've given, But also having an ongoing dialogue as strategies evolve and having the teams be a part of, of evolving those as well.
Viktor
00:47:40.350
That would be a brilliant business. Imagine doing consulting and saying for 500k I can reorganize and improve your company. You get money wired and you send an email and say I'm done. Here it is.
Darin
00:48:02.410
but that would reinforce, okay, let's play that out. The C level says, why did we pay 500, 000 for somebody just sending an email and saying it was going to make everything better at the company? And my response as the recipient of that 500, 000 is, well, that's all that you do. why would I need to do more? Because if you believe it's all working great now, that's all I needed to do. Then you get into the real work. And hopefully that leader would. I have enough intelligence to understand. Oh yeah. I've been screwing up all along. I probably should stay off the golf course and probably stay focused here a little bit more. So again, Tim is the CEO at Stellify. What's Stellify for? Is it going to help us in any of this?
Tim
00:48:52.441
I hope so. I mean, I am relentlessly focused on measurable outcomes and being able to visualize outcomes and connect them across organizations. you know, the word stellify means turn into a star or place amongst the stars. And my co founder and I had this vision that we could visualize teams outcomes and the way they measure progress towards them in a kind of star chart connections constellation way. but when we, as, as we, co founded the company, as we started to do user research, we actually learned a lot that. And I think that organizations need a lot of help. Teams need support, individuals need coaching to adopt some of the mindsets and behaviors that drives a connected outcome organization. we've adapted, we've evolved. And now we're more of a, of a coaching platform where we provide, uh, yes, the visualization and tracking tools, but, but also a coach in your pocket, a kind of asynchronous ongoing support. Uh, little and often as much as you need it until we see those measures, uh, surface and be visualized. so we're on a journey. I try to, drink my own medicine, drink my own champagne and, and, and realize that, you know, that vision is, is changing and we need to continuously learn. but, I'm having a lot of fun doing it I, I love seeing how our, our customers are using our platform for different ways and started to use it themselves as their own. Internal coaching tool. So, uh, yeah, it's, it's, it's been exciting and built upon, you know, the work I did at Red Hat and other companies beforehand.
Darin
00:50:23.369
So all of Tim's contact information and the information for Stellify, stellify. com will be down in the episode description. Tim, thanks for being with us today.