So I started as the software engineer, A self dot software engineer. Actually, I taught myself coding at a young age, and I got into software professionally by taking on first, take you a position, okay, testing software and all that good stuff. And then, um, then advancing to being a developer with the same company s. That's sort of how I began. I think what shaped my career First step waas um e was working in the company was maybe my third. My third job is an engineer, and at the manager that believed in me offered me to be a team leader. So my first opportunity Thio lead a team was maybe after four or five years of being an engineer, it was definitely a big miles Andi. As the first few years went by, I realized I really loved that. So I stayed with management for quite some time, actually went back and was an individual contributor for a few more years, especially after moving to the U. S. But then work my way back to management. Andi always aspired to do that at the highest level and to continue to develop as a leader

so responsibilities in decision. Um, so I mean, when you're leading a software team as a whole, my job is half of it is the lead engineering. The other half, in a sense, is just to be a good teammate for the executive team on DSO. What that means is my responsibilities is translating business strategy into engineering roadmaps. It's me collaborating with the VP of product and understanding what business needs we have, how we can answer those needs with software and then letting our teams are leading our teams to develop road maps that provide those solutions on DSO. What that means for my role is a lot of strategic conversations, a lot of planning and budgeting defining goals, andan setting high level plans on how to reach them, Um, and no coding anymore. And there's at some point in management of engineering where you're not coating anymore the way you're involved. Technologically, it's more of the architectural level on in general solution design. Eso, that's what it is, more or less is sort of keep keep one here with the business here. Our sales work, how marketing works in your company. What are your customers experiencing? What this customer support team tells you, and they just all that translate that to new development projects is essentially it weekly work hours? Um, let's say roughly 45. But then there's a little bit of extra, um, a little bit of extra work sometimes is needed, you know, on weekends. Um, not that anyone would, you know, stand there and wait for me to work more. Not not at all. It's just that because the environment is quite hectic and my particular schedule is full of meetings. When I need a few hours to get something done quietly, it's much easier to do off work hours. But of course, we try to do that in a way that and yeah, before covert, my work travel was 30 minutes. No big deal 30 minutes away. But now it's zero. So yeah, yes,

the general challenge that always repeats in your career, no matter where you are and what you're doing. Engineering is, um, you can do much more than you have time to dio Andi. Everything you're trying to be doing, you never have enough resource is for it. So the challenge is always a challenge of scoping. That's the part that I particularly like about a child development, whether it's scrum or something else is you're trying toe. Always do M v p. Always develop minimum viable product. Why? Because, you know, you know I can spend on a project three years and I'll still not be done. I'll still I will always be able to innovate and do more. But the challenge is use a timeframe that's redefined and a limited amount of resource is and do as much as you can as best as you can with those limitations