PurePerformance - Scaling Dev Teams from Startup to Enterprise while keeping Agility with Stefan Frandl

Episode Date: December 14, 2020

Stefan Frandl, Development Director, has a single digit employee number at Dynatrace and therefore seen a lot of agile transformation over the past 15 years – growing from a startup in Linz, Austria to now 800+ engineers across globally distributed labs. A visit to several “unicorns” such as Google, Facebook and Slack triggered the latest agile transformation.In this episode Stefan walks us through the implementation of the changes we discussed with Andrea Holl in her episode on “Scaling Agile at Dynatrace”. He shares the challenges around growing responsibilities of team leads, work left half-finished, overhead on hand-over and cross team collaboration. He then introduces us to the current structure and processes at Dynatrace such as Team Captains, Product Owners and Agile Advocates as well as Dev Directors and Lead Product Engineers. While Dynatrace has seen many benefits already, the journey is still ongoing as Dynatrace is continuously rethinking and improving the way we work and provide value to our customers!https://www.linkedin.com/in/stefan-frandl-aa86723/https://www.spreaker.com/user/pureperformance/scaling-agile-at-dynatrace-with-andrea-h

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. My name is Andy Grabner and as always I have with me my co-host Brian Wilson. Brian, how are you doing today? Andy, you have an interesting voice today. What's wrong with you? It's an interesting start. See, I wasn't't expecting that um yeah yeah you're trying to to make things even funnier than they typically are huh even yes even funnier than they typically

because they're usually so rockingly funny yeah i get i get offers from uh clowns to to join circus and run away from everything but yeah no anyway yeah we have a uh been busy been very busy lately so uh as you can tell my mind isn't all here right now even so let's let's get into it how are you andy very good we'll assume our names back so i'll be brian again now it was fun being okay i'll be andy and it's been fun being you for a while, thinking that I'm in Denver, Colorado and not in Linz, Austria, allowing me to travel at least virtually. No, but Brian, the cool thing about today's session, we always have cool guests, but today is really great because we have kind of a great continuation of the topic we had at theull, Agile coach at Dynatrace, talking about and giving us some insights on Agile transformation stories, approaches, different scaled Agile frameworks, and how she kind of started helping Dynatrace to change.

And she gave us some insights into the process that they took. I remember the Let's Rock Agile community that they built and so on and so forth. But then we said said this is great you know we got a lot of great tech theoretical background and some insights but really what would be interesting now is to hear how does this really then translate to the day-to-day work of the dynatrace engineering team yeah this reminds me of uh this reminds me of when we had burned and and I think it was Anita on talking about the Agile, not the Agile, but the

DevOps transformation. So, yeah, it should be fun. Exactly, yeah, because we had Bernd kind of saying, yeah, this is from his perspective, from kind of the leadership, and then Anita told us her story from actually in the DevOps team on our ACE team. So, without further ado, without babbling around, let's introduce Stefan Vrandel to the podcast.

Stefan, welcome to the show. Thanks a lot, Andy. Thanks a lot, Brian. Cool to be here. Yeah. Hey, Stefan, you, maybe Brian, you want to ask him. Like, he's been an old-timer almost. Yeah, yeah. So as Andy mentioned, you're an old-timer,

so I guess you're walking around with a cane and all. No, but you're, in all seriousness, you're one of the very, very early employees as well, right? Like one of the, you said, I think, before we joined, you have like a single-digit employee ID or something? At least I had one, yeah. That's right. And I bet you back then you just had Stefan as your email address, right?

You didn't have to have a last name or anything. Yeah. But there are a lot of Stefans in Austria. So, yeah. Already had a second one at this time. Yeah. I'm just amazed too, because it's, you know,

I started my, I first interacted with Dynatrace in 2009 as a customer. So, and I know you go back to even before then, obviously as an employee. So it's always just amazing to, when I, when I meet some of you folks,

