PurePerformance - DevOps is 80% culture: But what does this really mean with April Edwards

Episode Date: June 27, 2022

While this episode started out with a recap of April Edwards (@TheAprilEdwards) keynote called “Putting the Ops into DevOps” we quickly got April talk about what measures Microsoft has set to embrace the cultural change needed for their DevOps transformation: Every service has a public health dashboard, putting the customer in the center, make products open source, eat your own dog food, align your objectives with the team, …Besides this great conversation that finally gave some great input on what cultural change really looks like we learned from her background in Ops, moving to Dev, getting into the cloud and now inspiring Ops teams to have it easier in their job using automation. Tune in, learn and get inspired. We also talked about the late Abel Wang and how Microsoft UK is supporting Girls Who Code.Show Links:April on Linkedinhttps://www.linkedin.com/in/azureapril/April on Twitterhttps://twitter.com/TheAprilEdwardsPutting the Ops into DevOps keynotehttps://globalazure.at/sessions/#323994Supporting Girls Who Code in memory of Abel Wanthttps://www.justgiving.com/fundraising/msbuild2022/?WT.mc_id=modinfra-67727-apedward

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 Brian Wilson and as always I have with me my wonderful co-host Andy Kravner. How are you doing Andy? Making funny faces at me today. I know, I'll try to make you laugh at the beginning but I guess I don't succeed. But Brian, I met a feedback last week from a colleague who was listening to us

and he actually said we are funny. He's listening to us because we're funny. And I didn't believe him, but he must have three beers. I don't know, after three beers, he said we're still funny. Oh, yeah, yeah, yeah. Well, if you're on three beers,

I'm sure anything's funny, right? Exactly. That's all right. Well, thank you, whoever thought we're funny. We're going to take the show on the road and go start doing stand-up yeah that'll be really really um i can't imagine sitting through a bunch of computer jokes actually maybe five minutes of it would be good but i heard another another thing uh today from one of our users she was saying she was binge listening pure performance podcasts. What?

Yeah. Look at that. That's crazy. Look at that. We still have an audience. It's fantastic. And she was picking out a conversation we had with Tarash,

remember the guy from Facebook? Yes. The performance engineer on how important it is to bring observability data to the engineers so that they can make better decisions on the next line of code that they're writing. If you bring it to them into the environment that they live in, not necessarily have to force them into the observability platform itself.

Yes, that's awesome. That's awesome. I have a feeling there's going to be some kind of transition coming up here though. Yeah, of course, because we're not only here to talk about past episodes that people listen to, but we talk about the future or the now. The episodes of performance past and the episodes of performance future. Exactly. We could do a whole special on that. No, today I want to say hi, welcome, and actually willkommen, because I know that April, our guest today, she knows German at least. Oida.

Oida, yeah. will comment because i know that april yeah our guest today she knows german at least in this case it would be it would be all day because all day is male believe it or not even though it ends with an a and all day would be the female version but i let's not go into this direction april welcome to the show when i finally give you some time to say something and stop our strange laughter thank you both glad to be here today yeah i know a little bit of german but i'm better at hearing it and reading it if i go to speak it french comes out and it's really embarrassing oh french interesting i yeah i took french for years and i never use it and i can't speak about i'm in france but as soon as i go to speak german i speak French so yeah hey April so I invited you because I heard you give a keynote at a global Azure Austria and this is also I think the Austrian connection we then talked a little bit about you know why Austria and then you said you know you're here from time to time like in

Klagenfurt you've done the Ironman here but before we go into this I want to talk give you the chance to actually say who are you because maybe some of our listeners don't know who you are what do you work on right now who do you work for and what's your passion? Sure so my name is April Edwards I'm a senior cloud developer advocate and DevOps practice lead and I work for a very small company called Microsoft. Some of you may have heard of them. They might do well. Yeah, they do okay. They do a few products some of you may be well aware of.

Yeah, so I've been working there for over four, gosh, four and a half years now. And I started off in the operational space. And then I moved into development into my career kind of accidentally. I started getting into this thing called cloud. And I started automating things a lot more. And then moved into the development space to do more things with code and move down that application stack. And what really drives me is seeing people do something with the knowledge I've shared or I've created, which I think is always great. When you do something and someone out there actually finds what you do is useful.

So whether you write a script or, you know, like Andy, you've said you saw me at Global Azure giving my keynote. Like, I hope people took something away from that that was beneficial. So that's what drives me to do what I currently do. I head up a lot of the DevOps stuff. I'm focusing a lot more on the operational side of DevOps. We hear a lot about DevOps and developers, and it's important, but operational people don't inherently know Git and source control, like why to use these things, what they are, and these whole pipeline things. So I'm focusing more in that space at the moment. And my predecessors at Microsoft are a lot more in the developer space. So I've kind of changed my focus a little bit.

So that means, it's actually funny, but depending on who you talk to, DevOps has a different meaning. If you're talking to a developer community, they may say, well, it means we are using, we are now asked to do more operational stuff. That means we bring our best practices, but not only build software, but also we build it, we run it. And I think then when you talk on the upside, and I think this is what you are targeting right now,

