PurePerformance - 079 From Scaling Spartans to DevOps for Dummies with Emily Freeman

Episode Date: February 4, 2019

How to you scale a startup, a mid size company or an enterprise software organization? Can we learn from the Spartans or the Romans? And how can we explain DevOps to a Dummy?In this fun filled episode with Emily Freeman (@editingemily), Cloud Developer Advocate at Microsoft, we get answers to all these questions and get inspired to join Emily’s appearance at the upcoming devone.at conference in Linz, Austria where she dives deeper into how to successfully scale development organizations from startup to enterprise. Later in 2019 make sure to watch out for the written version of our discussion on DevOps for Dummies – Emily is using her writing skills to bring it to paper!https://emilyfreeman.io/

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. I got the name right this time. My name is Brian Wilson and I got my name right too. And we also have Andy Grabner, Andreas Grabner, but he'll hit me if I say it that way. So Andy, how are you doing today?

I'm pretty good actually. It's the end of my day here. I'm not sure if I'm allowed, well, sure I'm allowed good actually it's the end of my day here I'm not sure if I'm allowed well sure I'm allowed to say that I already had a beer in the afternoon because they did some photo shooting or video shooting here in the office and they were supposed to drink beer and I got the beer from one of my colleagues to finish it and so my afternoon has been going actually pretty good so I can't complain well well the way my morning been going, I wish I put some whiskey in my cereal, but didn't get to do that. So anyway, we're recording another show today, right? I don't know if at this point Perform, I forget if this is airing before or right after Perform, but either way, it's right around Perform time for us. We've been pretty crazy, but we're here and we're interviewing.

I can't even speak today. It's so crazy, right? Andy, why don't you take over from here? Of course. Well, we want to introduce our guest today. And I'm pretty sure she has also had her crazy stories about getting the year started and being crazy busy with conferences. And today our guest is Emily Freeman, Azure Advocate for Microsoft. Emily, welcome to the show. Thank you. Thank you so much for having me. So how is your day so far? You're also in Denver, right?

I am in Denver, yes. So am I. That's the only reason I asked. That's awesome. We should have done this in the same room. We missed an opportunity here. You know what? Technically, it's easier to do it in different rooms for the audio separation. It sounds crazy, I know, but unless I can get, hey, let's all get everybody. If everybody here, everybody listening tweets at Dynatrace and tells them to build an addition to my house for a studio, then we can do this. So everybody, please go ahead and tweet at Dynatrace right now.

Anyway, Andy asked you how you're doing. Sorry, I didn't mean to cut that off. No, you're fine. I'm doing well. I've got my one cup of coffee down. I'm having my second, so I think we'll be good in about 15 minutes. I'll come alive. I am full on addicted to coffee at this point, but no, it is good. It's really cold here though. Yeah. It's winter, right? I think that's what it typically is in the Northern Hemisphere in January. I mean, is that a surprise for you and living in Denver?

Come on. I think what it is, it's usually so sunny that it's less cold. Like, it is, like, bitter. Okay. So, yeah. I mean, you know, I like my sunshine, Andy. So, Emily, tell us a little bit more about yourself in case people, there are people out there that don't know you. Who are you?

Kind of give us a quick overview of what you've been doing, what you're doing right now. And then I think we jump into the topic that we pick this, the one thing that I'm very interested in. But get started with some intro. Awesome. Yes. So, I am currently a CloudOps advocate at Microsoft, which means I work with in the Azure ecosystem and I'm a developer advocate. The definition of that role is still undecided depending on who you speak to, but I define it as a bit of an intermediary and someone who carries feedback from the community back to the product team so that we can build better products, as well as communicating with the community about what we have coming up and

what cool things we need to do or what we have coming for the community to better utilize. Before that, I was a backend engineer. I wrote in Java and Ruby. And then engineering is my second career. So prior to that, I was a writer. I worked in PR for a little bit. Cool. Well, that's, I think that's helpful, especially that I assume as a, as a developer advocate, you are doing a lot of blogging, a lot of presentations. I don't know, kind of, you know, I think you're writing a book actually. I mean, that may help, right? Yeah, no, absolutely. And when I decided to get into engineering and I went to a code school, I pretty much thought I had wasted my

time and that it was a total waste that I had spent so much time writing when I was just going to become an engineer. But it is sort of my secret weapon, I think, and my superpower in engineering that I can write and communicate and tell stories. So I'm really lucky that I've found a role where I can kind of use both those skill sets. Cool. Right. Because as you know, communication is very, very important. And not to disparage developers in a lot of ways, but a lot of developers have these brilliant minds, but not necessarily the social skills. So having somebody that can bridge that gap where needed and having that skill to introduce into it is, and of course I don't mean all

