Brendan Burns is famous in engineering circles as one of the co-founders of Kubernetes, but he's more than just a developer - he leads a team of 650 engineers at Microsoft.
In the first episode of a two-part series, Brendan joins the Dev Interrupted podcast to talk all things engineering leadership and management. After joining Microsoft and being given a team of 30 people, he has seen his teams double each year. Adopting a leadership style that he jokingly refers to as "my form of punishment is micromanagement," Brendan discusses how to be intentional about employee interactions in a remote world, the importance of delivering a concise message and why saying "yes" to as many opportunities as possible has led to career success.
Episode Highlights Include:
- Learning to program on a Commodore 64
- Saying "yes" to as many opportunities as possible
- The "meet them where they are" philosophy of employee interaction
- How to run distributed engineering teams
- Being intentional about meeting employees in a remote world
- Why missing deadlines creates opportunity
Episode Recap and Transcription
Dan Lines
Hey, everyone, welcome to dev interrupted. I'm your host, Dan Lines and today I'm joined by Brendan Burns, Microsoft Corporate Vice President and co founder of Kubernetes. Brendan, thanks so much for joining us. Absolutely pumped to have you here. I've heard you say that your first coding was in basic on a Commodore 64. What was your pathway to becoming a developer? How'd that happen?
Brendan Burns
The Commodore 64, I don't think that was the first computer that I used. But it's definitely the first computer program, I think I'd use a friend's Apple two, I didn't know my family didn't have computers.
Dan Lines
You had to go to the lab, your friend's house.
Brendan Burns
Yeah, to go to a friend's house. One friend had the Nintendo and one friend had the Apple II, it was like 1983. But the Commodore was actually my bake sale computer. So my third grade I had a big sale. And like what they did at the end makes that was they used the money, they bought a competency and they put it in the back of the class. And I think I think they just didn't know. But back in those days, both the Apple II and the Commodore they just booted into basic like you could just like at the command line, just type in instructions and go at it that way. And I'm looking for commands, poke was one of them, they just push the value into memory. And there was byte magazine too, that was more free. And otherwise, they'd have programs just like following along at home. I don't mean I really thought of it as a career or anything like that. But I didn't know anybody. I think it's something to think about. I don't know, anybody who's a software developer. My dad was a lawyer and people were teachers and worked at Boeing. And I don't think I knew a single software engineer until I got to high school.
Dan Lines
Yeah, that was gonna be my next question. Did you have a group of buddies that were coding together? How did you take a leap there, no mentors or anything like that?
Brendan Burns
I had a babysitter who was into computers. She had some books and she just happened to be into, like, an incredible collection of sci fi novels. And I think by virtue of that, I knew about computers. I mean, it was a very different time. When I got into middle school, there was a computer lab, and I hung out the computer lab a lot, mostly to play video games like dark castle, which is still like the world's greatest video game. There was a Mac lab, it was all old Macs. But then we learned how to like, there's this program on Mac called rez edit, which is like this resource editor, which let you go in and change all the strings in the programs and change images and icons and stuff like that. And so we started like hacking around that way. We weren't really coding, but we were hacking. And then there was a little crew of us middle school dorks, and I did try and learn how to program back then I wasn't super successful at it. Now, you know, partially, I think, because it was all from books and like, the internet really wasn't a thing and you couldn't just grab tutorials. At Christmas one year, my only present was C plus. Because it was like $400 - a lot of money. And I had to get this one, this is what I want. Then in high school, I moved away from it a little bit because it turns out I'm pretty good distance runner. I did cross country and track. So I spent most of my spare time running and stuff like that. Homework in high school wraps up a little bit too.
Dan Lines
So no programming? Just running and some homework?
Brendan Burns
Yeah, not a lot of programming. I mean, I still we still used computers, sent emails and stuff like that. My mom worked for the University of Washington, she had email and I had email at my high school. So we use that as a way of communicating. It wasn't much. Then when I went to college, I got the course catalog, the book, which shows you how old I am, no online course catalog, and I flipped through it. It turned out that the things that I was most interested in were art and computer science. And that sort of was what I did in college. And so I left there and then by that point it's 1998. And suddenly, across my four years of being at college when I started freshman year, and someone's like, hey, there's this mosaic web browsery thing, and here's HTML to like, the software industry exploded in 1998. So it was an interesting time to be learning and on the front of that wave.
Dan Lines
That's a super interesting time. Thank you for telling us your origin story. I always like starting there, I'm going to move us, you know, on to where you're at now. And some of the things about your current engineering organization, most of our audience are engineering leaders or people who are trying to advance their career in one way or another. So I'd love to hear about how you're managing and leading your current organization. I guess your teams are doing a bunch of different things, containers, Linux, microservices, you have hybrid teams you're doing - it seems like you're doing a bunch of stuff. What is your team doing? How big is your organization? How are you structured?
Brendan Burns
Sure. Yeah, my work is about 650 people these days. A two pizza team. Keep 'em hungry.
Dan Lines
You're following the rules.
Brendan Burns
They said you should only feed your team with two pizzas. I heard you're supposed to, it's all about Lean engineering. No. And roughly speaking, that's four or five ish, broad themes. Like container, open source, cloud, native containers of Linux, I own most of the like, API gateways, API's to Azure DevOps to Azure stuff. Terraform for Azure client, like the Client Tools for Azure, the web portal for Azure. So a lot about managing your cloud stuff, not actually doing any of it, just the management. And then I actually also SAP like the big like, your HR database, whatever. It's pretty diverse. And actually, just someone said to me, like, what's the theme for your org, and I was like, I can find themes that run across them. Most of the SAP is on Linux. And there's a lot of DevOps, but there's not, I'm not sure there's one thing that like unifies it all, and I have pretty strong senior leads of people who have 100 to 150 people in their org, and they report to me, and they more or less, I hope that they more or less, just do what they need to do. And someone once said to me that I micromanage as punishment. It's pretty accurate, right? I'm pretty hands off, and I try and be pretty hands off. But like, whenever I see problems, I tend to get a little bit more in people's business. That's how they know that they're in trouble. Because you're diving in. So across the five years I've been at Microsoft, I started with about 30 people, and really only one team, like one team 30 people. It's been scaling.
Dan Lines
Wow. So you scaled huge, that's awesome. Was it 30 people and then, hey, you get another one? Here you go. Good job.
Brendan Burns
I started with one team, 30 people, and then relatively quickly, I got an incubations team that was incubating some container stuff that was really small, it was like three people. And so we grew the heck out of that, partially through acquisitions. So we bought a company called Deis, hired a bunch of people, grew that thing a whole bunch, and then through both just organic growth and, reorg for a variety of different reasons, right? Like sometimes because a leader is transitioning to a different thing. And they need to find a home for something that they had previously been responsible for. Sometimes because they just made sense to group these two things together. Sometimes priorities just shifted. And sometimes just because my manager knew that I wouldn't say no. Because I don't really ever say no.
Dan Lines
Is that a thing of yours?
Brendan Burns
I think so. I think, I don't know, it's a psychological problem that I have, or something. Like, if somebody comes to you and says, we really need you to do something. I'm like, absolutely.
Dan Lines
There's a movie on it. "Yes Man."
Brendan Burns
Yeah. I say no a lot to ideas. I'll say, I don't think that's a good idea. Okay. But if somebody comes to me and says, hey, we have this product area, that we need somebody to own.
Dan Lines
If it's an opportunity.
Brendan Burns
If it's an opportunity to take on more responsibilities, more scope, I tend to pretty much say yes.
Dan Lines
For our audience, like, that's a lot of successful engineering leaders, I see that trait. When an opportunity arises, hey, we're having some trouble here. Or we need someone to do this. Or there's a new customer base that wants something, i f you say yes, it opens up opportunities for your career.
Brendan Burns
Yeah, I think that's true. And that's something that's been universally true throughout. Like, Oh, yeah, I've never really done that before. But I can learn about it and I'm sure there's something interesting over there. And it's turned out to be true pretty much all the time.
Dan Lines
Yeah. What time period are we talking about from the 30 to the 650 in terms of your org size?
Brendan Burns
I guess I'd say I've roughly doubled every year COVID kind of slowed it down a little bit. But even there I think I put on about 100 across COVID.
Dan Lines
What does that feel like?
Brendan Burns
I don't do most of the work is the thing.
Dan Lines
Okay, tell us about that.
Brendan Burns
My teams are out hiring. So at some level, what I do is like bulk resource aggregation.
Dan Lines
So you're not micromanaging the hiring?
Brendan Burns
Not micromanaging the hiring, but I am definitely involved in trying to get more resources. Can we get 30 more headcount for that team? Working with the leads to say, okay, where are the gaps? What are we not able to do right now? What could we do if we have more resources? I think there's different interesting inflection points along that scale line. I think that there is there's two, the two most interesting inflection points that I really one was in after a certain point, and I'd say it's roughly 100 people somewhere in that range. There's always someone unhappy. Probability just says.
Dan Lines
Yeah, I mean, we're humans. Humans get unhappy.
Brendan Burns
So it took some getting used to, for me to be like, oh, okay, you're the person who's unhappy this week. Because every Monday would start with someone who was unhappy about something. And it just took some getting used to, to not be like, Oh, my God, I, I'm the most terrible leader ever. My org is so unhappy.
Dan Lines
Yeah, managing people is different than being an individual contributor, and people have all different types of problems and emotions, feelings. Yeah. And it seems like something you had to get used to a little bit like, Oh, this is gonna happen often now.
Brendan Burns
And I think as a manager, you're used to it. But I think as like, at a certain scale, and also a certain level of indirection, because like, I may never have met this person before. Like, they could be two levels down, and they're suddenly coming to you, like, you fix my problem. And I'm like, Yes? I had to get over that, like, urge to immediately jump in and fix it. I think throughout my career, one of the things I've learned as you grow and scale and influence, is the need to damper yourself grows too. You can really yank your org around if you're not careful. If you don't move slowly. It's like the difference between driving a sports car and driving a semi truck.
Dan Lines
Did it happen to you? Do you have an experience where you're like, oh, that was a learning moment there?
Brendan Burns
I've had some, I guess what I would say is, so one of the reorgs I got a team that was pretty unhappy to be real to me, put it that way. Okay. And they were pretty suspicious of and I went into that one. That was my normal approach, which is a little bit casual and a little bit joking and stuff like that. And I and they just completely misinterpreted. My first sort of group meeting with them, they just completely misinterpreted what I was saying. And they didn't tell me to my face. I only heard about it afterwards. And I realized in that one that I couldn't assume that people would feel the same way. Like I had to come in with a crisp message. I had to come in and be like, Okay, this is the message I need to land, I'm going to land it really crisply I'm going to use, I'm going to be totally on message, on onpoint. I'm not going to joke with people because they're just not in a place where that works for them right now. And I think I've learned that lesson. I learned that lesson with individual people. Before I learned that you happen with the style of the person. As a manager, you can't just be yourself all the time, you have to actually change your style to match the person who you're working with.
Dan Lines
Yeah, meet them where they are.
Brendan Burns
Meet them where they are. But what I realize is also true is the same for orgs. You have to meet the org where the org is and that was one way that was a pretty rocky relationship at the beginning. And it got better over time. And then they got reorged to another place. So it was funny. I was only a temporary took care of them for a while
Dan Lines
You got 600 about 650 people. You said maybe six or seven people reporting directly to you something like that?
Brendan Burns
I think it's 10.
Dan Lines
Are these people all over the world? Where is everybody?
Brendan Burns
Mostly North America. Okay, I think it's entirely North America, but not all Redmond. Some California, some Seattle, Austin, North Carolina.
Dan Lines
Spread out but still within North America.
Brendan Burns
Yeah. And my teams are actually spread throughout the world, but those are teams within these bigger teams that report up to me.
Dan Lines
I see. So the leads are all in North America, teams could be anywhere?
Brendan Burns
Yeah. I've got a team in New Zealand, team in Shanghai. Actually a couple teams in Shanghai. We just acquired Kinvolk, which is another startup mostly in Europe, spread all over Europe, pretty distributed. Little bit of the center in Germany but pretty spread out across Europe.
Dan Lines
Are you all are you remote? Or is it just be remote if you want to be?
Brendan Burns
Right now with COVID everybody's remote more or less like a few of the offices are saying that you could optionally come back, if you want to come back. Prior to COVID, I would say that we were pretty Redmond centric. My teams are a little bit less but in general, Microsoft's Redmond centric. I think that along with the rest of the world, we've learned a lot about being remote and we're going back to a labor hybrid environment. There's obviously startups and stuff like, we're gonna get rid of our office and all that stuff. I think Microsoft's doing really great at growing and adapting and saying, look, actually, most people want a lot of flexibility. And let's figure out how we can give them that flexibility.
Dan Lines
Yeah. Same thing that we're doing at my company, the hybrid the optionality.
Brendan Burns
And it's tricky. You have to be super mindful about it. I that's our big challenge right now, I think is figuring out how we're mindful about it so that we don't end up, because I worry a lot about nobody being able to really get to a place where they're happy, because they go back to some default that, that they're like, Oh, my gosh, everything's happening to the office, I'm going to the office.
Dan Lines
Human tendency, it's cool to be remote for a while, then you want be in the office and then you don't want to commute anymore.
Brendan Burns
I think that what's most important, I think, is that we figure out ways that like, people can find the balance that they need. I think that's hard. There's just a ton of people who've realized, like, actually, having a little more flexibility makes a huge difference in my work life balance. I've had people who are like, you know what I really want to go I wanted to go to go fish, and but I fish from 5am to 7am. And so if I can take my RV and park my RV somewhere with decent internet, I can fish from five to eight, and I can hop in my RV and I can work. And why shouldn't they? I think that's great. And so I think that people suddenly realize that Oh, actually work doesn't have to work the way that work used to work.
Dan Lines
Definitely. So you've got to work remote because of COVID, but you also normally have a distributed team. How do you manage all of that? Any learnings or something that you could share about running distributed engineering teams?
Brendan Burns
I think it's absolutely critical that you have good, leads and trust. That's pretty obvious. In any situation like that, you're gonna, you really need to have that sense of trust. But I would also say that one of the things I find is that building up your own connective tissue is also really important. Right? So I do a ton of skip levels. I do about 100, skip levels every quarter. So out of that 600 people I do a half hour one on one with about 100 of them.
Dan Lines
Gotta stay connected to the pulse of what's happening.
Brendan Burns
Yeah, and because I think that, especially in a remote environment, where you're not going to run into people at the elevator, you're not going to run into people in the cafe, you have to produce that opportunity for someone to raise a concern to you that they might not either feel comfortable raising to their manager, or might even be about their manager. And so I think definitely, because there's less serendipity you have to focus on creating opportunities for conversation.
Dan Lines
Yeah, you're intentional about it, because it's not going to happen randomly as much anymore. So you've got to go provide that opportunity. If we got down to an individual team of, I don't know, eight to 12 engineers, is it work the way you want to work? Or is it like, Hey, we're a scrum organization. Or you have to do kanban? Or this is the road you have to follow? How do you balance that kind of stuff?
Brendan Burns
I think it's a mix, right? Because when you exist in a bigger org, it's important that there is centralized dependency tracking, and things like that, right? Because if we're going to depend on something at Azure networking, you know, that's another 1000 people in a different place. And if we all decide like, they're going to use JIRA, and we're going to use some other ticketing, it's just not going to work. And so we have to have the ability in some places, we say, Hey, you know, you're gonna use Azure DevOps. That's just the ticketing system. I'm sure you can love JIRA, and I'm sure you can other stuff, but we're on this thing, right. And and I think that's okay, because like, at some level, they're undifferentiated. I'm sure that the Atlassian people will come and be like, no, but it's, but at the end of the day.
Dan Lines
I'm sure they're like, let's bring out the battle card versus, but no, it's like, I don't know if that's gonna change my life as an engineer. I have other stuff to do.
Brendan Burns
And similarly, for things like monitoring and alerting, there's a bunch of these things that it's actually really important to have centralization for the term. What does it mean to be like, we have different severity levels for an alert, it actually, interestingly, for a while between the some of the bigger orgs in Microsoft, that it was a little different. People would be like, Oh, my God, that's a severity one. And this is a severity zero. And it was actually the same, they meant the same thing with different numbers. But having that kind of level of normalization is really important. But at the same time, I think it's important to give teams the flexibility to find the thing that works for them. So I have teams that work in .net. I have teams that work in go, I have teams that work in rust, and they have different procedures associated with them. I do think it's important to have certain things the same, I have expectations around basic engineering principles.
Dan Lines
Do you post them? Here's our principles.
Brendan Burns
I haven't posted them. I've talked about at all-hands. To be honest, we should do more. And we're trying to do more automation saying like everybody needs to report. I don't care how you measure your code coverage, but everybody needs to report their code coverage.
Dan Lines
Let's leads to another good question: Are there a standard set of metrics? So it sounds like code coverage is one of them? Is there any standard set of metrics that get reported to you?
Brendan Burns
Yeah, there's so many different things, honestly. Some of its things like code coverage, some of its things like are all your certificates auto rotated. It's not just security. It's also like best practices to, right? Are you reducing toil? Are you reducing toil on your engineers? Because it's not just are your certificates rotated? And, and then also, of course, there's stuff like, like, how often your teams get paged? Like, we just went through this, like DRI health review of how often they paged, how quickly dp they respond.
Dan Lines
Like MTT, mean time to restore stuff?
Brendan Burns
That kind of stuff. But also how good are they doing the service, which is important. But there's also like, how disruptive is your service to their lives? Which is equally important. Like, how often are they getting woken up in the middle of the night? So there's a lot of those kinds of metrics that are out there. And then of course, business metrics.
Dan Lines
Are you doing anything with Dora metrics, cycle time, change failure rate, nothing like?
Brendan Burns
We do a little bit, I guess what I would say what we do measure, we measure differently problems that get to multiple regions versus getting to a similar region.
Dan Lines
A reach effect of the issue? And like, when can you catch it?
Brendan Burns
Yeah. How do you ever monitor to catch something, and I will tell you that it's a much bigger deal if it gets to multiple regions, and if it gets caught in a single region, and because from a customer perspective, we make a commitment that, like, if you're in multiple regions, you should be, you should be pretty safe. So if there's a correlated failure in multiple regions that's far worse.
Dan Lines
Yeah. What's your philosophy around actual versus planned? Meaning, are you the type of leader where it's like, hey, it's gonna take as long as it will take as long as it's high quality? That's one extreme, like, another extreme might be like, hey, you said that you were going to this team would finish it at this timeframe, and you're late. So we're like not hitting our metric there.
Brendan Burns
It's got to be both.
Dan Lines
It's always the safest.
Brendan Burns
Yeah, no, but I'm serious about it, too. Like I've done enough engineering to know that, I guess what I would say is, every time you miss a deadline, in my mind, it is an opportunity for that engineering leader to reassess how they figure out deadlines. Right?
Dan Lines
Yeah. Probably a lot of reassessment. We've all missed deadlines.
Brendan Burns
But we shouldn't be getting better. And, we should be getting better. Yeah. Even if it just means Hey, look, I know, like I can tell you for me, my own personal learning was like, every time you think of the number, double it. Okay. That was just, I learned probability was like, Brendan, you think that something's going to take half the amount of time that it actually will take every single time. And over time you just realize, you're like, okay, I think it's gonna take three weeks. Okay. I'll say six weeks. I also think like date driven development is a good thing at times because it clarifies the mind.
Dan Lines
Working within a boundary, you can bring out the best solutions or creativity, I've seen that.
Brendan Burns
I will also say that I'm a really big fan of the of the release train approach, which was to say, the release leaves the station at the same time, every single week.
Dan Lines
Is that how you you're doing it across your teams?
Brendan Burns
It's why we try to do it, because I don't want because like, I had teams where it was like, oh, let's just hold the release for one more change. Let's hold the release, or one more change. It'll come in and like an hour, it'll come in and an hour and a half will come in tomorrow morning. People are like rushing to jam their thing into the release so that they didn't miss the train. And the two things that happen there is to get way worse code review.
Dan Lines
So you get worried because they're rushing.
Brendan Burns
Let's get it. Yeah, like so they're gonna give a way lighter weight code review, because they don't want to give a bunch of heavy comments that somebody's got to take a bunch of time to review.
Dan Lines
You read it. You gotta digest, make the changes, you're gonna miss the train.
Brendan Burns
We continuously to deploy our build, do you do we do like, generally speaking, weekly release, but there's a continuous build.
Dan Lines
Yeah, yeah, so you can always get latest?
Brendan Burns
If you jam most of the changes into your release in the last day, you have almost no subside. So your releases is less stable, too. I really feel like that's one of those things, it's pretty important to be like, no, no train leaves the station at noon, every single damn day. If you miss it, you're waiting. Setting that expectation.
Dan Lines
This is an assumption, but when I think about maybe a team, your size, I would think also though, like when you're releasing, do you release a percentage of the populated environment? Like staging the relief? Hey, 1% of the users are going to get this then 25 Oh, we found an issue. Because it's real world behavior.
Brendan Burns
It really depends on the service because a lot of the services are regional. So it's more like we released to East U.S. we released a West U.S. mindset. But some things are global and the Global Services tend to release started in a different way. So I guess yeah, the answer is yes. In general, we do stage releasing, how you determine how you stage depends on the details of the service.
Dan Lines
Super interesting. We could do a whole show just on how you work very cool, interesting stuff. How did you make the journey from thinking like an individual developer to becoming an organizational leader?
Brendan Burns
Yeah, it's a long journey. So there's that. And then lots of little stops along the way, I think it happens very naturally in some sense, because like, you're working in a code base, and you develop something and you become the expert in that area. And then people start asking questions, and you get used to helping them understand. And then somebody comes and says, Hey, I really wish that I could have this feature faster. And he said, Give me another developer, I could probably do it faster. And suddenly you have a small team. And then you realize that actually, you want to do something bigger, and there's this really good person on your team. And so you say, hey, you're going to take over this team, and suddenly, you've delegated the responsibility to them, then you start taking that first step up the ladder. And then eventually, I think that's one of the jumps. And then the next jump is when somebody comes to you, and you have two teams, and it's suddenly broken, I have to split my brain in half. And I'm gonna have moments when I'm thinking about this team. And I'm gonna have moments when I'm thinking about this team. And I would say that phase continues for a while. And then the next phase shift from me really switching from a team that I had built to a team that I had inherited, and how do you get to know a new team? How do you become a leader of a team that didn't naturally just find you to be the leader? That was another kind of organizational challenge that you have to learn how to establish yourself as a leader as opposed to organically just being leader. I think most recently after 400 or 500, I realized that I have to figure out how to be an at scale leader, meaning like, how do you maintain? You're so distant maybe from the experience of someone in one of your teams, how do you know what their experience is? How do you figure out a joke that I want like the the button that's like in the airport bathroom, like you leave and you press the Like happy face or the sad face, I would love to have every one of my engineers, like, punch that button every single day because you lose data, like you just don't have the sense of what their lived experience is. And so I started doing a lot more like office hours, so that anybody could sign up and come to a one on one or like skip level one on ones. A lot more broadcast all hands style stuff, where I previously assumed that people will just take the message about what's important to me what the message about what might work and what I want to think about work life balance, how I want to think that these sort of like broader topics, and I realized it wasn't happening. And so I needed to do more like conscious broadcasts, style stuff. And then especially in the pandemic, I've also been trying to figure out, like, how do you get that, like people bumped into me in the elevator, and just start talking. And then sometimes it's really awkward, because you're like, I think I should probably know who you are that idea who you are. But a lot of the time, it's somebody and when we're on zoom, and everything's a formal meeting, like those interactions have gone away. And so I'm starting to do virtual coffees and some virtual happy hours, that sort of thing, just to give a little bit more of that casual interaction. So that was that's the at scale part of it. And then also learning how to damper yourself. That's actually also really a challenge, I think where early on, I had some experiences where I'd run into somebody in the elevator like that. And they'd say, Hey, I'm thinking about this idea. And I'd say, Oh, that's a great idea, you should really go pursue this. And then four months later, they asked for a meeting, they'd be like, I've devoted my life to this. And he's like, wait a minute, it was just an elevator idea, like maybe like, we should have checked it out a little bit. And you realize because you don't have that fast interaction, you have to damper your response. Because the power or the impact that you have on that person is much greater than it was when you were a tech lead, and you ran into them every day. So there's this certain responsibilities to like steering an ocean liner instead of a speedboat. That was definitely a challenge to learn. I benefited a lot. And I think the places I've been I've also really provided a lot of great leadership training, a lot of great mentor training. A lot of it's not something where it's how I woke up. And suddenly I had to do this, it's much more like you meet with the other people who are doing it in the organization that you're in, and we all figure out what's worked for you and what hasn't.
Dan Lines
Certainly a journey of evolution and learning, do you have any kind of internal algorithm that you use to decide, hey, when should I delegate this? Or when should I dive in and see what's going on? I'm sure ou have to think about that all the time, especially as you have scaled, is there any kind of like reasoning you use to make that determination?
Brendan Burns
Yeah, I think you should delegate always effectively. Right? First of all, because I think that at least I don't know, for everybody but for me, my natural reaction probably is not to delegate. Because delegating is scary, right? Delegating is giving someone else responsibility for something that at the end of the day your ass is on the line. And so it's scary. And I think we'd shy away from it. And so I think that trying to bias yourself towards delegation is the right thing to do. Someone once said to me that I micromanage as a form of punishment, or as a form of expressing that I have a lack of confidence. And so when I come in, and I tend to dive deeper, it tends to be because for whatever reason, I'm not as confident that you're headed in the direction that I think you need to be headed. And I'm not certain and so like, my reflection of my uncertainty is less delegation, more reviews. Sometimes it's just prioritization too. Sometimes I have to be like, hey, this is an important customer over here and you may think their issue is not super high priority, but the problem is that they bring a ton of revenue, and they have a great support contrac, so it is actually. We don't get to choose that one, we're gonna go talk to this person. Or sometimes it's broader strategic, you just don't have the context. Let me come help explain the context. It's my job is to say, Oh, you know what, that chapter is a little confusing. Let's go rewrite that chapter. Maybe you just need to bring this context in to help explain. But I think that some of the best advice I ever got from someone in leadership training is that you should always be leaving, you should always be like, everything that you are doing, you should be figuring out how you can stop doing it. Who's going to be the person who's going to pick it up? Who's going to be the person who's going to take it on? And that's going to think that's guided me throughout. It helps I'm a little lazy. Like, everything that I'm doing, I'm trying to figure out how can I stop doing it.
Dan Lines
I love the mindset, totally the right mindset, because it can help you. It's how you scale yourself, and how you can grow your career. So you can move on to the next opportunity. If you're going to build up and be stuck with the projects that you have, you're never going to move forward. So I love the always be leaving mindset.
Brendan Burns
Because it does it makes room for that next thing and it makes room to to experiment and to innovate.
Dan Lines
This has been a fantastic conversation, Brendan, thank you so much for taking time with us here on dev interrupted and talking about your career journey. And all the amazing work that you've done with Kubernetes as well as what's coming next at Microsoft. Thank you so much.
Brendan Burns
Absolutely. Thank you.
Dan Lines
What's the best way for our guests to follow your work or learn more about what's going on with you?
Brendan Burns
Twitter is pretty good @brendandburns. Yeah, that's probably the easiest way to get to me.
Dan Lines
Awesome. Definitely check out a Brendan on Twitter. Make sure you have the D in there. And a quick reminder for our listeners. If you haven't already reviewed the show on Apple podcasts. Please take 60 seconds to do Apple podcast reviews are super crucial for the way that our show gets discovered. Also, be sure to join the dev interrupted discord community where we keep this type of conversation going all week long. You can find all of the information in the links below. And Brendan, thank you so much.