Navigating Career Transitions and Finding Opportunities for Growth in Tech with Matty Stratton of Aiven

Matty Stratton Transcript

Intro - 00: 00:01: Welcome to Beyond The Screen: An IONOS Podcast, where we share insights and tips to help you scale your business's online presence. Hosting genuine conversations with the best in the web and IT industry, and exploring how the IONOS brand can help professionals and customers with their hosting and cloud issues. We're your hosts, Joe Nash and Liz Moy.

Joe - 00: 00:22: Welcome to another episode of Beyond The Screen: An IONOS Podcast. Today we're joined by Matty Stratton, whose career has spanned DevOps, cloud engineering, and open source data platforms, taking on a variety of new challenges, including roles as PagerDuty's DevOps Advocate and Aiven's Director of Developer Relations. An influential voice in the tech community, Matty has had an immense impact in organizations like Red Hat and Pulumi, but he has also become a beacon of knowledge and entertainment in the DevOps space, hosting platforms like DevOps Party Games, of which I'm a huge fan, and the Arrested DevOps Podcast. Matty is a champion of change and a true advocate for stepping out of your comfort zone in the pursuit of growth in the tech industry. Matty, welcome to the Show. Thank you for joining me.

Matty - 00: 01:00: Oh, thank you. By the way, I have a new bio to put on all of my socials now, because that was amazing.

Joe - 00: 01:06: Credit entirely to our wonderful researchers here on the Show. They always do a wonderful job. So welcome. It's fitting that we start with that bio because of course, here we are to talk about embarking on new roles in tech industry, stepping out of your comfort zone, and we hit a whole lot of beats in there, a lot of different parts of your journey. So across that, we mentioned several companies mentioned several roles, we mentioned several different like whole industry sectors. Take us on that journey. Walk us through your career path. What has led into all these different transitions?

Matty - 00: 01:33: Yeah, I mean, the word that comes to mind is serendipity, right? And I will say this is sometimes a fun game to play and sometimes one that can lead you down a path of regret. And I try to not do that. But maybe it's like a sliding doors thing, right? It's like, This one little innocuous thing, I would not be anywhere near this place I'm at if that thing didn't happen. You and I would not be having this conversation if not for something that some kind of jerky scene partner I had in high school said to me. So I was on the speech Team when I was in my sophomore year in high school and we did a duet acting thing. And I'd never really done this before. It was fun and interesting. And my scene partner was very involved in the plays. And there was a certain point when we were practicing with our coach and figuring out when we were gonna practice over holiday break. And my scene partner was like, oh, well I can't do X date cause we're going to theater fest. We're taking the play to theater fest. The coach said, oh, Matt, are you going to? And he goes, why would he be going? And I was like, okay, Jerko, guess who's trying out for the play now? And then the way this got me there was, so that I ended up originally going to college as a theater major, as an acting and directing major, which I dropped out of. And then went back to a different school as a computer programming major, which I then dropped out of that too.

Joe - 00: 02:42: Quiet the switch.

Matty - 00: 02:43: Right, it's kind of funny if you look at my senior bio in the theater club in high school, it's like, where do you see yourself in 10 years? And I said, I was either gonna be a happy but unsuccessful actor or a successful but miserable computer programmer. So I knew it was gonna go down one of those ways, right? And we won't go down the whole storied career of theater and movies and things that I did, but it's important to know that I have that background, right, that that was the thing. But then I dropped out of school and I had to get a job and I started working for a local computer company that was an Apple Service Center. So I learned how to fix that, but they also were a fledgling ISP. This was back in the mid 90s. So I became the web master for like our local homepages for our users. So I taught myself HTML and very early on, Pearl CGI bin, I went on and became a Web coder for a big mail order computer retailer kind of thing. But a lot of it becomes the serendipity. I wanna talk about the serendipity is I didn't know anything about Windows just as an important part. Like that was not my background. When I was doing a lot of this Apple work, we had companies that were like prepress and printing companies. And so they would all use Macs for their designers, but the backend, their prepress rip stations were Windows NT. So I had to learn a little bit about that. And then I ended up getting a random job as a system integrator. And then I learned Windows. And I spent 20 years as a Windows Back Office Engineer for financial companies and insurance companies. And somewhere along the way, I got interested in DevOps, which I always feel like I'm new to the DevOps scene, but every year I become having been involved in in a longer period of time. It's fun if you go data mining through old Twitter, you can find some really bad takes I had about DevOps. 15 years ago.