or inspiring people, I really like it. The thing that I wrote, like I took some notes when you said, it's really great because it inspires if you see people actually applying things you you showed them uh so that means you're you're showing uh operational helps folks if that's the right term right so how to use a kind of development best practices to actually make their life easier like version control automation um i don't know, maybe even testing, right? Who knows?

Because we've been forcing test-driven development on developers for so long, maybe test-driven operations is something that we should think about as well. Now, that means in your work, is convincing ops folks about the importance of version control still a big topic?

Or is this, I mean, this actually surprises me. You know, I wouldn't say convincing is the right word as such. But I would very much say that it's teaching them, and I say teaching them DevOps, but that's such a broad brushstroke term. And that includes a lot of things. And I'm actually going to quote the infamous Donovan Brown. Now, I think many people, hopefully in your podcast, have heard Donovan a few times.

He came up with the definition of DevOps. And that's where we start. No matter if you're a developer, you're an ops person, you're security, you're PM, whatever you do, we define DevOps as a union of people, process, and products to enable continuous delivery of value to your end users. And yes, there's people, there's processes and products, but value is the key phrase here. And the reason why we focus on value, because it doesn't matter what you're shipping,

whether it's code or infrastructure, what's the value and how can you improve that value? And I like to talk, when I talk to the operational side and I'm like, well, what are we trying to do? We're trying to deliver value. How do we do that? We're trying to be more efficient and be more effective at our jobs. And I think that's the key bit. Having been in the ops space, I mean, and even still today, I work with organizations and I go and see customers. They're like, but these are my pets. I feed and I water them and I grow them and I nurture them. Yet when we start talking about the cloud and automation, our pets become cattle. So we let go of the pet mentality to say, how do we automate this? How do we do it better?

And how do we be more proactive? So it's taking a different approach and then starting there and going, what can we automate? What can we make better? And finding that thing that really hurts the most in the organization. And it could be automation. It could be observability. It could be just the tooling. So I think in the ops space, we do see more people going, yeah, I have some scripts. And I'm like, okay, where do you keep those scripts?

And they're like, on my computer. So then we start talking about these developer practices and and it's a hard scary place it really is for for a lot of people hey in your um keynote i know i've seen the the video now several times used by different people i'm not sure who was it used it the first time but the the comparison i think it was the uh maybe indianapolis an old car race um from i don't know how many years past and then comparing like a pit stop from back then to a pit stop now in formula one and how like i don't know maybe a minute of changing all the four tires you know kind of now converts into i think three four seconds and obviously i think the the message

there is we have eight different tools now, and we build tools to automate certain things. I think another big thing that, and maybe this comes to culture, is always practice, practice, practice, because I'm pretty sure these men and women that are now in a Formula One pit stop, they are not just doing this once a week on a Sunday

when the race is on, but they're doing this constantly, practice, practice, practice um and the reason why i bring this up because brian and i we had talks in the past about chaos engineering and kind of practicing what what do we do when things go wrong which is obviously things when ops people are asked the most to bring the system back to a regular state um is this something that you also try to teach, like the practicing, the using new tools? And then especially the practicing, I think, is a big point. Because the more you practice, the better you get at certain things, right? Absolutely.

And I think we think back to when we date ourselves a little bit. When we used to deploy an application, we went physically to a data center. And it might be you, yourself, and your shadow in that data center. Now we have these mass teams getting involved in application deployment and that involves the production team, you know, the production infrastructure. So we need to know what's going to happen before it happens. And that's also the other message, like, yes, we need to practice, but we need to know what change are we going to make before we push that big red button and making smaller, more traceable changes. And that's really critical. And it's, you know, our brains are muscles and our bodies are muscles. And exactly like the

Formula One race car scenario, you're right. People are practicing a small minute task repeatedly. That's it. And for anyone that's mastered any skill in their life whether it is learning german doing triathlons or just even handwriting i mean i have some friends that write some amazing calligraphy or anyone that does art you constantly do this small almost muscle memory to teach your body how to do something and our brains are the same way when it comes to infrastructures code and automation and devops and and what we're doing and how we're delivering that. That's exactly it. Those small changes to get better and better and better. So if you think of it as learning a task, absolutely.

Yeah, to fine tune a skill takes immense practice and time and it doesn't happen overnight. And people do get frustrated. I was actually on Reddit the other day in a post where someone was like, oh, I work in infrastructure. I'm being asked to learn DevOps. But I'm asked all these tasks and it's overwhelming. And I said, well, hold on, slow down. You know PowerShell. Focus on that. Automate something small and find the fun in it as well. This is the other thing I say to people is find something fun. When we're children, we learn by playing. As an adult, we should be learning by playing. And not everything we do is fun at work. And I'm very aware of that. But pick something

