.jpg)
The Agile Within
Providing agile insights into human values and behaviors through genuine connections.
The Agile Within
Lessons from an Agile Journey with Max Dazer
In this episode of The Agile Within, I explore the fascinating Agile journey of Safety IO with Max Dazer, Agile Lead. Discover how Max navigated through frameworks like the Spotify model, Lean principles, and the Theory of Constraints to foster collaboration and break down organizational silos.
Gain insights into Safety IO’s innovative ecosystem planning and how the Theory of Constraints helped the team prioritize work, reduce wait times, and optimize delivery. Max also shares how embracing the Product Operating Model brought teams closer to business outcomes and bridged gaps across the organization.
Whether you're a Scrum Master, Agile enthusiast, or industry leader, this episode is packed with actionable lessons to elevate your approach to Agile transformation. Tune in now and take the next step on your own Agile journey!
Connect with Max on LinkedIn:
linkedin.com/in/maximilian-dazer-b43875199
Check out the Road 2 Mastery:
Follow us on LinkedIn:
https://www.linkedin.com/company/the-agile-within
Welcome to the Agile Within. I am your host, Mark Metz. My mission for this podcast is to provide Agile insights into human values and behaviors through genuine connections. My guests and I will share real-life stories from our Agile journeys, triumphs, blunders and everything in between, as well as the lessons that we have learned. So get pumped, get rocking. The Agile Within starts now.
Speaker 1:Attention, Scrum Masters and Agile enthusiasts, Are you ready to level up your skills and connect with the best in the industry? Well, the Online Scrum Master Summit is your chance to hear from world-class Agile experts, gain real-world insights and explore the latest trends shaping the future of Agile. Best of all, it's 100% free and completely online. Happening from June 17th through the 19th, this event brings together thousands of like-minded professionals for engaging talks, interactive sessions and hands-on workshops. Don't miss this opportunity to sharpen your skills and expand your network. Sign up now at onlinestrummastersummitcom. And now on to the show. I hope everybody's having an absolutely fantastic day out there today. Welcome back. This is Mark Metz, with the Agile Within. My guest today from Berlin, Germany, is Max Daser. Max, welcome to the show. Hi, Mark. Yeah, thank you for having me. So, Max, you and I connected a while back in a training class. Do you remember that?
Speaker 2:Yeah, it was the Road to Mastery, which was like a really great experience to have back in the days.
Speaker 1:Really was, really was, I think often about those times. So give a plug to Road to Mastery. If you haven't done that before, maybe I'll put a link in the show notes. How about that for our listeners out there? So, max, before we get further, I want to dive into our icebreaker question. And if I were coming to Berlin, germany, for a day and had never been there before, what's one thing that Max would say that I couldn't miss doing?
Speaker 2:I think there are, in general, like a lot of tourist attractions, but I know you're not looking for those. So I think Berlin has one really key feature it's decentral. So, depending what you like, you can go in a district and it feels like a completely different city. Like, just to name something, wedding feels completely different than to Prenzlauer Berg. So, depending on what you like, you can go to these different districts and you can even have like a really kind of posh experience or like more grounded experience, depending on the districts you go. And that's something I also really appreciate about Berlin.
Speaker 2:Berlin is a really honest city. When you go and walk across the streets, you will see a little bit exaggerated like a millionaire next to either some working class guy or even a homeless person, both drinking their beers at 7am. So if you kind of like this vibe, berlin will be perfect for you, no matter what. And I would really recommend going into different bars, like in Wedding, you have like a lot of great bars that are really for lack of a better word ancient, but in a good way. So that's what I would everyone recommend Check out Wedding it's one of my favorite districts and enjoy it All right.
Speaker 1:Well, max is an Agile lead at a company called Safetyio. They have been on a journey. Their agile journey has had lots of twists and lots of turns, and Max and I were talking. And Max, why don't you, if we're thinking of a timeline, and you've got that starting point over on the left and maybe you can picture, you've got a circle that's on the line and it says start here. Where are we starting at in our agile journey with safety?
Speaker 2:io? Yeah, that's a really good question. So I'm at safety ao since round about four years, like right after covet hit, and so when I joined it was like a purely remote company just out of necessity, and also relatively small. We were like 50 people around about around like six teams. The numbers might be slightly off, but that's the more. It's more or less true. And it was a company that was working in the Spotify model. You had different tribes and squads, all of this kind of language, and I joined as a Scrum Master for a specific tribe, so to say. They were doing software service solutions for worker safety, so everything that is, workers that work in safety-critical situations without going super in-depth about it. That's what we're trying to do that everyone can work in safety. And I joined there and was mostly really focused in this kind of squad level.
Speaker 2:I personally never liked the Spotify model, so I was always fighting against it because people might disagree. But how I approached the Spotify model for me it was like a strong metrics organization with different names. So it's usually a good way for a company of changing without really changing, because you just changed names. Like you don't have a department, you have a tribe and you then have squad instead of teams and when people like this naming that's fine, I always find it found it a little bit cringe, so that that was one personal uh opposition I had against this model. Were you alone in that sentiment? I think not completely. I think no one really liked the names, but we were also and that's across the journey seeing that this model didn't really help us to satisfy our needs.
Speaker 2:Because when I started, I didn't immediately jump and try to disabandon the Spotify model. I was focused on my teams. I was working with three teams and trying to help them. So there it was like for lack of a better word what I would describe as basics from master stuff, not that it's easy or boring, but it was really talking about. Okay, what does our process look like? Let's visualize it.
Speaker 2:Let's do a value stream session, talking about WIP limits, that maybe for a team of six people we don't work on 20 items at the same time, and why it makes sense. Introducing like different metrics, like flow metrics, wasn't big enable for us and working on technical excellence. So improving our test coverage and moving to like a continuous delivery from really releasing maybe once per month to nearly daily. What I'm describing here is like a journey over like a year and when we there, we had our different teams that were relatively high performing, but what we noticed that this doesn't necessarily result in a global phenomenon. And I think that's when we try to question the Spotify model. So I stopped here for a second because I could really go on big money log, but I was not alone. But I think for us to question the Spotify model, we really had to push it to its limit that we really feel it's not suiting our needs.
Speaker 1:Okay, so as a recap, make sure I'm understanding correctly. So when you came in to safetyio, the team maybe even at the department level or even the org level had adopted a Spotify model. And when they did that, they really were able to just kind of take their own processes and their own organization and just kind of drop it in as is and really didn't encounter a lot of resistance into the Spotify model. You did that for about a year. You start challenging something, so what's the next step in the journey?
Speaker 2:The next step. That's what I called like an ecosystem process, Because, without going super in-depth, but to give you like a high-level overview about our structure, we have cloud solutions, mobile solutions and also hardware devices. We approached every one of them individually. So software as a service was looked at as a product, the mobile solution as a product, the hardware solutions as a product and I don't want to get picky about names because it's justified in a sense, but when we approach it from a customer perspective, they want the entire solution because everything works together. They want the entire solution because everything works together, and we saw it on different features that just because the mobile team is finished doesn't mean the feature is done, Because there might be other teams who need to do something, and there this kind of Spotify model, which is really driven by autonomy, was something that we could not like.
Speaker 2:We were not able to create this much autonomy, even with domain-driven design, which was one way to approach it, that at least the software as a service solution doesn't have that many dependencies, because we were growing over this journey that I'm describing from like year zero we're joined to like year two and like initially doubled. So now we're close to 100 people and like round about 12 teams. So autonomy is still important, but we also realized our system, our organization, doesn't necessarily need to optimize for autonomy as much as the Spotify model, so I think that was why we questioned it. And this ecosystem approach was really based on a lot of different concepts. So I don't want to say that I didn't invent anything, but it's inspired by less theory of constraints, lean principles and really trying to embed this kind of system thinking in our approach and trying to identify when we think about a feature approach.
Speaker 2:And try to identify when we think about a feature, what does it really mean from a customer perspective? Do we need other teams? So this means we cannot only plan in the mobile part, but we need an ecosystem approach where we plan there first and zero constraints has something that I call full kitting, which means you prepare like everything. You need to know that a work item can flow through your value stream without being interrupted. That's what you're trying to create. Obviously, this will not work the first time and everything. Every reason that you're getting blocked. You should write it down and try to embed this in your kind of full kitting list. But that proved really valuable in reducing some of the wait time. Maybe one last example.
Speaker 1:Sorry to interrupt you, but what about that? Because you mentioned that there was a matrix-style organization that kind of had been embedded in there, that you were, I guess you assumed that, and so how were you breaking down those dependencies to move away from having these handoffs, so to speak?
Speaker 2:to move away from having these handoffs, so to speak. So I think that for now it's not completely about just removing dependencies, because we think about experimenting there more, but for now we have clearly embedded teams that work on the embedded devices and so we don't have like a cross-function team in that sense that stretches across different technical, technical domains. So we still have these dependencies. They are not that many like that it's the main thing we want to get rid of. Like it's not the main constraint. What we were witnessing is more that because everything was planned individually like if you have a product manager for web and a product separate product manager, if you have a product manager for web and a separate product manager for mobile and a product manager for the hardware device, they are not necessarily incentivized to prioritize a feature that another product manager, another product owner needs to say oh, that moves up into the backlog. So there we use one thing from less which says and it's maybe not also in Scrum but you have one product backlog per product. So ecosystem is the product. It means we should have one product backlog. So this means we need some way of visualizing the work for the ecosystem and prioritizing it at the start and that was the example I wanted to get into.
Speaker 2:What we can see, and it's a little bit of a made-up example, but a mobile team starts a feature and then realizing, oh, we need the web team. They go to the web team, say we need you, when do you have time? They say, oh, we're working on something we. We can start this in two weeks. That's like a good scenario.
Speaker 2:So what does the other team do?
Speaker 2:Because mainly organizations don't like idle time, which is another thing we could get into why this is bad, but usually organizations don't like idle time, so the mobile team would most likely start new work and then wait for the other item that is still like in progress until the web team gets to that.
Speaker 2:And in the best case scenario they just do their work and then everyone can continue. But the more realistic scenario is that they have questions and then you need to refine it, potentially with them. But you also started something else that also needs your attention and then suddenly you're having a split focus and from there on you're potentially in a bad multitasking situation that can spiral out of control. So what you're doing there to also approach from a lean perspective, you cannot limit your work in progress, because each team might, by accident, trigger more work in another team. So that's why we try to move it out of the team level and bring it to the ecosystem level, and I think that was really this kind of next iteration that also made us then abandon the Spotify model and the names.
Speaker 1:So I'm curious to know did you have a WIP limit at the ecosystem level?
Speaker 2:So I think we're using different things there and that's maybe also something where I'm a little bit biased. I am a huge bottom-up guy, so this means also especially my kind of where I started in the scrum master role. I started with something, my team experiment. If it works, let's roll it out, and that can make you sometimes slow. So, um, you need to mix it with uh, with top down, yeah, and the short answer is yes. The slightly longer answer is the first problem we encountered was there is no shared language how we talk about work. Like it's really hard to limit work when everyone has a completely different understanding about it. And I know that's right now abstract.
Speaker 2:But just to give like a really basic example, right out of Jira Epic, when we ask these different teams what Epic meant, we get different answers. For some, an Epic was it's a piece of customer value, like an independent thing that we could release and the customer gains something from it. For other teams, it was like we were seeing implementation Epics, testing Epics and so on, so like a kind of waterfall-ish breakdown into Word, which is another problem entirely, but still that's how they thought about work. Another team was using epics just to like store work. So they had. We had as an example, we discovered like a technical depth epic, which was like a immortal, because you would just whenever you found something, it was like, oh, we should fix this event At one point you, you just add it into this tech-to-concept epic and it was like a container of work that you would always pull stuff out.
Speaker 2:And from all of these versions we can debate what is right and wrong and how you should use it, and that can be an important conversation. But the reality was, well, we don't have a common agreement. Everyone uses the same word but has a different meaning there. So that's where we try to say, well, maybe let's and I know some people don't like it but let's standardize how we talk about work and how we think about work. And I think that was the first kind of key step we had to take in order to be able to limit this ecosystem, and that was like a crucial step. But then, yes, we moved to some way of limiting the ecosystem. It's a little bit harder to explain there because it's not as straightforward that you just have a limit of four features can be in the ecosystem. It's a little bit more complex there.
Speaker 1:So I often say that life isn't black and white. Many times it's some shade of gray in the middle. So you usually can't go from all the way from one extreme to the left to an exact opposite extreme on the right. So to give full, 100%, total autonomy to the teams to let them do whatever they want to do, I think everybody would agree that that system is probably going to fall apart.
Speaker 1:They're all off, kind of doing their own little missions, but at the same time, if you go all the way on the other end of the spectrum and say we're going to standardize everything and this is how the process is across the ecosystem and we're going to spell it out to a T, I think you probably wouldn't have many developers left right. If that was the case, they would be so frustrated with having to be told exactly not just what to do but how to do it. So it's how do you define that middle piece to negotiate, to find the sweet spot? And so I'm curious to know how, what that process was like for the, for the teams. I'm sure you got some pushback on some ideas, right.
Speaker 2:Yeah, and maybe also as a disclaimer, it's not that we're fully there. I think it's generally also really hard to reach an end state in these kind of product developments. It's always in motion. But something that's helped to find, or getting closer to, this kind of sweet spot, as you've called it. What personally helped me was the theory of constraints, because how I would describe it without going fully in depth with theory of constraints is because it's a lot, but I think it's kind of anti-dogmatic. So it's not necessarily arguing that you need to optimize for autonomy or something else. It's arguing try to understand your system foremost and try to then be flexible. And I give you one example of what I actually mean with that. So I've described this ecosystem approach, at least on a high level.
Speaker 2:The complexity in this process lies is sometimes a feature is purely in one technical domain and one team can handle it and can more or less deliver customer value and quickly iterate on it. But sometimes you might need all the teams in the ecosystem, which makes it a little bit harder than to like. You cannot approach it the same way. These two features, these two words would be handled completely separate. And to get more specific, even there, if something is purely in one team, you potentially don't need to have coordination meetings about that because it's in your team. You kind of capture this with all your team meetings, be it a daily or refinements and so on. That all should be enough to tackle that. But if you have a feature across an embedded domain, a mobile domain and a web domain, individual team refinements will not get you there.
Speaker 2:What helped us to find the sweet spot is again pushing this planning up front and saying let's agree on priorities and what we have to do first on this ecosystem level, let's apply this for-kitting approach, which means answering the basic question which teams do we need for that? Like, we have a customer problem and we want to solve, which teams do we need? We will not always be right and that's also not the goal, but for a lot of features we can actually tell which teams will have to do something. We cannot necessarily always tell how and what exactly they have to do, but we can tell they have to do something. We cannot necessarily always tell how and what exactly they have to do, but we can tell they have to do something. And if we figure that out, this also means they should have potentially some shared planning sessions, and the goal obviously, is that we can go back into our individual teams and then go back to autonomy and we just do our stuff, but we cannot start there. So, to recap it we just do our stuff, but we cannot start there.
Speaker 2:So, to recap it, we just didn't try to say, oh, we want to optimize for one thing, be it autonomy or be it 100% predictability. We said let's move this planning of work really upfront, move it on the ecosystem level, so out of the team level, let's agree on priorities here and when we do our full kitting and understand which teams we need, this kind of dictates how we approach the work. So if it's more dependencies, we plan it together, that we can understand the nature of the dependency and how we want to approach this work. We might have some kind of shared refinements and some kind of coordination meetings around this. If something is purely in one team, it's not part of this. Ecosystem coordination meetings as an example, because no other people need to hear about it. So that's one example how we try to be anti-dogmatic and not saying, oh, but our framework wants us that we do this and do step B, and I think that was really helpful.
Speaker 1:Customers don't care what framework you use, right?
Speaker 2:Yes, and I think also what we have to like. I can't be really specific here, but these teams work also in different processes right now. So our embedded teams were more in a waterfall-ish process, which we may want to change. But I also want to be honest that the main problem we're seeing right now is not that they're doing waterfall, that it's really not connected to that. The main issue we were facing is that priorities were set on the team level, not the ecosystem level.
Speaker 2:You might want to change the process and adapt it, but for us, it was really just helpful in saying we don't really care how you work, we can figure this out. Just let's get into one high-level shared process and everything else will follow from there, and that also, in my opinion, is really good to create buy-in, because we're not coming like the all-knowing gods and being graceful to them that we're finally paying attention to them and now they need to work like us. It's more like a shared learning experience, and that's how I in general like to approach it, because I don't know how to do good embedded development, being completely honest there. So I don't want to dictate how they work, but I want to figure together with them out what are our problems and how can we fix them?
Speaker 1:So I want to talk to you just a second and get your thoughts on this, because this is a situation that I've encountered in the past. And so the situation that we were in was we had multiple teams and a team was assigned to a product and they knew that product, they knew how to support it, they knew everything about it because that's what their specialty was. But then some products just like okay, for the next two quarters, we really need to dial back on this product. We're not getting the sales from it. Customers just aren't using it or they're happy with where they are. Where they really need is in this other product over here, Like maybe your software is a service solution, for instance. That's where we need to put our energy.
Speaker 1:So what the ask is from people that aren't in the software development side is well, why can't you just move the other? I'm giving air quotes resources, I hate that term, but why can't we just move resources from one team to another? So instead of having 10 on one team and 10 on the other, let's just put eight on one and two on the other, and that way we can make more progress, and the teams would really have a heart attack because they're like I've never worked in this system before, so it's going to take me a long time to ramp up. So that was another problem for us to solve of getting ahead of the game and doing some cross training and making sure that people did have that big picture view of the ecosystem, like you talked about it. But have you encountered situations like that and how did you approach those Max where you were being asked to shift the teams around?
Speaker 2:I would say we don't have this problem super severely, that we need to figure it out. I think what happens sometimes if we're saying one product, we want to dial it a little bit back, that we're saying why don't we just have one or two people from this team go to another team where we definitely need what there's like a lot of more work coming up there, because we assume that's where the real value lies. So I think there we have some flexibility. It's not necessarily that it's right now on feature level, because then also from a budget perspective, these people would then be added into like as resources and be then part of this new team and don't necessarily would switch around that soonish again. But what I'm trying to say we're we're not really that high in fluctuation, so it happens sometimes and then we can reasonably figure it out. But there it was not enough pain that we need to say, well, let's maybe look at, look at for lack of a better word for a process how can we figure this out and switch people around and then train them? This hasn't been the main problem, however. The other part of my answer would be what is really valuable in, for example, an ecosystem, because it can still happen inside this ecosystem. That we're saying for feature B that is now upcoming, we see 80% of the work on the embedded team and the embedded team might be four people, while the rest of the other software teams, be it mobile and cloud, might be 40. This can, like this is an important thing to be aware of, that. Well, maybe our constraint it for that feature might be embedded. Why this is important is, again from a theory of constraints approach.
Speaker 2:If you want to improve your system performance, you need to aim at the constraints. So you need to first of all and I know sounds stupid, but know where your constraint is. And that's not as easy to answer Because, coming back to our journey, where we were when we planned in the individual teams, if every team is working on like 100%, you have so much work, especially in like a knowledge work, that you don't necessarily see the constraint that easily, see the constraint that easily. So you need to really be thoughtful about this and do this kind of full kitting that I've mentioned earlier that you are able to tell where is our constraint. Because even in our ecosystem the constraint moves depending on the work, on the nature of the work. So it's not like that. We can say, oh, the constraint is always there and either we want to keep it there or we want to move it to a specific. So it's not like that. We can say, oh, the cost range is always there and either we want to keep it there or we want to move it to a specific place because it's moving. So you need to build also your kind of signals in that tells you where is it moving towards to, because if it's not embedded anymore and now it's cloud, you potentially want to focus your improvements there. That might be hiring more people.
Speaker 2:But finally, answer your question. What can be really helpful to understand is idle time is not an enemy. Not necessarily, because also from the constraint, the theory of constraints approach, the only thing that should work at 100% of its capacity is to constraint. So in our example, if embedded is to constraint, they should really work at their optimal capacity. All the other teams, if they are idle for this specific project or feature, it doesn't matter that much, like it would matter if it's so severe that the constraint suddenly moves really somewhere else. But this idle time you could in theory think about, can we use this idle time Like either they just start work that doesn't need the embedded team, so they just do other work. That's one way to approach it.
Speaker 2:But you can also say is there a way that we can help out the embedded people? It's not necessarily about making a mobile engineer become an embedded engineer, but is there some work we can help with? It might be some sort of testing, system level verification or other things, and it can be important to raise these questions. So that would be my answer to your kind of questions. At first we didn't completely have this problem, but something like theory of constraints can really help you to focus. That you understand. Do we even have this problem? Should we even focus on increasing, like hiring more mobile engineers, because maybe your constraint's not there and it would not really matter.
Speaker 1:Okay, Max. So we talked about starting off at the Spotify model. Then you moved on from that and you started taking some things from Agile, from Lean, from Theory of Constraints. Bring us up to where you are today.
Speaker 2:So one thing that I have mentioned and that becomes important right now that Safetyio is really engineering-centric. We're part of a bigger corporation where this ecosystem is really important and Safetyio it's purely engineering leadership. For a time, even the product owners, as we called them, were part of engineering. That's not necessarily bad, but you're hitting a glass ceiling because you're in your agile bubble and everyone is there, and then you have the rest of the business who are on another island, it feels like. So I think what we started there to give it a name was trying to use these principles from the product operation model, like framed by Martin Kagan, and saying we should involve the entire business and try to explain them why we work like this and why we can leverage this and also be then more customer-centric, Because with this high of engineering focus, it has a lot of benefits.
Speaker 2:But it can also sometimes mean that you're losing a little bit of customer contact In the worst case also getting into this kind of feature factory set that you can see you don't need to be engineering-driven for that. A lot of marketing-driven companies achieve that, but I think that is where we were stuck. We got to this ecosystem level and it helped a lot, but we still had like different parts of the organization, like sales and product marketing, that were really far away from us and I think, on discerning where we are right now in getting like embedding or implementing these product operational principles, this helps us right now of like bridging this gap.
Speaker 1:That's interesting. So what was the biggest improvement within the product operation model that you feel like improved the way that you worked.
Speaker 2:I think it depends how you want to look at it. Something we've done on an ecosystem level also was putting way more emphasis on goals. People can argue you don't necessarily need a product operation model for that and that's fair. But that's like a practice we did. We're implementing OKRs.
Speaker 2:But if you go not just looking at practices but more like also the principles, I think the product model kind of forced everyone to be more outcome focused so that you actually understand oh, that's why we could use something like okrs, because you can also use different ways of think about outcomes and ways to measure them. But suddenly this is was driven by different kind of departments for lack of a better word in this organization Like product marketing is now way closer to the engineering teams, making sure that we're setting goals in collaboration and having this kind of transparency on why we're doing this and the need for it. And I think that is this kind of biggest improvement of saying, well, we were on our island for a while, but maybe let's try to leave it and go back into our big corporation and seeing where we can align our processes.
Speaker 1:Did you ever have to have a conversation? And I'm asking I'm not telling If anybody that knows me, that's a famous tagline that I that I like to use to delineate. So I'm not telling this, I'm really asking but did you, did you have to, or someone have to, have a communication with the engineers to say we understand that well-engineered software is very important, but we're asking you to do more. The solution that we're not looking for, or the goal I should say, but we're asking you to do more. The solution that we're not looking for, or the goal I should say that we're not looking for, is wonderfully engineered pieces of software. It's meeting business outcomes for real users. Did you have any conversations like that where you told them what you're doing is important? We just need to expand out of that.
Speaker 2:So I think there yes, I think we obviously talked about why we want to do the product model and we had different reactions across the company, like some people said, oh, that's what we always wanted to do. And then I reacted with, oh, that's great, we're finally doing it. Or like, oh, we're doing this right now and always wanted to do it's just a new name. So we had these different kind of reactions. I think what in the product model, but also before, we really tried also from like a from management, for lack of a better word to help people to understand. You're not necessarily here just to create code. We want to understand are we actually making a difference? In order for that, we need to work empirical. So this means we need to have some sort of metrics that we're inspecting to see if we're making progress towards an objective. If we want to do that, we need to understand the business world, because for some stuff, you can maybe look at some performance metrics, and that's also important. If you really want to understand, if you're changing customer behavior and then also making an impact on your own business, you need to bridge these gaps. And I didn't think people like we're a big company, so I cannot say that everyone loves this change. But in our setups we we are still leveraging, like the, the basic scrum setup of having like a product manager, a cross-functional team, whoever they need, their developers, qas and design, and we always try to say we, we want to have like close collaboration. If you don't know how, that's also fair. Like, if it's really a problem that we don't know how to work with design, it's a fair point. Like that's also fair. If it's really a problem that we don't know how to work with design, it's a fair point. That's why we're on this journey and want to use this principle from a product model. Then let's figure it out and let's try stuff. So it's answering a little bit, but I think a crucial step was from also engineering leadership, saying you're not just here to write code. We still care a lot about technical excellence and pushing a lot of there.
Speaker 2:But you cannot just opt out and say, oh, I don't care about how we set up goals and I don't care about the goals, I just want to do something. We will not get rid of you. It's an individual. If they stand by that, that's fine. Like it's. If it's an individual if they stand by that, that's fine. But we also want to be clear that in like a career ladder that we're having, then you can only reach a certain point. Like if you then want to climb up to the next rank at one point, you need to then also embrace this kind of change.
Speaker 2:But really, for now at least, what I experiencing the teams are really open to that and again, some are positive, saying we wanted to do this always. Now we finally get the chance to do it. And for the people who said we always did it, it's just a new name, we just try to tell them that that's also not completely accurate. Like we need to be honest with ourselves that because of our engineering focus we had kind of reached the glass ceiling and it's not helpful to just say, oh, we always wanted to do it like that. Now a new word comes, let's embrace it.
Speaker 1:Well, max, you term this as a journey, and I think that's very aptly named, because it's not a destination. It's a journey that's ongoing, so you continue to evolve. I'm anxious to hear how your journey progresses. So thank you for taking us on this journey from a high level. About safety IO. It's been very interesting to hear. I always enjoy talking with you. If our listeners out there want to get in touch with you, what's the best way for them to do that?
Speaker 2:Mainly LinkedIn. I'm not really a huge social media guy, so if you want to find me, linkedin is probably your best chance.
Speaker 1:All righty, we'll put a link to your profile in the show notes to make it easy for everybody. Max, really appreciate you coming on the show today, buddy, it's been real helpful.
Speaker 2:Thank you very much for having me Again. I really enjoyed our conversation.
Speaker 1:Me as well. All right, everybody. That brings another end to this episode of the Agile Within. We'll see everybody next time. Thanks for joining us for another episode of the Agile Within. If you haven't already, please join our LinkedIn page to stay in touch. Just search for the Agile Within and please spread the word with your friends and colleagues Until next time. This has been your host, mark Metz.