Joe - 00: 04:12: Who amongst us has not had bad takes? It's fine.

Matty - 00: 04:14: Yeah, well, they weren't bad, but they were the things that you were like, well, who patches the servers in DevOps? And I was like, cause that's, yeah. But yeah, so I kind of went down that road. And while I was working for a living, running infrastructure for a bunch of companies, I would occasionally get invited to give talks as a customer, be like, hey, come speak about what you've done there. And having studied improv and acting and direct, all these things are fun to me. And after a while, started to learn that that could be an actual job doing that. And then I spent some time in developer advocacy, which is when I started at PagerDuty, run over to kind of do advocacy there and then have done this for a bunch of years. And now I'm able to lead a Team, but I've always wanted to be close to things that are interesting to me. One of the things I used to say when I worked at Chef, which was per PagerDuty, I used to say, I work at Chef because I believe in Chef. I don't believe in Chef because I work at Chef. And that is also, by the way, a good way to like burn yourself out and have a really unhealthy relationship with the company that you work for. But I always sort of say, I want to feel like the product that I'm selling or that I'm supporting or that I'm enabling is making someone's life better somehow. And it's not like that Silicon Valley thing, like we're trying to change the world, but Chef is a great example. Like I had been in that nonsense. And I knew that if you use this, it wouldn't make you bajillions of dollars. It wouldn't make your kids listen to you or anything, but your life would suck a little less.

Joe - 00: 05:32: That's a discreet thing that you're doing every day. That would be a marginally less painful if you did this, if you use this, right?

Matty - 00: 05:37: And that's what I like. I want to be somewhere I say, okay, I understand. And I think most products do that. So I want to be able to understand how. I've talked before about how I feel like I do DevRel on easy mode because it's easy to have empathy for someone that is you. Yeah, right? So it's fun to know where I'm at now and I'm running developer relations for a data company. I don't have that built-in empathy for our types of users because I'm not a software developer at heart. I'm not a data person, but luckily I'm a Manager. My joke is I said I couldn't get a job on my own Team as an individual contributor. And that's actually probably what helps make me a better Manager. That's fascinating.

Joe - 00: 06:14: And that leads me really neatly into asking, so we're kind of talking about the jump from industry to industry from role to role, from college degree to college degree, from IC to Manager, from stepping up into the leadership role, I guess, seats, how did that come about? Were there any parts of that transition that you found particularly difficult or helpful?

Matty - 00: 06:29: Yes, and I've been through it twice now. So I spent many, many years as a system administrator, as a backend engineer, you know, and everything. And then I got hired at Apartments.com to be the Manager of technology operations there. And it was one of those 50, 50 jobs, like you're supposed to be 50% Manager, 50% engineer, which means it's a 75, 75, you know? And as the great Ron Swanson says, "'Don't half-ass two jobs, whole-ass one job.'" That's a lesson for you. But as I worked there for a while and built out the tech ops Team there and I became a Director, so Manager of Managers, and I was running a big function, and I got a new CTO at one point that I reported to. And after I had worked for them for a little bit, he kind of pulled me aside and said, "'You know, Matty,' he's like, "'I don't think managing people "'is what gets you out of bed every day. "'I think you want to do things.'" And I was like, okay. And he said, "'I think I want to make you our infrastructure architect.' And I said, I didn't know that was a job that we could have over here. And interestingly, I said, I have two conditions. One, I want to make the same money. This needs to come along with that. And two, I need you to write a letter to give to my, at the time, wife and father-in-law that this is not a demotion. Yeah, so I did that. And this changed back to IC kind of happened. This was circa 2013 or so. And then shortly after that, I moved into some other roles and I fought management, but I also fought being management for many years. And I have a friend who has had this history where he goes to a new place and he's an amazing engineer and he stays there until they insist on making him a Manager and then he leaves because he's like, "'That's not what I do.'" And he's actually been at his current company for I think the last seven years. And that's, I think was part of the point was he said, "'Look, just so you know, do not ever make me a Manager. "'That's not what I do and I will go somewhere else.'"