that really interests you and inspires you and go, yeah, you know what? Actually, I want to automate this thing with PowerShell. I want to do this bit of code or I want to fix this problem. Really interest me. And take that small thing and make those small changes. And that's one small change. And then you keep doing it on bigger projects and it gets better and better and better. And hopefully as a human, you get better at these things. Andy, that goes back way back to a few years ago, or probably several years at this point. I think it was Wilson Marr put out the idea of future of performance testing and engineering and

skills to learn and automation was one. And similar to what you were saying, April out the idea of future of performance testing and engineering and skills to learn and automation was one. And similar to what you were saying, April, the idea was he didn't say fun because maybe there's nothing fun going on in his life. I don't know. But his idea was take something you do every day, something simple, though, and use that as a thing to automate. And I got to say for me as well, from a learning point of view, if someone tells me go learn X, I'm not going to be able to learn it. I need a project to do with, I need a purpose to do with. So if it's something in your daily life, hopefully something fun. Uh, I think that that's fantastic advice, um, for that. Cause yeah, fun, fun's the name of the game. Absolutely. I mean, I have automated a lot of things in my house.

And I have home assistant running. I have lights, my heating, I have air conditioning running in my office right now. It's all automated. I'm thinking of Peewee's Big Adventure. I'm thinking of Peewee's Big Adventure. It's not that crazy. Nothing, nothing. Okay. My heat will be really cool to have like a slide that rolls out like the top of my house and goes back into my office, like out of the second story of my house and just out the back window down in my office would be a lot of fun, but maybe next week. Yeah. I mean, I did home automation as one of my side projects and I, I had to learn Python.

And for me that that is not fun, but I actually got to use yaml and a lot of stuff and i use yaml every day and work with pipelines but then i got to do it at home for fun and that helped and then finding other ways to do things with code or languages i wanted to learn and just say you know what actually can i do this in golang can i do this with powershell whatever um yeah you have to make it fun and and sometimes it's hard because we get brought down a lot at work. And that's kind of the other part of the DevOps thing is the culture change. So we talk about tooling, we talk about process that you're implementing. 80% of DevOps change is all culture. It's giving your teams, your engineers, your people, the safe place to learn and to be able to say, I don't know, I screwed up. Like we need to enable

what we call the growth mindset at Microsoft. And when I was in engineering prior to joining as an advocate, I would constantly say, I don't know this. Can I have help? Can I have a rubber duck? Can I have someone to help me through this? You know, to sit with someone or to say, yeah, I don't know this, but I'll figure it out. And I enjoyed that learning and that experience on something that may have been completely out of my skill set. But having that safe space to learn and grow, I have actually locked down four hours a week of learning time. I really try to honor it. Short weeks where we have like bank holidays, long weekends, I personally struggle. So I might do two hours instead of four hours. Last week was a three-day

working week for us here in the UK. So I really struggled on that time because I want to get other stuff delivered. But I have locked down four hours a week of learning time for myself. And it can be anything. It can be any project i want uh this week i'm just literally going through learning modules on microsoft learn which are free learning modules gives you a sandbox to play in and learn and i'm just going to try something new and just say screw it like i don't know is it related to my job no but i'll learn something and that's all that matters and maybe i'll write a blog about it yeah Yeah. Hey, I want to ask something on this because I had a conversation also on social media

the other day, and we were talking about SLIs and SLOs. And then the comment that the other party made was saying, well, you shouldn't start with SLOs because this is all about culture first and you need to make a cultural transformation and that's it. And there was nothing else more. And I wanted to kind of say, well, don't just play the culture card without saying what this actually means, because if you're just saying as culture, then we all say, yeah,

we need to change, make the cultural change. Sure. But what does it really mean? I think you actually now brought a great example. Culture changes that an organization actually dedicates, in your case, 10% of your time during the week for active learning. That's great. Can you give us some other examples that you've seen? Because we all talk about culture, right?

But what else besides giving people time to learn is there that is in organizations that are going through this transformation? So I think at Microsoft, we had some specific things that we did as an organization. And I'll start this off by saying, people remember the Microsoft days of old and your Exchange server broke, Windows server broke, something broke in the software. You called support in another country,

you spent hours on the phone and they helped you get through that dramatic trauma of everything breaking. And it was like three in the morning. Today, we had to change our culture as a company of how we approached our customers. So one thing, so the adopting the growth mindset was a huge one. The other thing we did is creating an obsession around our customers. And it's a culture of customer obsession. So how do we do that? First of all, we do things like visibility.

So if either of you play Xbox, please tell me you play Xbox. I'm sorry. Okay. Someone listening has to play Xbox. But if you're using Microsoft Teams, that's fine. Well, I can't answer for the competition, but Xbox, Microsoft Teams, Azure, every service at Microsoft has a dashboard and it gives you a live service update.

You can see if you have a service update anywhere in the world. So if you're deploying to Azure and let's say you're deploying to a region of like West Europe or North Europe, and there's an outage, you'll see it in the dashboard. So we got closer to our customers by giving them visibility when there's an outage,