obviously a shout out to Reini, who I've known since I think my second week of working at Dynatrace. So yeah, it's always, it's always an extreme pleasure to have guests on like like yourself who've been who've seen it all really yep that that's right so thanks a lot yeah and talking about cnidol stefan can you for those people that don't know you uh can you give a quick background on yourself and especially your i think last 15 years at dynatrace.

But maybe just a little bit like what's your role right now and maybe give us some background in where you started and then we dive into the topic on what has changed over the years. Sure. So currently I'm a development director here at Dynatrace. Yeah, responsible for two rather big areas. On the one hand, the whole code level end-to-end topic with the one agent but also with the

server side correlation, service detection and also the UI. And I'm also responsible for engineering productivity and that's also quite a big part of my history at Dynatrace. So everything that is about continuous integration, continuous delivery

and the whole Dynatrace lab, that's pretty much everything that I'm responsible for and my people are working on. It's amazing. I mean, especially first of all technology-wise, you are at a cool level end-to-end tracing, like everything that we know and love around PurePath.

But then also the things that people from a customer perspective not see is the engineering productivity, making sure that our engineers are actually, they have the tools so that they can stay productive. And I remember the two of us, we've worked over the years together on figuring out how we can make things faster, better automated. I mean, you did these things, but you always kind of fed me some information that I could then use in the blog posts.

So thank you for that. That was really good. At least I'm trying to. So yeah, that's a key thing for us. We need to automate. We need to try to use what we have as good as

possible and be fast, be scalable. That's also part of the growth story. Sounds like a very low-pressure job. Yes, of course so maybe coming through the growth story can you give a quick overview

for people that may not be aware of the history of Dynatrace as you started in the early days how do you see like maybe a certain let's say phases of growth and like through the number I don't know, of people, through the number of products, through the number of features?

Can you give us a little overview? Yes. So, yeah, we started in a little flat in Linz with a small group. So I think I had a one-digit employee number back then. And it was like crazy because if you think of startup, startup mentality, everyone was aiming or having the same goal

and trying to go in the same direction. So that was from a spirit that was really, really a great time. Yeah, and then we evolved, we grew and you saw that until we were around 150 people, everything worked fine. So everyone did know who is responsible for what, and that made it easy. So there was no problem with working together. There was no problem with handing over, for example, or bringing a feature to the end or an end-to-end overview of a feature.

So everyone knew what is the goal of that feature? How can we help our customers with that? And yeah, that made it pretty easy to work together. But that was until we were 150 people around that. So that means back then, I think that's actually an interesting number, 150. So you still know people. And I think we

remember back then we were still a single development lab, pretty much, right? Yes. And of course, that also made it pretty easy. So you could just step into an office and ask someone and talk to him or her.

So it wasn't a problem at all. And therefore, the information flew very, very flawless. And it was just easy to get all people on board if you kicked off a new feature and have everyone working on the same thing and have the same understanding on all the sites. So now what was the next phase after 150? How did that go on? So then we grew to around 300, got new labs there.

So we got Gdansk and Detroit into our development team. And of course that made things different. It was pretty interesting in collaboration because if you're not used to that, it's pretty hard to learn at the very beginning. Of course, also get a common understanding, get to know the different cultures and also see how working together could work in the end or could work out in the end. That was an interesting process.

And of course, that we started having a constant people exchange, right? other and kind of work together for a while because there's still obviously this human thing right we need to it's it you need to learn get to know the person also from a private perspective if in the evening you can go out for a drink or something like this and um i i mean obviously now in kobe times we don't do this but i was gonna say what's going on what is going on for a drink i don't get that yeah that's that's just a very very important part get to know get to know the people that you're working with um get them also to know uh on the private side so that that's also very very interesting and yeah you you still get the different relationship, you can more or less better better judge what

the other person wants from you if you have met he, him or her already once. And that really helps. So personal relationship, seeing people talking to them in in person face to face that makes a huge difference and i don't want to sidetrack too much here but the one thing that really strikes me and you know before we started this i was just talking about how although i complain about the issues we usually have recording just the fact that we can do these is quite amazing. But when you think about going back to the beginning of Dynatrace,

