Being Agile about Scaling Agile at Aras Software w/ Andrey Knourenko

Help me think through how this episode applies to my situation. Start by asking what I am trying to change. Separate the episode's claims from your suggestions, and say when the notes do not support a claim. Use the transcript to find passages, then check the audio before quoting. Transcript: https://yuvalyeret.com/podcast/episodes/being-agile-about-scaling-agile-at-aras-software-w-andrey-knourenko/transcript.md ## Published episode notes In this conversation, Yuval and Andrey Knourenko discuss Aras Software's scaling journey. They reflect on the challenges faced during the transition, the impact of COVID-19, and the evolution of planning approaches and team structures. The discussion also touches on the influence of private equity on agile practices and the need for continuous improvement in agile methodologies, particularly in the context of emerging technologies such as AI. "You have to be agile about agile." "It's about the speed of the whole system." Chapters 00:00 Introduction to Scaling with Agility 00:57 Understanding Ares Software and Its Journey 03:38 Challenges in Scaling and the Need for Methodology 05:31 Implementing SAFe: Initial Steps and Training 06:46 Outcomes of SAFe Implementation 08:28 Impact of COVID-19 on Agile Practices 11:14 Improvements and Trade-offs with SAFe 14:21 Team Structure and Mentorship in Agile 17:28 Evolving Beyond SAFe: Exploring New Methodologies 19:58 Tweaks and Innovations in Agile Practices 22:46 Analyzing Development Processes 24:12 Managing Iterations and Team Dependencies 26:53 Empowered Teams and Agile Structures 29:31 Adapting Agile Practices 32:59 Impact of Private Equity on Agile Practices 37:58 Navigating AI's Influence on Development 40:57 Key Takeaways from the Agile Journey Follow Andrey on Linkedin Learn more about Aras Software and its journey towards agility Yuval Yeret is a business flow coach for the age of AI. Yuval is focused on helping mid-market and scale-up companies such as ARAS Software tackle hard shifts/inflection points and regain traction, speed, and impact through nuanced agility interventions. https://yuvalyeret.com/ https://www.linkedin.com/in/yuvalyeret/ Being Agile About Scaling Agile at Aras Software: A Conversation With Andrey Knourenko – https://yuvalyeret.com/blog/being-agile-about-scaling-agile-at-aras-software ## Transcript This transcript was edited from automatic speech recognition for readability. Speaker turns may be wrong or absent, and it may contain recognition errors. Check the audio before quoting or attributing a passage. Episode: https://yuvalyeret.com/scaling-ai-podcast/being-agile-about-scaling-agile-at-aras-software-w-andrey-knourenko/ ## The friction around safe / scrum Welcome to the Skelling with Agility podcast. I'm Yuval and today with me is Andre Nureko from RSOF. And I'm really looking forward to the conversation because I like to look at the arc of the journey of Skelling with the agility that companies take. And in a recent conversation with Andrei, we reflected on the different things that happened in ours's journey towards agility and we thought it might be interesting to share it with a wider audience. Welcome to the podcast, Andrei. It's good to see you again. Thank you. We're good to see you again. We know each other for quite a long time and yeah, Thanks for having me. Pleasure. So do you want to share a bit with the audience about our software and your role there, and maybe how we met our journey start? So, ARAS is a PLM company, right? It's a PLM as a product, like cycle management, and not to go to in-depth, it's used by manufacturing companies, anybody who has designed, manufacture anything, right, a physical. And any object, kind of, from, I don't know, simple chair to rocket engines, it's a bill of materials, right? And companies go through, gather in requirements and design and change management and the manufacturer process planning and et cetera, et cetera, up to the maintenance and all this lifecycle of a product, right? And what's interesting, everybody does it very differently. There are certain kind of methodologies, but everybody does it differently. So essentially, you cannot just write one piece of software used by everyone. It has to be kind of a platform that has to be customizable, adjustable, right, configurable, et cetera. So because everyone does it differently, you need to adjust that software to the needs or build maybe specific applications on top of the platform. So this is what we have done with errors. be one of when I joined the ARIS 2005, it was a small company, maybe 20 people. So right now it's one of leading PELAM companies competing with big companies like Dassault PTC, Siemens. Yeah, so that was an interesting journey. When I joined there was a few people development team and as we grew, team grew and we needed some kind of more well-defined methodology and agile approach kind of that scales and this is where we met Yuvau. It's probably was what 2017 or something around that time. But we think yes. Yeah, he provided us with some safe training. And from there, yeah, we started practicing safe. And yeah, we can talk about this how kind of it's evolved over the time. Yeah, so funny enough, one of Andre's colleagues, John, found me for this, is not knowing that I'm already working with a couple of the other PLM players. So, Asimin has been a long time client and I've worked with PTC as well. The size, you know, still on my list, maybe one. They're up the road here in Waltham, right? It's like the center of the PLM universe in Massachusetts, right around, between 95 and 495. We have all the players well represented here in the area. So maybe going back to how we started. Do you recall what was the goal? What were some of the problems with the existing ways of working that made you think about we need something different? Yeah, we, as I said, we had a small team originally and probably by the time we started and we met with you, Tim Guru to about 50-60 people. Clearly, it was kind of difficult to scale it up without applying some of the formal methodology, right? And we kind of tried, somehow kind of grown, homegrown, you know, agile methods and whatever. I don't think we're clearly looking for something different, right, that can scale, that can have a kind of better, find kind of approach and how things needs to be done. Yes, John, who you mentioned was kind of leading this. We talked about this a little bit, kind of safe, or clearly scaled by JAL. So definitely there are some other scaled, a JAL methodology is probably even at that time, but we somehow decided, okay, safe, probably something based on the name Fitsas. And this is how John approached you and we started the training. I think the goal was again, as I said, to be able to scale, to be still agile, but to be able to scale across multiple teams. And most members of the teams were pretty young, right after the college, never practiced any kind of formal methodology. So I think Safe-offs would play the big role in teaching our developers how to apply formal methodology across multiple teams that apply in the gentleman. I think, you know, reflecting back how we started was the way I typically like to start with organizations which I think we didn't dive straight into safe training, we actually have done a workshop ahead of that to figure out does safe make sense here. What are the other approaches? What do we want to do? And one thing I still remember is we've done the speedboat exercise where I asked you to break out into smaller groups and try to draw. What do you think RSEs at the time? And I remember there was a conversation about as you were growing up, it became a fluteal of spin boats that needed to somehow get together and create the power of the the power of the scale that you have without becoming the massive slow aircraft carriers that your competitors are. So that was what we were. We were trying to do with the scale agility at the time. So and then as you're saying, we started the training and we started deploying and finding consistency. So let's maybe for the couple of months, years, what were the outcomes? Did it really help? I think it did. Ultimately, I can tell right now we switched to something different, but we can talk about this. But yeah, I think we, as you said, we did, you did some training for actually executive team and we discussed if it's a good methodology for us. I think kind of the leadership team was on board with implementing this and then we started slowly with I think one team and then couple team so we did not jump into this right with whatever five or six teams we had at that time. So yeah we for two three pis we kind of trying to increase number of teams switching to save that seems to be working I think people liked kind of that how things well defined you know the PI planings was a good way to everybody get in the same room and you know brainstorm and discuss so yeah I think I think as a result probably after a few PIs, again, I don't remember even right now exactly, we started, all the teams started practicing safe. And I think it went pretty well, as I said, it taught teams of way how to kind of properly I will define the geomethology and scale it across the teams. But I think just kind of think that kind of was disrupting was COVID, right? It was a 2000, the beginning of 2000, the COVID started. So we had to switch to online PI planings. planings. And that's I think you're kind of looking back. I think that's ultimately had the big impact on our practice of safe because it's one thing when everybody's in the same room, right? Everybody talks, everybody's kind of you see people, whatever you can approach people and different when everybody's behind the screen can hide. I think over the time people started using those formalities of safe process, right? It's a lot of procedures and whatever this is, this session, that session in Spakan Adopt started using this kind of hiding behind this to get less stress. It maybe was out of their plane and whatever they thought needs to be done down ahead of time, the junior player playing people just kind of whatever did nothing much. I think kind of that was definitely with moving from life face to face for a month to online, it's impact. Overall again I think safe is well defined but probably a bit too prescriptive kind of approach right and again in combination with not being able to mid-face-to-face most of the time right and whatever this that has its effect so yeah before we go to the changes that you've made which I'm really curious about if we reflect on its April or February 2020. ## What is really happening in the system COVID is making its way to the U.S. but it's not here yet. What are the improvements in R&D engineering business performance that you've been able to achieve with your safe-based way of working and what are some things where you still felt didn't work that well or what are some of the trade-offs that that safe introduced. Even before we we go to COVID. That's how COVID changed that but I think yeah as I said on a positive side we definitely was struggled to kind of scale across multiple teams kind of whatever methodology kind of kind of a job methodology we used at that time and save definitely was helpful because all the PI planings kind of opened boards like everybody understands what they kind of do, what's the plans for the next iteration. It was very helpful. I think that's increased also transparency. I think it was always with at that moment right before we started even safe. It was a little bit for people outside of each development team. Even for different development teams for product management, for anybody kind of marketing and other people's in the company was a little bit of mystery what's going to be in the next release, right? What's developing is working right now. I think the transparency is significantly improved because now we had common kind of boards, right? The common plans for the next PM. everybody knew so we our releases did not align with PI was different schedule but still I was a clear Which PI and what's done and this PI will go into which release so transparency and Predictability of what will be done? I think those two were for at least for the people outside of Development was I think was a significant improvements Sir yes Now, yeah, and therefore, for the developers inside the team again, it's brought some structure, some ability again to kind of understand maybe what other teams do and ability to apply certain methodology, the SPI planning week with iteration was quite good actually again when we did it face to face, right? We tried to do some innovation and kind of some hackathons during this week, etc. I think I was a lot of positive momentum going to February. And I thank you, recalling some of our conversations, I think, and you said earlier, a lot of the team was young. So you had a core of very experienced people, very, very experienced people from the early days and as you grew, you had a lot of people that you felt like deemed it to get up to speed. And that was at least one of the goals for using safe. And I'm curious whether you felt like these created teams and people that through the transparency, through what we've practiced, were able to get up to speed and become full players. Yeah, I think definitely again splitting in more organized manner into formal teams, right? And having each team some structure with a scrum master, with the ability for young people who joined the team to kind of learn from other members of the team. team each team has made a slightly different approach, how to do this, but still there was kind of mentors inside the team. So yeah, they definitely helped young people to, I believe, came up to speed much faster. And it's also again, to create some structure for them, where they kind of as a new people and not known product well, and code base well, kind of, that helped them to get up to speeds faster than before. I think we changed the team structure, the team topology as part of this, right? Actually, it's another interesting thing. First, a few years, we almost had very static kind of teams that didn't change, right? And then that wasn't one of lessons we just kind of realized, well, yeah, that's... stable teams good but not kind of forever, you know. So we start moving people from team to team and actually it's initially it's caused a little bit even pushback because people kind of started after a couple of years feeling like very comfortable and where they are but I think that's another maybe a lesson learned that if you let people to stay in that static position for too long becomes too comfortable. So you need to shake up things a little bit time to time. So we in the later years, especially when we became the remote and not everybody was sitting because we also kind of organized even offices, the team was sitting in the same areas, etc. But we call it all this gun and everybody started working remotely or primarily remotely that definitely changed and we also started moving more people in exchange between different teams. Okay, so what I'm hearing is the team structure if it's too static or too long you get comfortable and you don't challenge. Yes, I think the same it can be said about ways of working, right? If you get stuck in your rigid ways of working for too long, there's probably an opportunity to do it better. I mean, we don't necessarily need to continuously improve, but at least periodically improve. And I think it's a good segue to your realization that you might want to change some things in how safe works for you because of COVID, but maybe for other reasons. So, yeah, so we continued for a few more years, but I think we increasingly started feeling that kind of safe method that the team grew actually to overall we had over 150 people, some of them system teams, you know, a product security team and some devops teams a third but still the team grew quite a bit. At the same time, again, I think with the remote and people over the years finding the ways how to reduce the stress, let me put it this way, kind of, and the safe to be very kind of prescriptive, okay, you do that session, you do this and speak, I don't know, you do this. A lot of this turning to practicing for the sake of methodology, right, rather than for... I call it agile theater. Right, right. It's safe theater. Yeah, yeah. So I think we kind of we got increasingly aware that maybe something needs to be changed. And I think kind of a year and a half ago, a couple years ago, we probably a year and a half, we started looking for maybe something that can replace how we do things. You get to get a group of our kind of senior people from different functions, architectures, architects, flippers, gramasters, release management, etc. And I asked them actually to brainstorm to come up with how we can identify the way we the practice agile and we kind of identify what's out the biggest problems and how they can kind of suggest how we can change things. So ultimately we ended up with something based on less, it's a large scale of Scrum, right? But with some tweaks specific for whatever we do, right? And for our type of development and for maybe type of developers and development teams we have. Yeah, so we switched to that probably a half ago, maybe a little more right now. So I am curious what what I don't know we haven't talked about it before. So I'm really What does that look like? What are the tweaks? I think one of the major things was kind of we did not have those big product increments anymore. And didn't plan for the whole......your plant-based print. We print the spring by sprint that gives us more agility. It's also eliminated a lot of this again pre-planning ahead of time and then doing not much during innovation and planning, you know, iteration. So now every iteration was kind of view-kind of iteration, but people spend a small amount of time beginning of iteration of planning this and also ability to much faster pivot if it's needed, right? Which is in our business was pretty common. So one of the specific things for us we had something called the special team where was kind of group of mentors and each mentor was from also from different. Function like a Q a manager right and development manager and architect etc etc and. They all senior people and first each one of them was kind of responsible for a particular team, but your responsible maybe was playing a role of a matter. If a team actually doing excellent, that person has to do nothing. If a team has some issues maybe, right, or how to collaborate with some other team, right, split the vehicle because they're always dependency etc. And they cannot resolve it by themselves. So maybe those mentors kind of step up and help team to resolve those issues. Sometimes teams had some questions about how to address specific. And another thing again, these team also get together regularly and have their own kind of small. What does it mean? It sounds to me like what we call in next, Nexus is a scaling framework that's similar in ways to large-scale Scrum. It's the thing that comes from the Scrum.org world from Kent Schuiber. It has a concept called the Nexus Integration Team, which is responsible for the integration, for looking across things. So, looking across this year, how to kind of, if we need to do the tweaks, maybe in overall process, they were first to analyze it and suggest how we adjust why maybe single backlog. Doesn't we all going to have two different backlogs, one for whatever kind of new functionality and other. ## The practical shift So kind of topics like this when they're played with switch tools lately, especially kind of a lot of new AI tools, right, came into use and we started using something called DX. It's a development experience. It's one of the tools that measures development experience more closely, right? Because it has some, it's integrated with Visual Studio, with Git, et cetera, et cetera, right? It actually can tell you how many commits done by each team. Like this goal, right? So one of those, and that I think kind of very valuable, provided very valuable information also, right? And again, production on all these teams, sorry, all these tools, right? And kind of training for the team. That was all kind of responsibility of that, with a special team that kind of was. So I'm curious back to you stopped managing PIs. You moved to managing iteration by iteration. How did each sprint look like? What did the planning across these teams look like? and where these teams really self-sufficient, dream aligned teams, and how many dependencies did you have across teams at that point? There are dependencies, but I would say it was not very difficult to resolve them, right? So we definitely, we had a big platform, this is our innovator, it's a big platform. But I think whatever team worked on definitely had the dependencies, but we tried definitely to split functionality that way to minimize them. So, yeah, dependency existed, but I think not to extend that prevent teams to be significantly independent and plan their iteration pretty quickly, I think teams spend maybe a couple hours just the beginning of iteration to plan it prior to that week with before the iteration starts, I think it was kind of a common event with representatives of different teams to review the backlog and to decide kind of what overall with product management what the teams will be working on kind of next iteration. Yeah, so I think that's well, the reason the blue level. So maybe I think it's good for people to understand the perspective. In my head, there's a narrative here, which is that what I see in a lot of organizations is something along these lines. You can think about it as a flipped pyramid, which is essentially that often when I meet them, a lot of the work in the organization requires a lot of teams. It rewards even a lot of product groups and a lot of the time the value of something like safe makes sense because it enables you to, like you said, scale or tackle delivery when you need to incorporates deliverables from multiple teams. But there's a price that you pay for this. The price that you pay for the structure is yes, you can manage such a delivery release, a project across those teams, but there's a lot of overhead to it. And eventually what a lot of the the organizations that I work with, strive towards and achieve is this sort of structure, where most and most of the work can be delivered by empowered teams. And that's what I hear in the story that you're telling me and what I recall that we you were trying to create these sort of teams. The more of the work in the organization fits into these, This layer, the base of the pyramid, which is our teams that don't really need much from each other, the more lightweight structure you can manage. If I look at the conversation I typically have with organizations that are starting this journey, and it's probably similar if we had the AI recording our conversations back in 2017, we would be able to go back to it. But it was in person and we didn't transcribe. We were talking about can we do something that's lighter way? Do we need the structure of safe and a lot of the time the answer is we might need something like this for now. But we want to build architecture the team capability so that over time, we create it more as a platform. We can create a solid architecture, like solid software architecture. We need solid team architecture, which enables you to get rid of a lot of these practices. Like, do you really need to go into in-depth planning for the quarter head if you can resolve dependencies very quickly, probably not. Does it make sense to plan a quarter ahead? If you want to be very agile, if your customers are constantly shifting direction and there's business opportunity, maybe not, maybe it makes sense to talk about the vision and the strategy for the quarter but not planning in depth. And all of these are evolutions that whether companies continue to use, say, but change what they mean by PI planning or whether they shift to something else. All of these make sense. The for me, the important thing that I'm hearing is you were following the principles of agility and constantly trying to find what's the most effective way to achieve alignment, to achieve transparency, to achieve predictability, how can we reduce the overhead that we pay for getting these things? And that's exactly what I like to see. That's what I like this story. I tell you, even with the safe structure still in place, we went through multiple internal kind of iterations. Like for example, we had some point we decided would be bad if we have a separate architectural team, or with a group at least, right? And that group will do the architecture and then give it to the teams to implement it. I think over time, it's also, we finally realized that's maybe not the best way to do this. We ultimately split the group and make the architects a part of the teams. They might be moving from team to team over the time. It's not permanent, but at least they part of the team. They do architecture along with the team discussion with them. So rather than do it completely separately and then kind of bringing this to the team and then have a lot of questions and they actually go through the cycle of again proving that architecture to the team because it's something, you know, what's not invented by us is somebody brought it from outside. So I think we went through all this, as you said, trying to find the way, the most agile, the most productive, the least wasteful way, kind of all implementing software. And I think my experience over this here shows that it's highly depends definitely on whatever teams you have, right? People on the teams, because what might work for one organization and even for some sub-subset of organization might not work for another because maybe one organization has mostly very experienced guys or with a high level individuals and that needs to be quite a different. A child, still a child, but quite different a child principal supplied over there and maybe the team was more kind of middle and junior type of developers. What type of software developed kind of visit that something completely new or it's just developing maybe some parts of software that's quite typical like some UI you know what I'm not saying UI is can be interesting but again it's kind of you clearly understand what needs to be done while maybe in some other components here, it's more like experimentation and some kind of, so that's maybe unique for your product and for your company. So yeah, it really depends and I think honestly, my looking back, I would say my experience right now shows that you have continued experimenting, you have not afraid to apply maybe different a general principle even to different parts of your organization, find whatever works the best way to do it. Yeah, exactly. Yeah, be agile about agile. So the next iteration of your journey as a company was that a private equity firm, you know, saw the success of R.S. and made an investment and, you know, tried to amplify its value. I've heard different stories from what happens to companies and their ways of working when private equity gets involved. So I'm curious, how did that affect if at all your ways of working as an engineering organization, as a product delivery organization? I think was, I don't think it's It's effect us right away after private equity company acquired ours. I think definitely we went through some de-diligent process, the interesting how we do the development. I think we checked most of the kind of check boxes, right? So those we did agile, we did all kind of, you know, product security, the code analysis, all those kind of things that kind of needs to be done, I'm not sure software development product. We had a decent, I still believe, kind of CI CD process, a lot of automation, things like this. So in that sense, I don't think they kind of pushed us to change quite a bit. Of course, you constantly have a push to increase your productivity, you have to deliver more and faster and better and less people etc. Which is, yeah, nothing new. But I think, yeah, kind of that pressure also, kind of, let us realize over time that probably kind of situation we get with the safe and everything I described before, kind of needed improvement, right? And that was part of the kind of of the reasons why we switched. I think lately it's definitely had a little bit more impact. I think we company now goes through some restructuring because again private equity have some plans about the company and this is why I kind of have some changes in the company. But again, as I said for maybe a few years after the acquisition definitely was a pressure to deliver more and faster and better, but I don't think I had the direct impact on how exactly we implemented a gel. ## What leaders should pay attention to I think my impression overall private equity companies, maybe different companies approach it differently. It's up to you. What's the interest in that? Yes, you deliver the result, how that result is delivered, you're doing this type of agile or diesel, whatever kind of it's up to you. Yeah, which I think is the right altitude, right? The one other thing that I'm seeing and having more and more conversations about is even like the outlets of the engineering organization, if you look at the different private equity forms call these things different things, but the full potential plan, the investment pieces, I don't know what it was called, in your case, the project, the initiatives on that plan often have a lot of uncertainty, a lot of potential, but also a lot of uncertainty. And I'm starting to see private equity firms come to me and realize that the traditional PMO style implementation for these projects is falling flat for the really complex stuff, both from the perspective of the students you know everything upfront and just follow a plan, but also when it comes to how it engages with people. So they're starting to realize that there's maybe a better way to engage with the people in their portcos in implementing these plans as well as be more agile and adaptive. So I think it's an interesting direction. It's still early days for doing that in that space. I mean clearly in the last year or so, the big elephant in the room is right AI. It also has already and will have a big impact on probably how teams will work, right? And everybody is trying to adapt right now. Things change very, very fast. But yeah, I think I'm sure at the end of it, we will see maybe also different ways how a team approach the team work, how they collaborate and etc. all this AI development methods will impact how we do things. I think we will need to be even more agile about our agile, or we need to be more agile about our ways of working in the age of AI. Every week there's something new that affects how we work. I mean again with the involvement of people, I think one other aspect of that is especially with the positive potential of AI, but also the fear that it brings with it to everybody. Goldarch used to say, to talk about the fact that you won't get very far with asking people to cut the branch that they're sitting on. And I think there's a lot of that going around. And you need to, I think, some of the answer is to be human-centric about it and involved and empower people to figure out how they will work, not just tell them, this is your... This is the way you will be using AI or everybody has to use AI. Let's figure out, how does it look like for us to become more productive using AI? not cutting the engineering headcount right off because of the eye, but we, you know, how do we grow revenue double figure every year with the same engineering organization that we have using the force multiplier of the eye? Yeah, I mean it's a big big of course change the way how software develop with the eyes is quite different, right, from what we did before. It's clearly a new way to develop software. I think the faster developers will jump on board and will learn how to do this, the more valuable they will before the company. But I think, yeah, there is a lot of nervousness right now, kind of among developers, especially developers, maybe less experienced, right? Yeah, job market, soft and clearly. And that also makes people honestly less productive, because unfortunately, because people felt kind of nervous, threatened, maybe tried to find another job, whatever they're trying to secure the lifestyle. And yeah, that takes their focus on what they need to do. I mean, all this, it's a complex problem. Yeah, unfortunately, kind of we, unfortunately, we need to go through that, how it will evolve and how which impact it will have and again, how the teams work, how teams collaborate, how the software development overall will evolve, that will remain to be seen. So maybe to finish, if you had one message, let's say for a big billboard on Route 128, I've where, you know, other VPs of engineering, heads of engineering, R&D, are driving back and forth. What's one message that you're taking away from your agility journey so far that you think is still relevant or even more relevant for the next five years? I think we already kind of articulated that. I think you have to be agile about agile, right, you have to not afraid to pick things maybe from different methodologies that work for you, don't be afraid that of course it needs to be all coordinated, otherwise it will be a mess, but don't afraid to implement somewhat different maybe agile approaches with the different parts of your organization and you have to constantly experiment and to see what works for you, right? And what will deliver the better performance, the better velocity. And again, I think it's a development velocity, it's a complex topic, right? It's not only how many lines of code you produce, right? Again, it's how well developers integrate into this, right? how happy they are and because happy developer, more productive developer, right? And how do you find the balance between all of this to maximize? I think one of the good lessons I was constantly, I think that applies to whatever you remember you taught us as a part of SAVES. Individual speed, speed of individual doesn't matter, right? What's on the count, the speed of the whole train, right? And if by training you understand the whole organization, right? I think you have to find a way how to maximize that speed, right? How to change pieces of that overall. So the whole train goes with a maximum speed. And that's not easy. You know, it's not easy, but it's, you know, it's what keeps us going. It's what people like us have been doing. We're software developers, right? We're software architects. We've just moved to architect human systems in recent years. But it's the same thing or a lot of the same thing. Humans are just more complex than software. Although we sometimes like to ignore it. Androi, this has been great. I, you know, thanks for sharing. Now you're welcome. What happened in the journey? I haven't been in touch for a while, but I like to see the principles are still strong with with you and with us. So anything that you would like to live us with people have additional questions for you or want to hear more about your story. Where do they find you these days? Well, we can find me on LinkedIn. Yeah, feel free to reach out if you have any questions. Yeah, actually, we didn't touch upon that. I kind of parted ways with others just several weeks ago. I'm kind of have now time to think more about what was done, what was done right, what was done could be done better, right? And kind of enjoying a little time off and we'll see what's the next. Yeah, but yeah, we'll read it out guys. We'll link to Andre's LinkedIn profile in the show notes. And that's all for us for today. ## Source boundary These are the published show notes from the podcast feed. They are a starting point for discussion, not a verbatim record of the conversation. The transcript is machine-generated and may contain errors or unlabeled speakers. Check the audio before quoting anyone.