because we're all going to have outages. So yes, we're having an outage. Yes, we're fixing it. Severe, moderate, low, et cetera. The other thing we've done is we take direct feedback. So there's feedback.azure.com, where you can literally go and get feedback. The other thing we do is we make our products open source and visible. So for instance, PowerShell was made open source. How did that change the product? You can go into GitHub,

see the issues that people have opened, requests basically of features they want to see or things that don't work well. And the product team sees that. So how did that actually change our culture? It means that the product group sees it. The engineers that deploy those features see your feedback. They see your questions as a consumer.

So we also had to eat our own dog food. We had to start using our own products, and we do. So we have empathy for everyone out there when something doesn't work or a feature isn't there as well. So we brought our customers closer to our engineering teams. Our engineering teams have more empathy. And when a request goes in on like GitHub, et cetera, or an issues gets opened up, let's say that one person opens up an issue

and the product group will see it. But if like a thousand people or a hundred people respond to that same issue, that demand gen is there. So they push that feature higher up into their deployment cycles of what they're going to deploy out for their products. And that gets put into the roadmaps. So there's that active feedback of, hey, I submitted a feature. Like, thousands of other people want the same feature. And now you can see it in the roadmap, and you can see when it's going to get deployed.

So we have changed how we interface with our customers. The other thing we had to do is change how we align our objectives in our team. So everyone needs to have a shared objective. So when we talked about the culture thing earlier, let's talk about ops people and dev people. Very often we have different objectives in our teams uh we're very siloed we work very independently we are measured independently so as an ops person i need to keep the lights on 24 by 7 um as a as a developer i'm asked to push new features if i'm asked to keep the lights on 24 by 7 and then my counterpart is asked to push new features and that breaks my operational stuff, I'm going to go off the handle and say no.

And that's what a lot of teams get. And they have this friction all the time. So we need to deliver that value together and have that same shared objective in our team. So that means changing our objectives and key results as teams, our KPIs, and how we measure them. It also means that we're all trying to achieve the same thing and it's that value.

So that's the journey that we've gone on at Microsoft to make those changes. And that's a lot of what I speak to other customers about is saying, you know, okay, we need to get the development team, the operational team, the security team, the PMs, everyone on the same team together to deliver those. Cool. Thank you so much because I really wanted to, you know,

I wanted to respond to that conversation earlier and I said, you know, don't just play the culture card, but just saying when the culture changed without giving me actually more details. And I think this is just a phenomenal list of things that, and I just took notes on this. Edeon Talk dog food is obviously really great i do want to suggest though taking our cue from us we've changed from eating our

own dog food to drinking our own champagne that's true i like that yeah yeah yeah yeah drink your own champagne i like it all right i'm gonna use that now in two weeks when i give my next keynote um yeah i think it's been such a term for such a long time. Yeah, credit goes, I believe so, at least the first time I heard it, it goes to Dietmar Strasser. At least he's the one internally who I heard it first.

But maybe I'm wrong. Maybe he got it from somewhere else. But yeah, definitely better than dog food. I like that a lot. Yeah, I think that's an old developer term that's really stuck around for some time um we use it in so many various different ways it's crazy and i think there's also a lot of times i'll speak to executives or vps of customers and they're like yeah this devops thing sounds cool and when you come down to it there's a financial benefit for them that they want to change and And it is that culture change from the

top of the organization. And when you say, right, if 80%, I think it's 80 or 85% of bugs are done in the development phase. If we catch them in that development phase, there's a lower cost to fix that versus production or the other stages of our environments. And I have charts and graphs and numbers and figures. So when I talk to executives, those are the things I bring out because the bottom line is they want to make profit. Yes. They want to deliver that value. They want faster time to market. They want to beat their competitors. And we're like, right, well, we can do this. And we use things earlier on in the process. And that's why we say shift left, et cetera. So there's different tactical approaches when you're talking to different types of people, but overall at Microsoft, yes, we had

to do things early. And I speak a lot about everything we do is production ready. So we don't develop test code and dev code. It is all production ready, meaning it's a production first mindset. So as a operational person, I'm like, yeah, I'm just going to deploy this thing to make this change. We don't think about the impact. Did you test that change? Is this a big change or a little change? Like how are we putting safety measures in place to make sure this is like production ready versus, you know, as we used to say in the military, pray and spray. And you don't want to do that in operations because you don't want to take everything down. So I think having that production first mindset, we also put things on earlier in the process.

So we're not thinking about things as an afterthought. It means that your production teams and your development teams are thinking, right, if this is going to go production now, it's not ready for production, but what do we need to put in there? Security. Because every single project I've been on,

the security person taps you on the shoulder and goes, this won't work and here's why. Every time. So to avoid those those arguments we bring them in early um try to avoid the incidences that will arise and you know being being ready to to go production first instead of dev or test and a quick question then because we started the conversation where you said you're primarily talking with uh with ops and um you just mentioned shift left how how far shift left do ops need to go and where is kind of the overlap or where where do they become kind of i guess mentors or how how early do they get involved in the development cycle from your perspective and what you see yeah we they need to be in there in the planning phase. So everyone should be in there