Joe - 00: 08:06: But Tech Companies love to make Senior Engineers Managers rather than hiring Managers. Yeah, yeah.

Matty - 00: 08:10: Well, right, yeah. And I think it's actually pretty cool that the place that he's at, they were like, "'Okay, well, that's the deal that we made.'" So I very much resisted management. I was in a lot of roles that were leadership. I was leading teams, I was doing all this, but I said, I don't want to be a people Manager. And last year, about a little bit over a year ago when I was looking for something new I think it was time for a change for me to sort of shift. And I said, okay, I would like to be able to run a function. And also I'm trying to change what I do. And also I said, you know, I think I've done a lot over the last five, six years about like understanding how to build a really great program around developer relations and developer advocacy. I can stop doing that now. And also this is partially as we go through it. And it's been really good to come through it again. And I think that's an important thing for people to understand is like, your career will do these little, not even ups and downs, but sometimes taking time away and doing something different helps you be better at that other thing. That's true even in developer advocacy in general, as we take steps away from being a DevRel and maybe go do some pure engineering for a while, go work in product for a while, you come back, you're even more powerful and effective. But the transition from IC to Manager again in this kind, this has been easier for two reasons. One being what I alluded to, which is I actually can't do the job, so to speak. I can, but I can't, you know what I mean? The things that the amazing DAs on my Team do, you don't want me getting up there and giving a deep dive talk about Kafka. Nobody wants that, unless you want it for comedy, maybe we'll do that. So that tendency we have as highly skilled ICs to be Managers, we're like, well, I'll just do it. And that's very hard. I mean, there's still plenty of places I could be better. And I'm sure my Team who's listening is saying like, okay, wait, Matty, let me tell you all the 15 times you should just let us do it and stop doing it. But the other thing is because I've done that transition before. And one of the things that was really powerful, the company I was at, Classwide Ventures, which Apartments.com was part of, when I first became a Manager, I was hired in as a Manager, but one of the things they realized is they said they had such a culture of promoting within that when they looked at all the Managers across the company, the majority of them were first time Managers. So they did a really big investment in training, internal training, and they did a Manager training, and then it was so successful, they also then did it for directors and I took it later. And there's this fella named Bill Joy, who I still try to do work with. And everything I think about management, almost everything, the foundational stuff comes from that and it was super powerful. But one of the things that we talked about in there was the various Manager transitions we do through our careers. You go from IC to Manager to Director to senior Director to VP and everything. And every transition along that way is a challenge. The hardest one is the first one. Once you've done that, now it's nuance, right? It's sort of like learning a new programming language, but the first programming language you learn is the hardest one, because you have to learn to think like a programmer, right? But then when you're like, okay, I learned C++, well, now I need to learn Ruby. Okay, well, it's a dialect at that point. It's a nuance, but learning that first jump, that's the hardest thing. And to your point, like you said, we love to just take Senior Engineers and just make them Managers and we don't set them up. Lindsay Homewood has a great Blog Post called, it's not a promotion, it's a career change. And I know Charity Majors has written about this extensively, Lindsay's post has been around for forever, but that's the thing, it's a different kind of job. And it's totally okay to be incredibly senior as an IC. I love as a Manager that my direct reports make more money than I do. That should be totally fine.

Joe - 00: 11:30: It's not, yeah, the different career, not necessarily like a recognition that you are better at that job than the person that reports to you, right? I think that's very key. So you touched on this a little bit. I wanna kind of drill deep on this idea that you have stepped in lots of different industries, different careers. Lots of people, I think particularly now as the tech stacks get ever deeper and it feels like you need to be ever more specialized. And so the idea of making those sideway steps is very intimidating. How do you deal with stepping out of your comfort zone in terms of your role, in terms of what you work in and making those transitions to something new? How have you approached getting over the fear of like, oh, is this role gonna take me in a different direction to where I've been before and that kind of stuff?