developers, obviously, but there's, you know, you have your head down and yeah, anyhow. Absolutely. No. And I think that's one of the, you know, sometimes developer advocacy gets under some heat for like, why do they exist? And I really feel we fill that gap and we allow engineers to focus on the things that they want to focus on. And because we are like, I mean, there are advocates who are much closer to the keyboard than I am. I do a bit more talking than some people, but I definitely think that I'm never going to be the most technical engineering engineer in the room. And I think that's awesome because I'm someone who can speak to that engineer and kind of get what they're

talking about, distill it into another message and then convey that to whatever audience I'm speaking to. Hey, and Emily, we actually got introduced because you are going to speak at DEF ONE in Linz, Austria, later this year, right? Yeah. And I know I wanted to switch topics, but I mean, just a quick overview, and maybe we come back later in a more detail,

but what are you going to talk about at DEF ONE in Linz? Yes, my talk is Scaling Sparta, Military Lessons for Scaling a Development Team. And it's a fun talk. I think it's a unique perspective and a sort of unique point of view for how to talk about scaling. But it basically breaks down companies

into three types and based on size. So in my opinion, you have your startup or your small business. You have your mid-sized company or that sort of late stage startup. I know a lot of companies at this point who aren't startups still like to call themselves startups. And then you have your enterprise and large companies. And I kind of use an analog for each of those so that Sparta is the small company, the Mongols are the mid-sized, and then the Roman military is our enterprise. And we kind of go through each military, what they prioritized, and how we can kind of take those lessons learned and apply them to our dev teams. Cool. Well, now I also understand probably why I definitely wanted to have you speak

because as Dynatrace, right? I mean, DevOne is a developer conference, but Dynatrace is kind of hosting it and having you then in Lintz where we have a community here in this region where we have a lot of startups, but also companies that are kind of probably grown out of being a startup into the next phase. I think there's a lot of startups, but also companies that are kind of probably grown out of being a startup into the next phase.

I think there's a lot of people that will benefit from your insights here in this particular area of Austria. So that's why it's great that you're coming and talking about this topic. Very valuable in our scene here. That's awesome. Yeah. I'm excited to hear that. Yeah. I'm excited to hear that. Yeah. Now, maybe we can have a little more time later on to go into more detail on Sparta. But what really intrigued me is a book that you're writing right now.

And obviously with your background in writing, I'm pretty sure it's going to be an awesome book. But can you just reveal the title and your thoughts on why you wanted to write that book? Yeah, definitely. I am writing DevOps for Dummies. And it is the Dummies series. So those yellow books you're used to through Wiley. And it is a very, very high level, given that it's for Dummies. Book on DevOps and what DevOps means, setting it up, kind of making that transformation.

My goal is to make it friendly for everyone. So if you are a developer who's never heard of DevOps, because in my opinion, DevOps is still very ops focused. And I think a lot of developers get a little intimidated because they're not super familiar with infrastructure and areas like that. So they don't really go there because a lot of times in engineering, we're all afraid of looking stupid. So it's definitely for that person, but it's also for people who are just curious about integrating it into their company or transforming their company into a DevOps organization. And also for managers. I think a lot of times we as engineers don't do a great job at teaching our managers how to manage us. And so one of my goals for this book is to really help any kind of manager who's reading it understand the stresses and circumstances

that we develop and deploy code in um and then how like what kind of support we need from them so that's that's sort of my my high-end goal um to make it friendly and certainly to integrate the philosophy of devops into more people's organizations do you have a um I'm not sure if it's the right term, but like an elevator pitch or like an analogy, how you would explain DevOps to like the dumbest of the dumbest, like in a quick conversation at a water cooler? Yeah, it's funny you mentioned this now

because I just decided yesterday, I was talking with Chris Short, who works at Red Hat, and he was asking if I have a definition of DevOps for the book. And I was like, I don't. I need that. You're right. So we're actually going back and forth right now to figure that out. I think it would definitely vary depending on who you're talking to. For me, DevOps is a way of ensuring that development teams have the tools they need to develop faster and better. Definitely. I think, you know,