together at the planning and design phase. That is as far left as you can go. So if you think of DevOps as a cycle, right? And we talk about as a process, you have the planning phase, which is the first part of your phase. Then you go into development, then delivery, and then operational. That operational phase gives us the feedback to then go into the next planning phase. So the ops team should be there in the beginning of the planning phase every time. So in the plan and design, they should be there at day one before anything else gets done. Everyone should be included in planning, not just ops. It should be security, PMs. At Microsoft, when I was in the engineering side, I didn't have a title about what I did. I was a senior software engineer. That doesn't tell you about what tech stack I touched. I was just a senior software engineer. We combined our teams and people had

roles, not jobs, and everyone was involved from day one. So every time we kicked off a customer project, everyone was involved in the planning phase. And trust me, it's long, tedious projects, but it meant everyone's involved from day one. We know what's going on. We can discuss the priorities. So everyone absolutely needs to be on there. Got another one for you. Terminology. So when I explain DevOps and how it is different or overlapping or kind of working with SRE, site reliability engineering,

the way I always explain it, and now people now cannot see my hands, but I will show it to you. So I always say I see DevOps engineers from the left, meaning from development, using automation to get changes faster into production. And on the other side, I see SRE side reliability engineering using automation to keep the systems reliable and healthy in production. And for me, it's like DevOps and SRE in the end

are handshaking, right? And I think there's a nice meme that I always use where you have DevOps and SRE holding hand, but DevOps kind of, again, automation to push stuff faster from dev to ops and then SRE to use automation to keep things safe. Do you have a differentiation between DevOps and SRE, especially as you talk with ops or is SRE just another, I don't know, role or what is SRE for you or does it not exist in your world?

I think SRE has been one that's for debate. You know, this is like the tabs versus spaces argument. SRE should be involved in the DevOps process without question. Some people feel like they shouldn't and it's a whole separate role. And I think really, I feel like DevOps and SRE in the same boat. We're all rowing in the same direction. We all want the same things. And this can be coming down to when you have a, quote, DevOps specialist in an organization or an SRE specialist. The SRE specialist usually just gets thrown the observability, the monitoring, and those things. And I'm like, well, hold on. The rest of the team should be responsible for that as well.

And there was someone on Twitter recently, a former Microsofty that is currently at a competitor. And she's like, they keep telling us to get the developers to care about operations and they don't, but we need to have that empathy. And that's a hard argument to have. It's a hard discussion, but I've been on so many projects

where I'm touching infrastructure, I'm touching code, and I have to be empathetic to what's going on. And that's actually how we kind of put together our engineer. Again, I told you I was a senior software engineer. We were more vertical engineers. I'm not a data person. I had to learn about data. I had to have empathy for data, which killed my soul, the way some developers feel about having to care about operations and monitoring, et cetera. But I did it and I had greater empathy for what the data side of the project was doing and how my code and my infrastructure changes affected the data. So I didn't have to be an expert. I just had to have the empathy and know what I was doing, how it affected things. So I'm more of a vertical engineer. And that's what we strive for at Microsoft.

And there is no end point to that. And I think that's the hard part, right? There's no like, yeah, I've reached my pinnacle. This is it. I have my definition of done. It's I'm going to be continuously learning about all these things that touch my project. So I think the SRE thing is,

and DevOps are in the same boat. It's just tough because they tend to get segmented out, but SRE just gets thrown the observability and the monitoring when, in fact, they need to be involved in those other things as well. And it's hard to monitor what you don't know about in the beginning as well. I don't know if I'm naive or it's because of my upbringing in the world of performance where there was no differentiation between dev and ops. When you think about performance, it's all the same,

but is there a strong pushback against the cultural idea of caring about the only priority being ensuring an excellent customer or end user experience and everything serves to that which then gets rid of all those silos you're talking about which is part of the concept of devops and if you think about how sre fits into that if sre is doing the monitoring that all starts in the beginning what has to be monitored what has to be accounted for um it it sounds too easy of an answer and maybe it's a little too optimistic or I can't think of the word I'm looking for, but is it a problem with that or is it more of just people accepting that change and accepting that challenge of, you know, it's too much for me to care about

everything or to even just collaborate and take feedback from everyone? There is always pushback. People don't like change. Humans don't like change. Humans like being comfortable. I'm one of those weird humans that hates being comfortable in my life, personally, professionally. And so that's good. But I think for most people, and again,

you think you've been in role for 10 plus years, or you've been at a company for a while, and they say, hey, we're going to do this DevOps thing. And you're like, hold on a minute. I got to learn new things. I got to change. And it doesn't matter what the end goal is. They hear change and that's the hard part. So it's, it's really making sure that everyone is on board. And I'll be honest. We probably lost over 20% of our workforce when we started implementing DevOps at Microsoft. And we do have a bit of a change in our engineering teams every year. We have feature teams and they move on. But it's hard. It's hard to accept that change is coming. People want to