Matty - 00: 12:09: of it just comes from being older and having been through it. And that serendipity. And I had a mentor years ago, I was at a crossroads at one point and was like, okay, two possible opportunities. I'm like, do I do this one or this one? And he said, look, it's not about the next job. It's about the next job. So what do you want to do next? And one of these will take you there and the other one won't or could take you there. So that's a lot of how I think about that. But having that evidence of that, it's sort of like, as we get older, you start to believe a little bit more like it's all going to work out. It's probably fine. We like to say this in DevOps, it's probably fine. But as you go up on one hand, the statement can be as you want to become more expert, you should become more specialized. But I would challenge that a little bit, because when we start to look at people who become more and more senior in organizations, they actually become broader. And what do we talk about with principal engineers, principal engineers don't write code. I mean, you write them, but to do those type of very senior roles, and there are exceptions, there are places where you can be at the super senior level, but there's fewer and fewer of those. So that's a tough road to hoe, right? Because you were like, okay, yes, there is a market for this person that knows this one particular library and framework so well. And you know what? The world needs two of them, right? But the world needs lots of engineers who understand how the broader ecosystem of your Application and infrastructure and system and business work. So it's a superpower to be able to know more things shallowly. But where you're shallow is your awareness of how those things work. And where you're deep is the glue, the

Joe - 00: 13:44: connective tissue between- You become like the T-shaped person.

Matty - 00: 13:47: Yeah, or the M-shaped person, even if we want to really, which those are rough, because then you're like, be super great at lots of things. But also generalist about everything. This is something I've been looking at, how do I expand? I'm doing this myself right now. I'm saying, okay, I have things that I am really comfortable at. I could sit and turn this out, right? But what's the longevity of it? And talking to a mentor said, you know, Matt, not a lot of companies have a Chief DevRel officer. So I'm learning about how do I expand into understanding things like developer growth, how to understand other kinds of marketing, not to make my DevRel Team a marketing Team, but where do these things connect? And then also, I mean, I'll call it out right now. Like, even though he's my boss, I'm not doing this to like gas up my boss, but we have a new CMO at Aiven. He's been the CMO for a while and he came from DevRel. And I'll tell you, as someone running a DevRel Team, it's freaking amazing when your CMO came from DevRel, because they get it. But the same thing is, see how these things work together. But what I'm getting at is, you can move into those areas and then your other expertise makes you even more powerful there and being able to understand it. So, and even if we talk about, if you're like, okay, I want to be like really technical engineering, whatever. So the same thing, the best principal engineers are the ones who understand how the business works, how the broad ideas. So the more that you can have, I don't want to say a passing knowledge of those things, but that's the thing. So it's actually scary. Trying to learn something new is scary. Don't get me wrong, right? Not to dismiss it, but to help get over the hump is why, right? Because the thing is you're like, okay, I'm going to ask myself to put in a big investment of learning something new. That could be scary. That I could fail if you want to just drill it down to a cost benefit analysis. The benefit is, it can leapfrog me because now I have better knowledge and whatever. And if that's not something you want, then it's okay. But Jeffrey Snover said this on my Podcast once many years ago where we talked about expanding and he said, if you want to never learn something new, then go work in lumber. I think we've learned everything there is to know about Wood. But I also feel like every time that came up, I'm like, someone's listening to this. It's like, you know, My Uncle is like the Chief of the Lumber Council and there is all this Innovation in Wood.

Joe - 00: 15:47: No, as a woodworker, I get the feelings, but yeah, I get where he's coming from. Yeah. So, obviously you spoke about DevRel and that idea that there's not that many companies need a Chief DevRel. So, and I think that leads us into another topic that's inherent in making these switches, which is there's kind of your internal fears about, hey, do I know enough to do this? How's this going to impact my future thing? But also this is inherently a big commitment, a big investment moving from familiar to new. And there is uncertainty in that. And, you know, especially in DevRel, that is something we're very well How do you navigate that? Like I'm taking, you know, where I am going for this new thing and it could all blow up. It could be for many reasons. How do you deal with that uncertainty?