that was, you know, the type of APM before that was pretty lousy, or I shouldn't say lousy. It was great for when it was developed. It was first gen, right? But when you look at what our customers, even what us, us in the field, like demand and expect out of platforms like this,

it's amazing that it's all even there, right? If someone like Stefan, who's been working on building all these things into it so that it's what people expect, right? People take for granted that traces are going to connect tier to tier, right? People who are doing homegrown observability, you know,

open trace and things like that. They're learning the hard way, how hard these things are to, to maybe to do. But all these pieces, let's it's, we turn, you turn on an APM tool and there are certain things that everyone just

expects to happen, which all had to be built. And to me, I'm just thinking as Stefan is talking like, yeah, he was part of the teams that had to be built. And to me, I'm just thinking, as Stefan is talking, like, yeah, he was part of the teams that had to build all this and envision it. It's just crazy. 15 years later or so.

Yeah. That's why if it would be post-COVID or not in COVID and we would be together, you would buy him a beer now. I would. I would buy you two beers,fan two okay yeah um yeah if you're or when you will be in lint again after call it i will remind you of that right yes yes someday i'll get there i've never been there in my whole career here but anyway

let's really yeah well i have a daughter with a seizure disorder and uh in the earlier days it was impossible to for me to travel like that and um as time went on it just you know we do we do less travel for ses to lynx but back in when i first started with dynatrace it was more common so i think i might have lost my opportunity but we'll see we'll have to find some way post-covid yeah i want to go to the falco shrine yeah coming coming back to the uh the growth so we used 300 people that was the next phase what about anything changed after that yeah so the the good thing or the thing that helped us there was that we started, obviously, with Dynatrace. So there were people working still on AppMon, but a group of people started on Dynatrace. or quite a bit, to be honest, just to separate the focus and having, again, two small groups in the end.

So that was really, really helpful if you look at it from today's perspective. Yeah, so for people that may not know the history, so based until a certain point in time, our main product was what is now called dynatrace appmon the tool that we've also already kind of end of life but at some point we incubated kind of a startup within dynatrace which is now the dynatrace software intelligence platform that everybody knows and and that's that's obviously great to know because we as you said right

separating the teams making these teams kind of or at least the new team small and also learning i guess some some new approaches to delivery or to development yeah sure we changed the model uh completely just uh from uh on-premise to a s business and to continuous delivery. Instead of having two releases a year, we're releasing every two weeks. So that's a game changer. And of course, we had to learn quite some stuff there. How to build software and how to build software for two-week sprints and two-week release cycles

and how to do everything around that to get really good quality out there. Yeah. So then let me ask you a question. I mean, as of today, I think Andrea said it last week when we recorded, we have about 800 engineers, fossil miners who give and take across many different labs. Why was it necessary

to go through yet another kind of it seems bigger effort to to change i'm not sure how big the effort is but why why is this current iteration why was andrea and others brought on board to figure out how we need to change what What was the problem from your perspective? So the biggest problem was like, people didn't know each other anymore, so they didn't know who is responsible for what. And yeah, it started slowly to slow down the whole development process,

meaning you're starting a feature in in one team and the other team that should then work or continue to work on that to get it finished and end-to-end finished has other priorities because yeah they may be working with a different product management team they've been working with different other things and have their own priorities and their own features they are working on. So you just had things that were done on one part. So meaning if you think of agent, server and UI, we had quite some situations where we were done on the agent side for a few sprints already, but not having any time on the server

side to work on that, to, for example, add new things for service detection or stuff like that to make the feature end-to-end helpful for our customers. So that means... Go ahead. And that was, of course, a big roadblock. So you're slowing down even if you have a lot of people working on it. Yeah. So basically you had,