Nicole Forsgren and her co-authors covered this a lot in Accelerate. And it's mostly making sure that, okay, I think we've figured out a lot of the technical solutions. I think we are at a point in tech where our technology is almost evolving faster than we are. And so a lot of the problems we have throughout the development lifecycle are really human-related. And the thing that I love about DevOps is that it prioritizes people, process, technology in that order. And so you're making people the center of it. You're making sure they feel psychologically safe. You're making sure that you have a learning organization, that employees adopt a growth mindset, that you're not afraid of failure, that you embrace failure and practice for it. So I think creating that environment is incredibly

important and making sure that incentives align with that type of thinking. But also then you're looking at process, right? How can you make your processes better suited for your people? So like if an incident comes up, what kind of processes do you need in place so that the first responders can actually mitigate the situation? That type of forethought is really important. And then the technology comes last, right? Our tooling, there are so many tools that solve the same problem. And I don't think there's a certain prescription. I don't think there's any point in tech for one tool to be the silver bullet. It just doesn't work like that. You know, all of our organizations and challenges are unique.

And being able to find the tools that suit us andynatrace employees still bring to the podcast. It's also in the name Pure Performance. So performance people, performance practitioners, performance engineers that evolved over the last couple of years into, let know, let's say DevOps engineers. But I think a lot of our listeners are probably still on the performance engineering side. Does this role have a place in your book? Do you talk about, especially, I guess, from a technology, but also process perspective where monitoring and performance kind of fits into DevOps in that transformation? Is there a place for that?

Absolutely. Yes. I think in several places, but absolutely for monitoring and visibility, I think that's where a lot of the tooling helps us and makes us superhuman in that it can keep an eye on things. And if we set it up correctly, it can alert us and even automatically mitigate certain issues, right? So you can actually train your tools to do things that humans used to have to do. And now we can sort of think at a more broad and holistic view

rather than doing this low- work all the time that that certainly can be automated so yes performance engineers have a huge a huge role in any kind of engineering organization but certainly in one that adopts DevOps cool um now from I mean how long have you been again working at Microsoft oh I enter I started at Microsoft in October, so not super long. Okay, cool. So we had over the last couple of months and years a couple of folks from Microsoft on the show.

Donovan Brown, one of them, a big advocate for DevOps, telling the Microsoft DevOps transformation story. Do you know Donovan? Have you worked with him? Yes, absolutely. Donovan is one of, I think, the most polished speakers I've ever seen speak. I saw a keynote on just DevOps at Microsoft and how they've kind of gone from two-year releases

down to three-month releases, down to two-year releases down to three-month releases down to two-week releases and kind of accelerated their development lifecycle and certainly adopted a more CICD approach. But yes, I haven't had a chance to work closely with him, but he's awesome. He's also very enthusiastic. Yes. That's great. He's awesome. Exactly. Yeah. Yeah. He's also very enthusiastic. Yes. Yeah. It's great. He's awesome. Exactly. Yeah. Yeah. Yeah. And I just wanted to give him a shout out because he helped us pipeline concept, kind of baking monitoring and feedback into delivery pipelines

to act as quality gates on the one end, but also act to control what happens with the problem in production. And he helped us bring it into the Azure DevOps ecosystem. That was really nice. He brought in Abel Wang, one of his team members, and in collaboration, we got it on the road. So that wasrosoft and i think we brought it up over the last couple of years since we've been doing this podcast um it came up more and more that that and i think brian you you can probably explain it you explained it several times that the microsoft that we knew yeah well donovan donovan really clarified yeah i i tend to ramble when i try to explain something because that's just the way i do but donovan just said yeah this is not um well it's funny because we just had this conversation

about you all earlier right but he said he put it as this is not your father's microsoft um but it's not the microsoft of old it's not the microsoft we all grew up knowing and kind of grinning and bearing and dealing with i used to to work at CNBC way back. I was a video editor before I got into technology. And I remember when the whole big thing went down where there was the monopoly thing with IE being pre-installed in every instance of Windows. And it was just crazy. And we're not going to show any of our code.

It's all secret. It was such a thing. And now everything was charged for. And what always kills me, what kills me in a good way, is I can hop onto Azure and get a Linux piece, run.NET Core on it,

pay no licensing, and all I'm paying for is whatever hardware I'm running that on. And it's like such a different model. I mean, and all I'm paying for is whatever hardware I'm running that on. Yes. And it's like such a different model. I mean, not that I'm encouraging people to do that, but like such a different mindset. It's crazy. But I mean, this is the big split, right?