Matty - 00: 16:26: So I will say one of the ways that I deal with it or that makes it easier, and this is a very important caveat is I'm a white dude. So the risk is less. The reason I'm going to bring this up is saying, again, I'm doing this on easy mode and it's still scary to as someone who's supposed to be an expert. Because the scary thing is saying, okay, well, I'm going to try to learn this thing in the open and people are watching me do it. The concern is I'm going to be in there and someone in the chat is going to be like, oh, dummy, don't you know that the Docker file should be configured this way? Or why aren't you thinking about this thing? So there's that fear. And I will tell you this, as someone who looks like me, that fear is mostly unfounded. And under index person, it's a very founded fear because that will happen. Like I rarely have had someone come up and challenge and say, oh, what a dumb mistake, Matty, you're so unqualified. People think it's cool. They're okay. I helped you. I did whatever. If I was a black woman, I would have a different experience. So I just want to put that into place. That said, if it's framed in the right way, it's always safe to say, I don't know. And it's better to say, I don't know than to pretend, you know, that's one thing I've learned is when I was a sales engineer, customers would ask me questions and I would be like, oh shoot, I don't know what our SSL expiration policy is, but I could just say, I don't know. I'll find out for you. And I think it's a matter of owning things. If it comes up and you say, Hey, I'm learning this in the open and just come out. If you embrace what you don't know, but you're super good at what you do know, it kind of comes in and I'm bringing this in the context of learning in the open and putting this in, especially because we talked about Deverell, I think Deverell's done to do, right? We're being a voice of something and we're all so fearful. We're terrified that someone's going to ask us a question we don't know the answer to because we're very visible, right? And part of that is I don't know is fine. As long as it's, I don't know what I'll find out or I don't know, does someone else know, but just want to talk about learning something new. I think another way to do it is to do it incrementally and say, I want to kind of get better at this thing. How can I connect that to something I'm real good at? Because then my cognitive load is less. You know, you only can focus on one thing at a time. I think about what I did with public speaking, there's tons of things I want to get better at. And if I go up to give a talk and I'm like, okay, here's like the 15 things I want to try to improve, I won't improve anything because all I'll be doing is thinking about everything I'm doing wrong. But I say in this talk, my focus is more movement on the stage, everything else I still do, but that's the only thing I'm thinking about because all the things I'm really good at take care of themselves. So if you're trying to learn something, think about how you can couple it. Like, hey, I want to learn more about PG Vector or something like that. I'm not going to decide to build an Application with that in Rust if I've never used Rust before either. Let me go back to my really old standby that I really understand. So only part of what I'm doing is new. That helps two things. One, helps me focus on the thing I have to learn because I can only focus on one thing at a time. The same thing, if someone sits there, I mean, Kelsey Hightower is trying to do something and doing part of Kubernetes, no one's going to be like, okay, you don't know what you're doing because you just get overwhelmed with his knowledge and expertise of something else. And you're like, oh, you don't know this little thing. So I think that's a helpful approach. It's still hard and scary and everybody is scared. And I can assure you people like Kelsey are scared too sometimes. We all have it.

Joe - 00: 19:29: Yeah. And I think that's a great insight. And I think that also applies to changing jobs. Just start thinking about, there was a point early in my DevRel career where the technology I was dealing with was very different over course of successive companies. But in every time my audience, even with those different technologies was early in career devs. So there was always that strata of I'm very comfortable with this audience and know who this audience are. Yes, I'm doing a different thing with them, but I have that grounding. So yeah, totally agree. I think that's a really good point. On the topic of learning new things, I know you mentioned that, you know, obviously now I've been to a slightly different field doing data management, less DevOps stuff, but obviously DevOps is a very fast-moving field. And I believe there's a new DevOps now is a thing that I saw that happened. I didn't know what was going on with that.

Matty - 00: 20:07: Platform engineering or something like that. Yeah.

Joe - 00: 20:10: But in all those transitions, you've also got that fast flowing current going past you the whole time. How do you keep up with continual learning when you're in those roles, especially as someone with the developer relations slug, you need to be at the forefront very frequently. How have you managed that task?