because of the team structure back then, I guess, right? Agent and then server, as you said, and UI, because it's separated like this. And if you look at the feature end-to-end that involves you know at least these three major teams and one team starts and then they are finished and you have a lot of let's say half ready features lying around just waiting to be continued by by another team but that team had other priorities and therefore you have a lot of half finished feature and half finished work-finished work. I mean, I guess

if I understand this correctly. Yeah, because if you're, for example, going back to that agent example, if you think of you did your code changes half a year ago and now it's processed on the server side and requirements have changed so you need to go back to that code and

change it or adapt it to the new requirements or you're just getting bugs in there for code that you have written half a year ago. That's all just not really big fun. Yeah. That sounds like a nightmare. That's all just not really big fun. Yeah. That sounds like a nightmare.

So it's also part of motivation and motivating people to have features end-to-end out there, see them working, get the feedback there. And that was also a big thing that we were missing. And I think this must be a problem

for many organizations, especially that are growing and that are moving also to more distributed systems where you have all of a sudden maybe 10 teams here that are working on 10 microservices in that area, then other teams there on some other things. And I'm pretty sure that a lot of organizations that grow will run into similar issues then. It makes sense if you don't change. Yeah, and that was one of the main reasons why we needed another change. And that's something that I love at Dynatrace, that we are always changing and always think about how can we optimize there. And that's a very, very cool part of Dynatrace, that you can always start to change, try things out. And yeah, if that works, so we can roll it out.

So that's really, really a very, very nice possibility here at Dynastrace. So now fill us in. What did you change then? How did you get a handle on this hand over hell or whatever you want to call it? So basically, there were multiple things that we we had to change so one thing was we had team leads back then and a team lead was more or less a swiss army knife so doing everything that is from of course working with people developing people but also being more or less the PO of the team, being the HR advocate of the team,

and also being an engineer. So having four roles on his shoulder. And that was, of course, something that works to some extent. And if people are extremely good, then that works out. But if you just have, for example, things or areas where you're good in, you may focus on them. So that means maybe one team lead is more focusing on the growth of the people. The other team lead is more focusing on the content, on the PO things. So, yeah, depending on where the favors are there,

it might look different from team to team. And I guess it's also just natural, right? It's also natural that every human being is obviously focusing on their strengths and therefore you will automatically have different permutations yeah yeah and and i said that's that's a big part of um having a lot of responsibilities on on one on one person and also um yeah having all the different roles combined into one um that's a thing where we see right now

that splitting up that helps a lot. So we went ahead there and thought about how can that look like. Of course, as I said, we just needed to recognize that a team lead is having all those four roles. And as soon as that was obvious, that this is overloading people.

So we just thought how to split it up and came up with the model of having a team captain. So that is the one guy who is still playing there, but is also more or less the leader of the group. And then having someone who is focusing on the content, meaning really focusing on the stories, focusing on the quality of the stories, having a definition of ready, a definition of done, having an end-to-end understanding what that really means,

so that we make sure that not stories like one liners where the content is something like as discussed which we had is going into a sprint because we had that situations to be honest where people were working on stuff that they didn't know what they are working for there. So what does that mean in the end for which kind of feature are we working there? And of course, that leads to not optimal results there. And when someone is focusing on that, then this really driving stories

and the quality in there, then this changes. So the feedback until now was like, yeah, the quality of the stories is way better. The backlog is like clean, really clean. And everyone knows what are the topics that we are working on. Why are we doing that end to end? And yeah, also knows what are our focus points for the next months. topics that we are working on, why are we doing that end to end and also knows what are our focus points for the next months. That's cool, so basically taking all the lessons learned from an overloaded team

lead and splitting the individual tasks into individual roles, team captain, PO, anything else, anything else? Anybody else that is involved now? So some teams are having an HR advocate in the team who is responsible for the retrospective and also for all the HR processes, making sure that things like a retrospective is really done. And also there are follow-ups on the retrospective items, which is also very important.