Azure was split from Microsoft, the operating system side of things. And unfortunately, we don't get to see Bill Ballmer getting on stage. And that's, I guess, the one downside of it is we don't get to see Bill Ballmer getting on stage and ranting and making a fun fool of himself but yeah it's it's a whole different kind of company now it really is and i um i put a lot if not all the credit at satya's um work and and sort of mindset he has completely transformed the organization. And I think it's interesting. I have this funny theory, I think about Microsoft. Do you know the, the concept that Russian leaders go from bald to having lots of hair to bald to having lots of hair? Have you ever heard this?

Okay. This is a thing. So like they, they oscillate between a leader that has a lot of hair and then none um poon's got a pretty i've seen that picture of him uh shirtless on the horse i forget though if he's got a hairy chest he's no well he he's bald though like head head and right now i know but i was just wondering i was just trying to remember if his chest was hairy i don't know sorry sorry to bring up images of shirtlessless on a horse. I know this took a turn. I don't know. But yeah, so that's a thing. So now I am applying that same thinking to Microsoft in that we have like a visionary CEO, a CEO who is a lot more focused on, you know, quarterly, quarterly income or revenue. And then we're back to a visionary CEO.

And I think it's great for Microsoft as a long-term company and thinking more about the developer and less about, we are so much less, or at least my team is trying to, it's a big ship, so there's a lot to turn around. But one of the things my team focuses on is, is turning Microsoft from like a sales and marketing driven organization to a developer driven organization and making sure that we're centering the user who are engineers, um, in everything we do. No, I think we all, we all love the new, the new Microsoft. And, um, we also like that there's obviously competition. I mean, we are, you know, we are playing and, you know, a lot of enterprises out there are playing with all the big players out there when it comes to the cloud, to the cloud infrastructure providers.

And it's great to see that. And on the one side, it's great to see that there's competition out there, right? Because you are all getting better with competition. On the other side, I think it's also great to see that we are still all working together. I'm just looking at DEF ONE again, coming back to our conference here in Linz, looking at the current speakers page, right? It's you, Microsoft. You speak next to Nikki Klein, tech evangelist at AWS.

Then you have Adrian, also from AWS, and there's a couple of other people lined up. So we are all, in the end, as advocates, working together and working for the benefit of the larger developer community that are going to build the backbone of our

future society, which is everything, all the software that's powering our lives. You're such an optimist, Andy. See, I keep on thinking this is all happening right now because there's plenty of money. And as soon as it starts drying up, it's going to be Hunger Games. Or we'll all pull an Oracle and start charging for things that were understood to be free forever. Yeah, I'm very curious, not to go very dark, but like what happens in the next sort of

contraction and recession with some of this. And I wasn't, I wasn't in tech for the last one, so I'm not sure exactly how this is going to go down, but yeah, I'm very curious how, how it contracts and what the market does when that happens. Yeah. It'll be interesting, especially with like, you know, Kubernetes so prevalent and you know, who's got controlling interest controlling interest it's yeah definitely a lot can happen maybe uh i will i will hope for andy's vision of the future where uh everyone will still get along um yeah but i know what i think in the back of my head you know we can all we can we all we all play our parts we can just uh and that's why emily coming back to you at dev one so you play your part uh you know, standing on stage

side by side with official competitors, but still friends in the community. Now, to your talk, because we want to definitely make sure that this podcast has been listened to by attendees of the conference and whoever wants to come to Lovely

Linz Austria. And I can give you some recommendations later on because you asked also we can talk about Linz a little bit um but um you gave us the kind of quick overview of what the session is going to be about any other things you want or you can share that you think this is something that in case you can't make it to the conference then you need to know this about my talk because you should go to the website afterwards and watch the video recording yeah i think the big takeaways um certainly are that small groups matter so i think one of the things that um is compelling about the spartan army is that they they trained in a very similar fashion they were all equals and they had autonomy. And I think that autonomy is incredibly important for engineering teams. mission is, what the actual target to get done is, and then allow their teams to accomplish that

in whatever way they see fit. That's when you really see, I think, great engineering and really awesome opportunities for engineers to explore different methodologies, different languages, different tools. So yeah, I think the why from a leadership perspective is a lot more important than the how. And then as you scale, it's not so much trying to organize in these huge groups and trying to address 2000 people and getting 2000 people to work together. It's instead maintaining that autonomy and treating your Roman military like a bunch of little Spartans. And the military, even our modern military groups things. So they have a group of 10 and then a group of 100 and so on. And I don't know the exact of each military, but you have these sort of small

groups that act as independent units and then together make up the whole. And I think that approach is really important, especially when you get into, you know, separating different logic and microservices and all of that and allowing different services to be one written in Java and one written in, you know, Python and having them play together. I think that's where you really need to see that autonomy and that small group perspective. I liked what you said earlier. Hopefully I got this right. You said the small teams are all equally trained,