Matty - 00: 20:26: I mean, part of it is to realize you can't like it's to sort of start with the, Hey, it's a fire hose. You're not going to know everything. One of the things is to be intentional, you know, don't say, Hey, I want to learn DevOps. I'm going to learn cloud. That's so many things. Do it in pieces and set realistic expectations as well, which is this is my problem. I will do this constantly. I find the weirdest edge cases when I want to learn something new. And I'm like, wow, did I make this part? No, you know what? Got the To Do App like everybody else does do that. Don't try to create some weird setup because I have a weird life, right? You know, I mean, like the problems I'm trying to solve are very strange. And so I want to try to solve those problems because it's helpful to me to try to make it applicable, but then it continually ends up with, I have weird problems to solve. Like don't go and try to learn this new go framework by building a common open source tool that all DevRels in the To Do App. And a lot of this has to do with everybody's individual preference of how you learn as well. Like, so for me, and as someone who would continually becomes more and more of a generalist, I find what works really well as things where it's not really learning by osmosis. This is why podcasts are helpful to me in certain ways, because podcasts are the thing where you just sort of get the general idea of stuff. You're most likely not going to listen to a Podcast and be like, I really understand the right way to frame my unit tests in rust. That's hands-on stuff whatever. But if I want to think about how to approach testing and rust, that's really good for a Podcast because it's ideas. And I can do that and I can let it kind of wash over me. And I tend to do that. Repetition is what helps me with those places. The other thing though, as much as I said, don't try to make it too hard. I don't really understand things until I can get myself an actual real world example to solve. And the trick of that is real world. It doesn't have to be serving the very weird problem that Maddie has right now, but even a problem I've had before. And how do I connect this to something as a sysadmin? I would have had to reconfigure my IP Tables. That's a problem I understand that people have. Okay, so I'll try to accomplish to that versus if it might be like, well, how do I do sharding in this? I'm like, I haven't had to do that before, so I don't even understand it. So it doesn't help me. So I think part of it is set realistic expectations for yourself. Connect to your way of learning. These sort of learning styles have been a little bit disproven, I think about like some people, but learning preferences is a very real thing. You have a preference of how you work and what you want. So having awareness of that, like I am not necessarily a follow videos kind of person. It just doesn't help me as much, but I like to read books. But some people hate to read books and some people want to see videos, which is why at DevRel, we create content across all kinds of platforms because everybody has their own preferences. And then one of the biggest things as well is if you can, and this is the hard one, is a mentor and a coach helps, like someone who can help you, but you be judicious with how you do that, right? Unless you're paying somebody, they're not your tutor, they're not there to hand walk you. But if you're like, hey, I'm just stuck. Can you just like rubber duck with me? Can you kick this around? And that could be either someone who's a big expert in it or a fellow learner who's in the same part of the journey. This is one of the things that to be quite frank, we look at all the things that suck about Twitter burning down. Boy, was that a helpful thing? I learned so much from having the ability to just throw a question out there. You get people ranging from who the heck knows this person is that's got six followers doing whatever or charity majors weighing in. And you're like, wow, I can learn a lot from those things. And it's a lot harder now, but you still leverage your network and fellow learners, like get a study buddy, someone who's trying to learn the similar thing.

Joe - 00: 24:06: For folks who aren't aware of the term rubber ducking, when you ask someone a question and in the act of asking the question and forming that thought, you solve the question yourself. So the asking is more important than the other person necessarily knowing. Just being able to frame that to someone is super helpful.

Matty - 00: 24:21:

Matty - 00: I've seen people do that even with blogs, right? Sometimes if I just write a Blog Post to try to figure the problem out, by the time I'm done writing the post, I figured it out because I had to write it down. Yeah.

Joe - 00: 24:31: I will never ever remember the name of this person who said this quote. Well, I use it all the time, which is like writing is a great way to Show how lousy your thinking is. And in the act of writing something down, you will often work out the problem because trying to express it in written words irons it out. Okay. So I want to move track a little bit into talking about the actual practical implications of moving company and how these transitions work. Something that I am cursed with, and though many people are cursed with is after you spent a while at a particular company, there are certain parts of that company culture that you become very fond of. And you don't become that person in the next company who's always like, oh, well, that might last place. But you know, we did X, Y, Z all the time. I am that guy on several dimensions. How do you navigate adapting to and taking bits of company culture with you between these roles?