So that also helps and supports the PO and also the team captain. But that's not in each and every team. And as you have said, there is also Andrea and the whole group of the Agile Competence Center that is helping us there and supporting us. Yeah. So that means that, go ahead, Brian, go ahead. I was just, well, a little bit of a change of topic. So go on, Andy.

No, I was just, yeah, maybe a final thought. That means Andrea and her team, they're kind of defining some best practices around how agile should be done. What are the processes? What are the building blocks? I think that's what she said. And then you have the individual advocates that are then injected into the teams

and really help them with executing these agile processes and obviously helping running the meetings, running the retrospectives and so on. That's great to know perfect what what also was very interesting is how we started that because if you if you think of that's really a huge change so it's not like a small piece but a rather huge one so i started with my teams going with so at first talking with the team captains, the team leads back then, just to make sure that they understand what we are doing and why we are trying to do, explaining the roles, and then also trying to find people who want to take those roles and who want to be responsible for specific tasks and areas there.

And of course, that was interesting because we didn't have, for sure, everything perfectly designed and defined back then. So we just needed to learn a lot and need to be flexible. And that was great to see my teams just being very open to that, open to that change, because they said it's a big change. And that was really, really cool.

And I wanted to ask, some of these changes, yes, now Brian, some of these changes, when you look at the numbers and the size of the teams, when the team been really great at from both the product point of view, as well as the internal processes point of view, is adapting and modifying as you go to fit the needs. But I imagine for any organization, the larger they get, the more difficult changing internally is. And have you, what have, you know, not to spend too much time on that, but what are those challenges like and is this something that's easy to overcome if you just shift the way you think about it

yeah the challenges obviously are that everyone has or should understand and should be should be on board if you're doing such a change to inform everyone about it to to convince everyone that this absolutely makes sense is of course a lot of work and you you have to run quite some meetings to make sure that everyone is understanding what what you want to achieve and how this change will also affect the daily work so there are a lot of questions or there were a lot of questions around that. And yeah, so it was really, really important that every dev director, so we have multiple dev directors for those 700 people, is working with the teams, trying to support them as good as possible, trying to make them understand what we are going to do and how we're going

to do it. And of course, like we always do at Dynatrace, we had a small incubator. So I was starting with my teams. And as soon as this was successful, so I also just started with a few teams in my group. But as soon as this was successful, I rolled it out to the whole group and then other areas or other dev directors also saw that perfectly makes sense

people are getting a boost there and of course it's a big chance also for those other people who were in the team didn't have a team lead role, but wanted to do more than development. So wanted to focus on different other areas.

So now this was, of course, a big chance for everyone there. Mm-hmm. Great. Hey, Stefan, so it makes sense that you obviously split the one role into multiple to focus on the individual things that had to be done. But this doesn't really solve the problem of you have multiple teams that you now need to coordinate. How did you solve that problem? Right. So we also introduced another new role there. So in the very beginning or in the last years, we worked with so-called dev fleets. So I was also one of the dev fleets back then

who had basically multiple roles. So on the one hand, the role of being responsible end-to-end for features and make them work end-to-end, but also being responsible for a larger group of people. And that was also split now into two roles. So there is the development director who is responsible for the people, for the growth in the teams,

but also for other organizational tasks there. And there is a lead product engineer. The lead product engineer is more or less coordinating the different POs in the different teams. So what we are doing right now is we're starting with product management. Product management is defining key themes for a year, for example, or half a year. And out of those key themes, we are creating different value increments, making sure that those value increments are really something that we can deliver and that is giving our customers advantage.

And out of those value increments the lead product engineer together with the pos of the team is then creating development epics and is then breaking that down to stories together with with the team and that helps a lot just to get the end-to-end focus and also to have a good estimate on how long things will take there that is pretty cool so if i can reiterate uh key key themes and i will you know around diamond trace solutions i think? If you think about those people that know Dynatrace, let's take the cloud automation solution, then you put it into product epics.