they're autonomous, and it takes a strong leader to give them a good vision. And obviously the leader has to trust the team to execute on that. Can you, maybe you said this, but maybe you can then repeat it or if you didn't say it say it uh what's the what's the different skills then for a leader uh in a large organization what's the how would you characterize the the leadership um the leadership change there? Or is it still the same, but it's? I would say in the smaller organizations, you're a lot like you as a leader on the front lines, like if you're in a truly small startup, most likely a founder is part of the engineering team

or leading the engineering team and is more involved in the day-to-day decisions and if not writing code themselves. As you scale, I think it becomes a hindrance for that founder or that engineering leader to still be committing code. And I think it's really, really hard for those founders to kind of let go of that and to step back away from the keyboard

because like all of us, we're afraid of losing that closeness to the keyboard and that, that technical knowledge. Right. But I think as you scale, being a manager is a full-time job and, and being a manager is an important skillset that I think gets overlooked because we don't value it so much in tech, but a great manager. I mean, you almost don't know that they're there because they provide cover for you. They handle the external forces so you don't have to. They do provide that clear information and that clear vision

so that you know what's going on, but without the minutia or the drama that may be happening around you. And they also amplify. And I think the bigger an organization, the more important that is for a leader to actually advocate for their employees and to amplify those voices and to make sure that people have clear career paths ahead of them. You know, they're getting those raises and those bonuses, they're getting promotions, and to protect everyone, to make sure everyone's getting the opportunities they want, that everyone's feeling fulfilled, both personally

and professionally. And so yeah, as you scale, I think the leader has to become more of a leader and less of an engineer. Funny that you were using, you changed back and forth a few times between manager and leader there in terms of using the word. And I was actually in a position a while back where I was a manager of a performance team where I was still doing about 70% of the testing work. You know, couldn't really do my job as a manager or leader. But what I think is important for people to understand, there's a huge difference between, I think, being a manager and being a leader. And I think what your point is there, if I put it in my parlance, is that you need to become a leader who has management skills. Yes. Right. When you're up there, because there's, I think, one of the biggest problems in the modern workforce is we have way too many managers

and not enough leaders. Yes. Absolutely. So I would just stress to people, you know, if you want to take that step up, go read about being a leader, find out what it means to be a Yes. Absolutely. And then in the end, get things done. It's funny, your descriptions there, too, sound a lot like, you know, I only know military stuff through like the movies and all. Right. But, you know, you have and I don't know the terms, but when you have the soldiers in the field, I think it's like the sergeant or whoever is there locally is right down there with them carrying the gun. Right. But that's a different, much different kind of role. Once you get into the rear office and you're calling the shots, you're putting down that gun. So it's still kind of fits into that whole military model that you're, you're talking about, but without even having to stretch it at all, it's just a natural fit there. It's the same kind of analogy. Absolutely. Yeah. Two things. One about the leader. I think one of the things I try to

emphasize in all my speaking is that no one is in charge of your career but you. And if you want to grow and if you want to see change in yourself and your organization or even in the industry as a whole, I think pouring energy into yourself and investing in yourself to become a better leader is one of the best things you can do. And you don't need to have that title to be a leader. I know many leaders on their engineering teams. You can be a junior engineer and still be a leader. And so, yeah, definitely there is a bifurcation there. But I think one of the things with military, and I have another talk where I go into like firefighters and their procedures. And I think as software engineers, we forget sometimes that we're very

young. Like we are, you know, 100, 200, depending on how you want to phrase it, your old industry. And so you have lessons that we just haven't had the opportunity to learn that other industries and other trades have already covered. And I think by applying those lessons from these other centuries-old approaches to things, we can accelerate our own kind of procedures. Maybe someday in the future, people will be using software engineer analogies instead of factory analogies or military analogies. Yeah. It's an interesting point.

I hadn't thought about that, but yeah, all the analogies come from these more historical. Yeah. I did have a question for you guys in writing this book. One of the things that is starting to bother me is a lot of our DevOps knowledge comes from like the Toyota manufacturing process and it is very manufacturing based. And for me, I think it works to a certain point and then it doesn't because engineering isn't factory work. Right. It is it is creative. It is kind of an art form. It is not a prescriptive industry. You can solve the same problem a hundred different ways. So how do you, like, I'm always curious what people think about, does manufacturing work? Do you, do you find another, other information more useful or