Matty - 00: 25:14: You know, it's interesting because it will vary based upon the type of role as well. But we tend to do this in leadership roles a lot and sometimes to the detriment. I remember I had a friend of mine who was running marketing at a certain place and they got a new CMO who came from Coke. And it was very much the, okay, how do we turn Jim Beam into Coke now? Right. Right. You know, and it was like, okay, but what I try to do is everything becomes an amalgamation. Right. And especially as I come into places in more of a leadership or whether it's as a Manager or not, but a lot of places I've been when I've come from company to company, that's, I guess one of the things is partially that's why you're brought over as well as they're like, okay, what does work? But one thing I learned, and it took me a while to learn. I had like many lessons in my life. I have to learn the hard way. I will tell you this. Someone when they hire you, they might say, Joe, I want you to come in here and shake things up. Sure. No, they don't. Or if you do that, take a month or two and just have your ears on. First 90 Days is a great book, right? Your first beginning, we feel very needed to prove ourselves. And honestly, in most places, what we're looking for is do you know where the bathroom is, right? Get started. And I learned this when I came to Aiven and I was in a scenario where I was like on one hand, I feel like I'd done that transition a bunch of times where I'm like, okay, I'm going to do it right this time. I'm going to got two ears in one mouth and blah, blah, blah. And then landed and they're like, by the way, you're going to have a new boss. I can't tell you who it is. And they're going to start in a couple of months. And I'm like, I need to prove something because I'm going to have a new person coming in. I don't want to sit there and be like, well, I didn't do anything. I figured out where the bathroom was, but even so it was still observant. So number one is absorbing. And then you can start to say, how do these things mesh? Like what are the things from Chef or PagerDuty or Pulumi or else I've been that were really powerful, it will vary based upon your authority within the group. Like if you're coming in, you have to sort of pitch it and be like, but either way, we're still doing it. Ease into it and treat it like an experiment. Don't come in and say like, here's the 15 different things we did at my last company. They were awesome. Find one and say, can we try this? Let's try doing our standups this way. Cause this was really cool. And let me tell you why I thought it was cool and lead the rest of the Team. Cause one of two things might happen. One might be sure. Cool. Let's try it. Another might be, I see where you're coming from. Here's context you don't have, which is we have people that are 12 hours apart. So we can't do it this way, but maybe there's a way. That's the combo of both. And that's the thing because doing a cookie cutter and saying, well, this is what we did at my last place will not work at your new place because your new place is different. But the kernel of it, the idea and the outcome that came out of it, you can say, what if we put them together and now we have the really good way that works. And also just sometimes the culture is different. I've mostly spent most of my career working primarily for us based companies. And actually we had an offsite a few months ago and all company, all offsite and someone in the company was asking me, he said, Maddie, have you ever worked for a European company before? And I said, no, not really. And I said, here's all the things I really love. This was like standing around at night and something. And a lot of my colleagues were like, okay, but just to be fair, just so you know, cause he's all my European colleagues were like, these things you love are not cause it's a European company. It's cause it's a Nordic company.

Joe - 00: 28:17: Cause Aiven of Finland, right?

Matty - 00: 28:18: Yes. Yes. Aiven was founded in Helsinki is based in Helsinki, Finnish founders, very, very Nordic culture, which has been great. And it's interesting too, because things as a leader that I was like, this is how I want to run a Team and we're going to make a big deal out of this. A lot of my teammates who don't have a lot of this American scar tissue go, I don't understand why do we have to do this? Even I'll give a great example is I believe strongly in a Team culture of when you're on holiday, you're on holiday. So we would sort of joke a little bit like at Pulumi Kat Cosgrove and Lauren. I would talk about like, Joe, if I knew you were on holiday and you showed up in Slack for lack of a better word, we would bully you out of it. We would say, get the F out of here. Right? No, we protect each other. And so I started bringing this up in our Team up at Aiven about we should have this. And they're like, I don't understand who the hell would go on Slack when they're on holiday now, to be fair, most of my Team is European and they do, you know, I mean, but they think about that as a DevRel thing, but to me, I went, oh, that's cool. So this is, it's not a solved problem, but we approach it a little differently. But the spirit of this was we take care of each other and maybe the way that's addressed is different because the Team is different. The humans are different, like, cause some of the patterns and culture that Joe, like you said, you want to bring over from your other place. Those were created because of the humans that were there. You have different humans, you have different problems to solve. So either you're going to come in and build a whole thing that solves a problem that doesn't exist over there, but then we don't solve the other one. But it's like any other type of change. You want to bring people along with you. You want them to be committed and not compliant. You build on the shoulders of giants, right? Every cool thing that I like, that I feel like I've helped make better in the Team, it's a whole assembly of ways we did things in Apartments.com and Pulumi and PagerDuty and Chef, but only the good parts because there's already all the bad parts exist. We don't need to bring bad stuff.