Could you give me an example on product epic, what that would be? That could be, for example, memory allocation profiling. That was a product epic. So. Yeah. And then a value increment would be just to walk through the example because that's really cool. I mean, I like the structure, but just if we maybe have one example also for especially Dynatrace customers that kind of then can relate to this, how we how we split this up internally yeah then of course uh this consists of multiple steps so for example um getting getting um the the raw data from from the agent to the server and and into the ui uh getting uh for example a location count into into the ui could be one first step there or one value increment.

Cool. Very nice. So, I mean, what's interesting now, so basically you had two things where you were splitting two overloaded roles into multiple roles so they can focus on individual tasks that on its own are very important. Obviously, you can then put in people that are really more dedicated to this role so they maybe have more experience or more interest in doing these things.

So splitting the team leads into team captain, PO, and agile coach or advocate, and then splitting the dev lead into dev director and lead product engineer, and then using the key themes, the product epics, the value increments, the dev epics, and the story to then actually then organize the work that needs to be done. Really cool. that needs to be done really cool um stefan so this is the current uh obviously iteration of this um you know agile improvement can you tell us a little bit about what has changed so far so maybe you know immediate benefits or benefits we've seen so far? Yeah. So there is, of course, speed. Speed has changed.

So we are way faster in releasing new features and getting new things into the product and have that end-to-end really covered there. That's a perfect thing. Of course, also the end-to-end understanding in the team is now way bigger. So we know what needs to be done to get it into the product, who needs to be approached there, who needs to work together. That is also really, really cool. Of course, a lot of people have

changed their roles or have now new roles there, like being a product owner, for example. And that was a big chance for a lot of people there to drive topics, to grow in their personal role. And now let me ask you why, I mean, I assume it's not just you that drove that change, but what motivated you to initiate that change? Because there might be listeners now that say, yes, we have also grown beyond the point where the current system feels it's like stuck or it's not efficient anymore. Who do you, can you give any recommendations to people that feel like they need to change and and and how to change it like what motivated you to step up over because i don't think it was your initial role to do this to to be the chain of constant change agent unless it was

so maybe you can just give some insights and and and guidance to other people so no it was it wasn't my role and i'm not the only one who was working on that. So back then I was going with my boss, Alex, so the VP of development to San Francisco, visiting different other companies just to see how they are working. And because we felt both that somehow we need to change because we didn't move that fast, although we added people there. So we needed to change something.

And we spoke with someone at Facebook. We spoke with people at Google. We spoke with people at Google. We spoke with people at Slack. And Slack was pretty similar from the size and also the locations, the lab locations to Dynatrace. And yeah, there we got some ideas how they are splitting up their work, which kind of roles are involved there.

And that initiated that change. So on the way back from San Francisco, we discussed about team leads and how many things they have to do and also being always the Swiss army knife, having always that kind of pressure that you, on the one hand, being responsible for the people but also being responsible for delivering features um yeah there the idea just started that is cool i remember actually now was it a year two years ago already that trip when when you talked about this yeah i think it's two years now. I didn't even know that was possible. Just go to other companies and pick their brand

and how they do things. That's cool that they share. I mean, it makes sense since everyone shares everything else. But the idea of like, hey, we're from Company X, can we come? What did you do? Go actually observe or you just met with them and they discussed with you? What does that even look like?

So we had good luck luck we had andy so andy andy was really helping us to to get contacts in there uh for facebook and uh for google i had my my own contacts and slack was like a surprise so we just uh said yeah we are using slack so maybe talk uh to to someone there from development and yeah we we are using Slack, so maybe talk to someone there from development. We were lucky and got someone talking to us, and that was pretty helpful. Okay, so it's not like they have a program that you can reach

out to and go and say, hey, you just happen to have some contacts and you made them work. Of course, with Andy involved, as soon as anyone sees them out on the salsa dance floor they're like hey yeah come on we're sold right it's melting away yes uh yeah of course no but i i mean to this point i think there's obviously i i mean there are a lot