any thoughts on that? I'd be very curious to hear. Well, I still, I mean, first of all, I like the Toyota reference. And I think if you would use a different product than a car, it obviously takes a while. And also the material and all that, if you use something that is easier to produce and faster to produce than maybe back in the days, they would have also started experimenting more if they would be more flexible. But the analogy that i used to explain devops and that was also why in the beginning i asked the question so what's your analogy what's your elevator pitch um one the way i explain it is and this is credit goes to my wife because she inspired me to that story because i i tried to figure out how could I explain DevOps and what we as DevOps advocates, and I also, I call myself a DevOps advocate or an activist.

How do I explain to my parents what is currently happening in our industry and what I do in my day-to-day job? And the analogy that I came up with is I said, mom and dad, you remember, you know, 15 years ago or 20 years ago when I was still a teenager and we went on the trip with our Kodak cameras and we started taking picture on the trip. And if the film roll wasn't full, we just didn't click all the pictures to make the film roll full because it was a waste of resources. So we took the camera with us, half full film. And weeks later, we went on the next trip where we made the film roll full then we shipped it to the film to a development company they had the

dark room the person there did the best what they could quality control if everything is fine and then weeks or months after taking the first picture they uh we got the pictures back right in the envelope it was mailed back to us. And this was the exciting moment. And then sometimes we realized that the pictures were completely crap, right? And out of frame, out of focus, and not the people that we wanted to have on the picture

in case somebody photobombed us. And that's kind of the old way of, you know, it's very rigid way. You can, I could go back and say, I'm doing the trip again, but it takes a lot of effort and time to take these pictures again. But the analogy now is how things change. And what for me DevOps is, is still that picture analogy.

Because if I look at the way my wife takes pictures and the way you do it and Brian, we take our phone. So I take the picture. I see it immediately how the picture is going to look like. I have tools on my phone, like the photo apps to make the picture better right at the spot. And now here's the big change. Instead of sending it to somebody that then prints it out so that I can show it to people, I have the tools on my phone to click a button and publish it into the cloud on Facebook, on Instagram, wherever it is. And then I can experiment because this process is so fast.

This is something I couldn't do before. And I believe the next big change here is, I mean, first of all, the change from the Kodak example. I had a clear separation of who creates the picture, who develops it, who ships it, and then who looks who is the customer. Here now, everything is in one. My wife, she decides what picture to take, what to do with the photo app to make it as good for her, that it is a minimum viable product that she wants to publish, when to publish it, who to share it with. And then the most important thing is what to do with the feedback.

If she gets negative feedback, maybe she decides to defend it or she takes it off or she starts to experiment, right? She wants to get more likes. We all want to get more likes. And I think that's kind of my analogy with the picture story is for me something that just resonates a little bit better, right? From the takes weeks to months, from the first picture until I get it. And otherwise, and experimentation is hard. But now the modern ways, it just makes a little more sense for me

and encourages experimentation. Yeah, I really like that. I also like that. I think one of the challenges we see is there's some people who work for more traditional organizations or still have, you know, hosts on premises. Like they are, some of those engineers are afraid that they are becoming obsolete or that they will lose their jobs or, you know. And I think the photo analogy allows this,

this consideration that we can be generalists as most of us, but there are still room for specialists, you know, like I hire a photographer to take photos of, you know, me and my daughter do my headshots, um, because I, she does them better than I could. Um, and so, yeah, I like that there is this, this focus that there can still be the, these specialists who, um. Yeah. Well, and there's also, and there's also the people that need to build that pipeline, right? Because there's somebody that needs to build the phone, the photo app,

the platform where I post the pictures, right? And that's what it is, right? And in the end, the way the analogy that I drive to DevOps, there is a team that makes sure, just what you said earlier, I believe, DevOps is all about giving the developers the tools and processes so they can develop faster and better. But I think what's missing in that is also to put them into control, just as my wife is in control to decide what picture to take, when to deploy it, and what to do with the feedback.

I think this is the last missing piece of the cultural transformation. It's not just about producing better and faster code. It's also taking responsibility to make it into something that is beneficial for the company you're working for, the organization you're working for, the team, and therefore also working with the feedback and being responsible for that. Yeah, yeah, absolutely. Wow.

Yeah, I don't have too much to add to that. I was going to sit here and defend the Toyota model a little bit. But the thing is... It's a great model, right? It's a great model. Well, with Andy's, obviously, first of all, you have to assume that people are old enough to know old film but i think it's definitely a lot more relatable um in real world terms the only thing i was going to say about the factory model thing is is to me at least um it was now the the mod that model was never about the art