do better. They think it's better. But then we also just get comfortable and then think of all the work that has to go into it. And then also, I'm so busy. I'm so busy fighting fires. How do you bring in the time to make these changes? And that's a lot of the kickback we get is either A, I don't want to change or B, I don't have time. And when I was in engineering, I call it death by fire because it was. Every customer project, we start off, everyone was involved in the planning phases, but we start off in one week sprints. So we had everyone, developers, ops, security, PMs in the team. We did one week sprints.

And if anyone here has ever worked in a one week sprint, it is, it is hell. It like, I have actually cried into my cornflakes in the morning because you wake up and you're like, I don't want to go to work today because this is going to suck. Because I've got one, but you have to pick off, but it teaches you bite-sized chunks of what you're going to achieve in that week. So it sucks. But then we moved to two-week sprints when everyone's happy and everyone started

to get the flow of this DevOps-y thing. So it is a little bit of death by fire, but that's how we kicked off our projects. It was literally lighting a fire under everyone and saying, we're going to do this thing. Here's the process. And, and help them understand that. And it's hard, but it's same thing. You know, every organization within Microsoft, every team has to find their own, what we call the Goldilocks principle, their perfect sprint cycle. And that means doing really short sprints, really long sprints, and then finding that niche that works for them. So, yeah. So, I think in a really long roundabout way,

people, yes, fight it all the time. They don't like the change and it means doing things differently. And that's hard. It isn't easy. DevOps isn't easy. And I will flat out say that, and you will probably cry or you'll want to quit your job or give up on your your career path and go why did i not just become an accountant or something simple right um i wouldn't say accountant is simple but yeah i i don't know i just i don't know i picked i picked a career like doctor seems like there's a lot of school involved and um yeah or you know like a teacher right like i'm gonna go teach preschool or kindergartners and we're going to play with Play-Doh and colored blocks. Sounds simpler than doing DevOps.

But I think, you know, we all got into tech for a reason, right? For me, it's the passion for technology, the passion for learning. And I do have to sometimes remember that when I'm in the deep, dark throes of my one week sprint cycle of doom. I love that. One week sprint cycle of doom. I love that one week sprint cycle of doom. Yeah. But it's, you know what I think everyone comes out the other side so much better. It helps you grow as a human and that's, that's great, but it is, yeah, it's hard. It's hard. Quick question. First of all, thank you so much for sharing all of these i mean i took so many

notes especially on the cultural changes i said earlier and then also how you kind of transformed at microsoft now i know you are you know an advocate for microsoft and what you're providing to your customers you know through the azure cloud services um talking a little bit about this because i know we have a lot of listeners that I'm sure are either on your platform already, or maybe thinking about it. What gets you excited? It shouldn't be a commercial now, but still I want to make sure that we also understand what gets you excited

about this stuff that you as Microsoft are bringing to people that are moving to the Azure cloud. And obviously with the focus of what you're doing, preaching DevOps automation. Yeah. So for me personally, it's the ease of doing things. And that's how I got into the cloud in 2013, into Azure. I actually had my first touch into the cloud with what was then Office 365,

which is now Microsoft 365. I'm sorry, we rebrand everything every few years. Totally not my department, but, you know, Office in the cloud, right? Exchange in the cloud. We rebrand everything every few years. Totally not my department, but you know, office in the cloud, right? Exchange in the cloud. We went to migrate. I was at a very large company and I was scared out of my mind. I thought I'm out of the job. And I honestly get where many other people in this space had that same panic. We ended up migrating to office 365. And I was like, Oh, I like this exchange doesn't break every night. I'm not getting calls at 3 a.m. for my COO because I did. Because who the hell works at 3 a.m.? My old COO. He did. And he would call me, text me, and email me. Well, if email was down, he'd call me incessantly.

So that stopped that behavior, thank God. And I could sleep at night and things were better. And then I was working for a managed service provider and I had a customer that had a couple sites and they were looking to shut down a site and migrate some kid and one of their data centers. And I said, what about Azure? And they're like, well, have you done anything in Azure? I'm like, no, but how hard can it be? And then I actually just got hooked. The ease of spinning up a VM, the ease of the failover and the redundancy and the resiliency built into the cloud. And I started doing a lot of data center migrations after that. So for me, it was the

ease of doing stuff. And then when I learned about this whole infrastructure as code thing, and back in my day, we didn't have Bicep. We didn't have Terraform. We had ARM templates, which again, if anyone's ever heard me speak about infrastructure as code is also my hell. ARM templates are ugly and they're nasty and they're gross. So I got into Terraform because I needed something better than ARM. And now Bicep, another great product we're doing. So for me, it was understanding the ease and the ability to scale and not getting those calls. It's someone else's hardware. And you then manage the stack in a very different way. And I used to have a great photo and I probably have it, but I equate it to ordering a pizza.

So when you have your own data centers, it's like going and making the ingredients for your pizza. You got to do everything. Then when you have Azure, it's like ordering a takeaway pizza from like Domino's or Papa John's. The pizza just gets delivered to your door and you have a lot less to do.