Joe - 00: 30:04: Yeah, yeah, perfect. So we are coming close to time. So before we wrap, I want to make sure that we help some folks who are at the very beginning of this journey. So I guess I would ask like first time, what do you think are some common misconceptions that people have about changing roles in the tech industry? The real myths, the real rumors that people, they get very hung up on before they make a switch.

Matty - 00: 30:24: I think it is that people expect you to come into a role and already be an expert at doing that thing and doing the thing you've already done. But in most cases, there's an expectation of growth. And now there's exceptions, right? There are people who will hire and say, I want to hire someone who's done exactly this before. Chances are you're not going to get that person because no one wants to go do the same thing again. But most Managers understand that. So it is a thing to say, you need to have the background that we want. So number one, the first misconception I think is that you have to have done the job to get the job. What you have to do is Show that you can do the job and you have evidence that you can do the job. That's one thing. When you think about switching roles, I think another misconception though, is that you will be guided to that growth as well. If you want to stretch your legs, if you want to try something that's a challenge, have a plan. Because if I'm a hiring Manager and you're coming to me and you're saying, okay, Maddie, I haven't been a Developer Advocate before, but I really want to be, sell me on it, right? You can say, I haven't done that job, but I've done the job this way in open source, or I've done this thing. So I guess that's less of a misconception and more of advice, but the misconception is that we're hiring people who are already able to do that, are already there, fully formed, ready to go. And sometimes that's the case, but it's not a given for sure.

Joe - 00: 31:36: I guess the other dimension, I think I see that a lot as well, is like people who are worried about their performance on the job. And so they go spend all of their evenings or the weekends studying for the job. It's like that learning and development is part of your job. Like improving on the job is your job, right? I guess that's another way that manifests. No, I think that's a fantastic point.

Matty - 00: 31:52: I think another misconception just in general is that anything is set in stone. Everything is negotiable.

Joe - 00: 31:57: What kind of things are you thinking of here?

Matty - 00: 31:59: Responsibility in the role, money, benefits. I mean, some things are not, but there's lots of levers to pull. The other piece of that is, I guess the misconception is if I try to negotiate, they'll rescind the offer. Now that will happen. And you know what? That's a great thing. That's a hard thing to hear when you're like, I've been out of work for 10 months and I have to pay my rent, but that's a big red flag. It is a big red flag and you would probably get screwed somewhere else. And I had a great Podcast episode with Cindy Miller recently called It's Tough Out There if you go to restdevops.com. And we talked a lot about this combination of this is the general good advice, but then also sometimes you just got to take what you got because you got bills to pay and there's no shame in that. Yeah, absolutely.

Joe - 00: 32:39: Yeah. I mean, take what you have to do and keep looking. And then I guess like last question really squeezing this one in there. If you could go back to the beginning of your career and give yourself one piece of advice about stepping out of your comfort zone, all these marvelous journeys you've taken serendipity, what would that piece of advice be?

Matty - 00: 32:55: I would say, and again, some of this is based on the time of when it was, it's not like go buy Apple stock kind of story, but get even better at cross-functional collaboration. It took me way too long to get past the problem that we all have, which is I'm ops, Dev is the enemy. Have that realization happen sooner about that we're all trying to do the same thing and how can you build those bridges and how to be more of a generalist sooner. Learn more. Learn a little bit about a lot.

Joe - 00: 33:21: Perfect. I think that's a wonderful beat to end on, Matty. Thank you so much. It's been a pleasure. Thank you for joining us today.

Matty - 00: 33:26: Super fun.

Outro - 00: 33:29: Beyond The Screen: An IONOS Podcast. To find out more about IONOS and how we're the go-to source for cutting-edge solutions and web development, visit ionis.com and then make sure to search for IONOS in Apple podcasts, Spotify and Google podcasts, or anywhere else podcasts are found. Don't forget to click subscribe so you don't miss any future episodes. On behalf of the Team here at IONOS, thanks for listening.