that goes into it that was about you know we talk about people, process and tools. The factory model fits that very well where the art comes in is, you know, what's being produced, the details on how it's being produced, right? You're, I always kind of look at the model as the bigger picture of it, not in the details, but obviously as you say, yeah, there's a lot of art to the way it's done, a lot of different ways things can be done there's not just one you know meanwhile yeah there's this idea of the toyota factory but the way you know like model it on that but the way the detailed side of it the way what type of code is written uh how you might even put the tools together you know we see people doing all sorts of new creative things with different tools because so many awesome tools these days have these APIs that suddenly you can say, Hey, I want to use this in this way.

I'm going to plug this into here and get something new, but you can still do all that within the confines of the model. But I get what you're saying. I just, yeah. Anything could be even continuous improvement, continuous development. Let's get a continuous development model of what the model is. Yeah, no, absolutely. I think that's, that's important. And I, I, um, you know, as, as someone who gets up on stage and, and spells out these, you know, idyllic scenarios in which you can, you know, do all the things quote unquote, right. I love talking to people because it's just not that way. Like life is messy. Our code bases are

messy. Our teams are messy and kind of embracing that and allowing ourselves to, you know, give ourselves grace for where we're at, no matter where that is. I don't care if you don't have a test suite or whatever you're missing. And then to just incrementally improve. I think that is, maybe that's my takeaway for DevOps. Incrementally improve. There's no nirvana here. You can kind of reach for that, but you're never going to get there. And that's sort of the point. You're just striving for excellence. Continuous improvement through continuous experimentation enabled by continuous feedback. You need to be like writing blog posts. Do you want to write this? I've never written, I've never written a single blog post in my life. You've come down with two amazing amazing ideas here that's that's

the austrian humor that's there's actually an entire i mean i hate to lump germans in with austrians but their south park addressed the entire thing with uh the the the joke bot or whatever the german joke bot um just to stick it to you and Andy. How about you? Just like people can... Also, Christoph Waltz does a pretty good explanation. You know, the actor, Austrian, who he was in late night shows and he did a great explanation

on the humor. But he actually compares the German humor with the Austrian humor and we actually get off pretty well compared to the Germans. You're funnier than them? Good, good.

So Andy's written tons of blogs. Oh, okay. Yeah, yeah. Just to clarify, yeah. Your dry sense of humor. Yeah, yeah, yeah. I'm not getting paid for jokes, right? I'm just getting paid for other things.

That's why. That's what it is. So anything else we want to address on here or should we uh be uh summarize emily was there anything else you wanted to bring up or i'm just really really excited um to be in linds in april that's gonna be yeah i think that'll be like good weather, right? It won't be super hot. It won't be super cold. Yeah. I mean, it always depends, right? It's always hard to say, but typically April should be good.

Unless we have a cold front coming through, you can still have colder weather, but it should be fine. Yeah. And regardless the weather, I mean, Linz for a couple of days has a lot of cool things to give, right? I mean, so you've never been, right? I've never been to Linz for a couple of days has a lot of cool things to give, right? I mean, so you've never been, right? I've never been to Linz. I've been to Vienna and that's it. But you've seen some of the music, right?

So it's a short train ride from Vienna. Yeah, hopefully you take a train because it's door to door an hour and 15. And yeah, Linz, you know, I I think since we big steel city traditionally but converted or changed in the last couple of years like many other steel cities I think around the world into technology biotech art we used to be the European capital of culture in 2009 and that transformed the city quite a bit I mentioned in the beginning the startup scene, I think is pretty good for Austria. And Ars Electronica, I think I mentioned that. It's a big thing that people typically know.

And yeah, lovely old town, you know, founded by the Romans many, many years ago. And a lot of history here. So check it out. Also good bars, restaurants, good beer. Yes. Andy, we'll have to send emily the oida video oh yeah that's right yeah that's my the oida is more vienna but still good yeah it'll still make us the people still be impressed they're like oh okay this is awesome i'm so

excited yeah um yeah and thank you thank you guys for having me on. And so I could talk about the book and talk about scaling Sparta and get excited. Yeah. Yeah. Yeah. And for the talk, would it help for people to watch 300 as a preparation? I do make a joke. I still haven't seen that movie. You really haven't? No. Wow. Wow.

Okay. Do you live under a rock? Is that? Yeah. I mean, I was a film major. That movie didn't look too impressive to me. No. And I think there were a lot of criticisms of it. And even so, like one of the things that comes up in the talk that I didn't fully appreciate when I first wrote it was that everything is written from a Greek centric