And I have, there's like a whole picture that gives like the scale of different types of like, you know, you get Papa Murphy's takeaway pizza from like Domino's or Papa John's. The pizza just gets delivered to your door and you have a lot less to do. And I have, there's like a whole picture that gives like the scale of different types of like, you know, you get Papa Murphy's takeaway pizza where you just take and bake. And anyways, with Azure, you have the ability to go, we use the phrase serverless, you know, and microservices. And there's a lot more you can do with your infrastructure. And there's a lot better ways we can deliver better services and value to our end users. So for me, a lot of what we're doing in automation and ease of getting started.

So for instance, GitHub, we have GitHub Codespaces, which lets you just spin up a coding environment and it's secure and it doesn't take days on end. So I think a lot of the inherent security and products we're deploying to the cloud and making, we use the word developer,

but everyone's life easier to use the cloud is what excites me. A lot of AI is built into our tooling now. So helping you write better code, better PowerShell, better C-sharp or whatever language floats your boat. We're building a lot of tools in that, which I think is pretty cool. So it helps us be

better people and be more proactive everyone can use the cloud easily like exactly yeah but it's a daunting place it's a daunting place but we've just put out some really good um and this is not a promo for microsoft but i guess it is um i was we've put out some really good documentation of like a matrix of where to get started, how to get started. Cause that's always people's biggest question. But I'll say to you, like find something that interests you and just go do it. Like go deploy it in Azure, then automate it and take it the next step further and further and, and go down the fun rabbit hole of doing cool things.

I got one last question. It might be tricky and you don't have to answer it because I don't know if this, I mean... It's an accounting question. It's an accounting question. Uh-oh, I'm out. I'm tapping out. Nah. You mentioned GitHub, obviously, rather than Microsoft acquired GitHub a while ago.

What does this mean for the future of Azure DevOps? You know, I get this question like every day of my life. And I do hope that, you you know the message gets out there i think there's some mixed messaging unfortunately so azure devops is our product that is massively mature it's a hugely mature product a lot of people have invested a good amount of money and time into their organizations with it it does a lot of amazing things github does not so they've been spending a lot of time and effort bringing up feature parity in GitHub. There are two separate entities. They will stay two separate entities for the foreseeable future.

I mean, we still have teams. Internally at Microsoft, we use Azure DevOps every single day. The Windows team, the Xbox team. I did some episodes on the DevOps lab with the Xbox team recently. Azure DevOps is here to stay. Now we all work in tech. We all know that sometimes products disappear and go away, but it's not going away in the foreseeable future. There's been so much investment in GitHub to bring up that feature parity, but it's not going to be the same product. So if any of you out there using GitHub, data residency is still an issue,

meaning if you need your data to sit in a certain place in the world, i.e. the UK or Europe, you're not going to get that with GitHub yet. It is coming, but it's not coming yet. There's a lot of features in Azure DevOps you just can't do in GitHub. Now, Azure Boards, super mature. GitHub Projects, awesome, but not near the technology stack. So we do see the GitHub stuff come out. There's a lot of talk about it. It's kind of the new kid on the block, if you can think of it that way. It's shiny and it's new.

But yeah, Azure DevOps is here to stay. And on a personal note, a good portion of the engineering team has been in the Eastern part of Europe. So they have unfortunately been hit with the war in Ukraine. But there are plans to release some features coming down the pipeline soon.

So it's been a tough situation, but I know there's stuff coming out. And I've spoken to the product teams recently about really making sure we get that message out there more readily. We see so much GitHub stuff, but not enough about ADO. But our customers want to hear it.

So that's been my feedback to the product team recently. That's why I also asked, because I hear it a lot as well. And now I know how to answer it. So that's been my feedback to the product team recently. That's why I also asked because I hear it a lot as well. And now I know how to answer it. It's here to stay. It is here to stay. It's just you're seeing the new cool kid on the block. And there's a massive investment from GitHub. But ADO is so mature.

It still has some bugs, but it's super mature. It's funny, Andy, that when you mentioned GitHub, I forgot that Microsoft bought it, which is going back to our conversations with Donovan way back, is such a testament to where the entire Microsoft organization has gone. Because in the old days, it would have been plastered with Microsoft and pretty much destroyed. And the fact that the way they handled Azure, the way they handled everything else, it's, as he said way back then, it's not your father's Microsoft.

So it's just funny how every time these things come up, I forget, oh, that's right, that's Microsoft under there. And Microsoft, and I don't remember the figure, there's some stat out there, and I'm sure it's changed, but we are the largest contributor to open source projects. We're heavily involved in the CNCF. And when people are like, oh, open source Azure, really? I'm like, yes, absolutely. And it's getting that message out.