of organizations that talk openly about i I think, what they have done. Like if you think about Spotify, they've been very vocal about it in the beginning. And I'm pretty sure if people are not listening in and say, OK, what can we do? How can we learn? And which company should we go to? I think a lot of organizations have blog posts or talk on podcasts and then just reaching out to these people via linkedin if you don't know them yet or like stefan i i assume people that are now listening in they may want to reach out to you and say hey can we sit down and learn more so i would i hope at least if this

happens that you will be open and kind of continue sharing that favor sure i'm happy to share uh what what we have uh yeah what we are we're going through and and how how we did that change um and of course i would be happy to share that experience and and remind me reminder to everybody a beer or two goes a long way um stefan the so this was the is this iteration are you done with this current iteration is this rolled out and implemented kind of across Dynatrace engineering

so I think we are pretty far we are not through that at the moment so we did change a lot and as this is very natural, the team needs to digest that, right? So we are still in the digesting there,

but it works pretty nice. And yeah, I think that is a good step. And yeah, that won't be the last change we are doing, right? So we need to take small steps and let the team digest it. And then maybe there will be a next iteration. Well, especially with the constant growth, right? We're still hiring like crazy even through covid i mean i see gabi my wife in in the uh in the onboardings that she does every month and there's still always

new people that she she where she tells her story about her team right because in the onboardings we introduce all the teams and it's amazing how many people we hire and how we grow still and i'm sure that's going to continue so i guess naturally there will be at some point a need to think about the next iteration stefan is there is there a kind of kind of you know concluding to this uh any other things that you wanted to make sure people know about our transformation and also what might be fruitful and useful for their transformation as well yeah as i said i think you need to just try things out you you must be allowed to fail as well so trying out something in a in a smaller group and if you

see that it's successful then roll it out to the bigger or to the larger group that was a very very good approach and i think that's something something uh if you think of a change um this is something that you can try and um yeah that's that's that's the way i i love I love to do new things or try out new things. And I think that did work out quite well so far. Yeah. Awesome. Really cool. And I think one of the things that amazes me so much about Dynatrace

is that just looking at you, that you are one of the early employees and after 15 years you're still here and you're still motivated and you're still trying to make the the our work life a better place and obviously the product better for our customers and there's so many like you that were there from the beginning and are still there and still doing like starting obviously with burnt our founder and and many others like uh brian mentioned ryan who has been there for a long long time christian there's so many people uh that just still love what we do here man it's pretty cool yeah and i think it's it's a big

part of that this is the possibilities that we have and and the freedom that we have and the freedom that we have to initiate change to do constant change but also the the dozens or thousands of of different technologies that we're supporting so you can learn every day something new and and that is just amazing so i i still had uh had touch points with with the mainframe as well as JavaScript and all the different languages. Of course, Kubernetes. So, yeah, it's like you can learn every day something new. And if you want to, you can look into different technologies. And that's the cool thing about Dynatrace.

All right. Hey, thank you so much i think stefan we we should have you back uh you know when the next iteration starts or obviously you are also working on a lot of other cool things within the company a lot of great technologies i know you're also leading and guiding people through some of the master thesis and some research projects. So I'm pretty sure while this was the first time, it was not the last time that we have you on one of our podcasts. So thank you so much.

Thanks a lot. Thanks a lot for hosting that. And thanks a lot for inviting me. Thank you. Thank you for coming on. And if any of our listeners have any questions, comments, you can reach us at pure underscore DT on Twitter, or you can send us an email at pureperformance at dynatrace.com.

Stefan, thanks a lot for being on and just for doing all the awesome things you do. We all really appreciate it. And I'm sure all of our Dynatrace customers appreciate it, even though they probably have no idea you're behind the scenes working on all this stuff diligently. But thanks to you and the entire development team and the R&D and everything that goes on. So I really appreciate that. Thank you.

Thanks a lot. Bye-bye. Bye-bye.