viewpoint because that is where we get our stories. And that is where, you know, the, it is now very West or European centric, our history, but at the time it was still very Greek, the Greek authority. So they sort of wrote their perspective on it, certainly not from the Persian perspective of that conflict, which was interesting. And Persia was a very interesting society in that I think they didn't have any slaves, which was interesting. And certainly in contrast to Sparta, which had a 1 to 50 citizen to slave ratio, huge slave population. But yeah, certainly not a fair comparison. And there are plenty of criticisms for that movie. I'll see it someday.

Andy, do you want to give a brief – sorry, I know we're a little over time on our scheduled thing. Do you want to give a brief summary of anything? Yeah, sure. Very brief, no. And then we call it a day. Well, for you. Yeah, I know. Call it a morning.

Come on. Do it. All right. So Emily, that's typical I try to summarize in the end. But I think we, so what I, I took a couple of notes while we were talking. And I think we obviously started from talking about DevOne, then went over to your DevOps for Dummies books,

which I believe hopefully we helped you getting some more inspiration of your initial pitch, your elevator pitch, on what DevOps really is all about. So I think DevOps, giving the devs the tools to develop faster and better. I think the issue will be also with more responsibility in what they're doing. And it's all fostering, it's all going towards continuous improvement through continuous experimentation enabled by continuous monitoring or feedback loops. What I really liked, though, is your kind of overview of what you're going to talk about in Linz at DevOne,

how to scale organizations, because I believe many organizations, and that also includes ours, right? We grow over the years, and I think scaling is a big challenge. And learning from you how to deal, how to organize teams, small teams that are equally trained and autonomous, and then having a strong leader versus just managers, leaders that give you good vision and trust the people to do what they, to implement the vision that they set out.

I think I like that a lot. And the last thing that I wrote down is a very good advice from you, is nobody is in charge for your career than you. Nobody other. You are in charge of your career, even though a good leader and a good manager is obviously seeing the potential and making sure that you are advancing the career in a way it should advance. But in case you don't have a good manager or leader,

then it's not them to blame. It's you to blame for maybe staying too long there. And you're in charge of your own career. Yes. That's what it is. Absolutely. Thank you for the wrap up. That was great.

He's created that. Andy's got many, many talents. For anybody who's interested, actually, that whole in charge of your career, I mean, that says it right there. But if you like, read a little book that goes into more detail. I remember one thing that inspired me way back was this book called The Dip. It's a pretty short book, but it's really just talking about you're at this point here. You feel like you're at a lull in where you're at in your company. And it's either that you're not preparing to go,

preparing yourself to skyrocket and take that next big step where you're at, or making the evaluation to say, you know what, this is absolutely a dead end and there's no way I can turn this around, die for me to jump and move somewhere else. But it's just a little, it was a good inspiring for me at the time that I needed it, to how to evaluate where you are in your career at the company you're at and figure out if you have the ability to take it somewhere else or not. But a good little book for people to check out. I forget the author, but it's just called The Dip. Anyway, Emily, thank you so much for being on. I'm glad we could finally get this scheduled.

Yes, thank you so much. It's getting sunnier and it's getting warmer. I think we're going to hit up to 50. So hopefully, hopefully you'll be, and hopefully it'll melt the snow that I didn't get to shovel off my sidewalk. But,

yes, thank you for being on. Good luck at Lintz. Unfortunately, I won't be there. I don't get invited back. I never, yeah,

I haven't been there yet. Andy, you gotta, you gotta get me over there somehow, someday. Yeah. They call them planes to get you here something something through the company this way it's expense and i also have to figure out a way to get myself over to barcelona for a replay so i gotta get myself inserted into that because i love barcel Anyway, thank you so much. Thank you. Happy New Year, although it's a month in now.

Half a month. Let's not. Well, this airs a little later. Oh, that's true. But if anybody wants to be a guest or has any feedback, anything, you can tweet us at pure underscore, no, pure underscore DT, or you can send us an email at pureperformance at dynatrace.com. Emily, what's your Twitter if people want to follow you?

Editing Emily. Editing, okay, yes. Very good enunciation. My daughter's getting on me from that. I'm from the East Coast, so I say editing. And people are like, is that edit? We're like, oh, jeez, yeah. So, yes, I'm trying to pronunciate more or enunciate whatever.

Hey, editing Emily, there you go. Hey, forget about it, you know. Hey, it works. Yeah, all right. Andy or Tony, thank you. I've got nothing more, yeah. Okay, we're done. Thank you all. Thank you, everybody.

Thank you. It's in the can, yay.