And yeah, this is the Microsoft days of new where we're out there to do good in the world as best we can. I don't know why they were trying to buy TikTok forever ago, but I'm happy that didn't go through. That was a weird one. Everyone's like, why are we buying TikTok? I actually know why we were trying to buy TikTok now. I hate to say this, but it's where the younger people are learning their code and learning their tech, short, small videos. And I'm actually working with certain teams to get those videos out and it's not my thing, but yeah, I mean, we're trying to make tech more available to people globally. You do little dances as you code. Oh, don't, don't. No, no, I don't dance. No, no, sir. Yeah, it's having to tell.

I was working with Jason Helmick, who is one of the product managers on the PowerShell team. And I said, Jason, you really need to get on TikTok because it's where old cool kids are. And he, I like, I just, I just sunk into my hoodie and I'm like, here I am telling a seasoned person at Microsoft, you need to get on TikTok. And I'm like hiding in my hoodie going, I've just ended my career. Like there's the nail in my coffin. And he goes, okay. And he swallowed it really well. And the next time we had a call, he's like, I've got a burn phone for TikTok. And I'm like, okay. So you're embracing this change.

Again, growth mindset is everywhere at Microsoft, right? So, yeah. So it's crazy. But, yeah, we do so much open source investment. And I'll put a plug in. Microsoft Build just happened. And one of my favorite humans, Abel Wang, passed away, unfortunately, last year from cancer. And we're raising money for

Girls Who Code. And Microsoft is matching our donations 100%. So every dollar or pound you donate, Microsoft donates a dollar or a pound. And I have several Microsoft executives donating $10,000 each. So that's $20,000 for Girls Who Code from each person. And then hopefully get my donations in and raise $20,000 as well. We also had him on the podcast as well. And maybe that's also a good kind of closing statement, or kind of at least from my side, if there's any things like this, right, where people can donate or any other resources,

please let us know, April, because we will include it in the summary of the podcast. Show links and everything like this. This would be great. Absolutely. I'll put the link in the show notes for everyone. It actually was a little bit difficult. We were unable to do any social media promotion when there's been a massive media issue in the world or a political

issue, if you will. So we didn't really get to promote a lot during Build, which sucked because there were a few political issues happening in the world. And again, there's more important things in the world than coding and work. We're not just a tech company. But yeah, I's more important things out in the world, you know, than coding and work. You know, we're not just a tech company. But yeah, I will get the link out there and everyone can donate. That'd be amazing. We're trying to hit 10,000 British pounds and Microsoft UK will match that with 10,000 British pounds. So that's about $25,000, $26,000, depending on the exchange rate. So, yeah.

Awesome. Awesome. Awesome. All right. Any closing thoughts, Andy? I just want to say thank you because I have to go back to what I said earlier. The whole cultural thing was just a discussion that I had recently.

And I think you gave me a great list of ideas on what cultural change really looks like instead of just saying cultural change is necessary before you do anything else. But now I know how you do it. And I would really love to have you back at some point. And the next time

when you come to Austria and into my region, maybe you ever make it towards Linz where we have our headquarter. I'm here in Klagenfurt right now where I know you've been doing the Ironman.

We have an office here as well. And it's like literally 500 meters from the lake where we are so beautiful area it is austria is probably one of my favorite countries because of the mountains and the color of the water is absolutely stunning and when i did ironman klagenfurt and i'm totally off topic from tech for a minute um the the course does like almost like a figure eight and at each town where like there's you get to the top of a climb and there'd be the village there everyone from the village was out and i remember cycling up this hill and there's just people cheering and you can't be unhappy and this little girl like had her hand out and i'm just like i hope i'm inspiring the next generation she was so excited to see a girl powering up that hill. But Klagenfurt was amazing.

The swim was warm, a little too warm for me to wear my wetsuit. So it wasn't as fast as I wanted to be. The water was amazing. Austria is amazing. It is one of the most beautiful countries. Like Switzerland's beautiful and I love Germany, but Austria is just like, it's mind blowing for me.

I love going back. So I'll be there once in July this year and once in August. Nice. Yeah. Thanks for the, I think we'll forward this to the Austrian Tourism Agency. Nice testimonial. Yeah. I'll take a kickback now.

No, thank you both for having me on. It was great to be here today. We diverted to culture a little bit, but I think it's such a hard topic, but such an important one. Again, like I said, it's probably 80% of that DevOps change in your companies. Yeah, and I look forward to you coming back as well

because I want to dive into something you said right in the beginning when you mentioned the quote by Donovan Brown. You called him the infamous Donovan Brown, and I think it'd be good to dive into why you chose the word infamous. All right. We can do that. We can do that. No, we don't really need to do that. I was just like, oh, infamous. All right. Anyhow, really thank you for being on today and thank you for our listeners. And to all of our listeners, again, there'll be the link on both the Spreaker and Dynatrace page for the donations for Girls Who Code. Is that who it is for? Girls Who Code.

And it is in memory of Abel Wang because he was a massive guy in build every year. But I think more importantly, just encouraging the next generation. Yes, exactly. So thanks, everyone, for listening. And we will see, we'll hear you, or we won't do anything. You'll hear us next time, I guess. All right. Thank you, everyone.

Thank you. Bye-bye.