I've always said, for the last 15 years of Microsoft, if you don't get in trouble twice a year for advocating for the customer, for doing something that you feel strongly about, then you're not pushing hard enough. Now that comes from a place of level privilege, but I can shield my team by using my level privilege. So like if I came to you, Mark, we'll just pick a random person and say, let's say Fred, I made that native. I call you, I said, Mark, I was in a meeting with Fred, and he was so crisp, and he was so strong and aggressive,
you would say, oh wow, so Fred was really advocating for the customer and trying to do what he thought was right. Well, yeah, but I didn't like his tone. And then you'll take that feedback and you'll put it in the round file, which is the trash can, and you'll go to Fred, and you'll say, hey, handsome, I thought you were a little crisp in the meeting, good job. You're pissing off the right people. Keep advocating for the customer, right? And that's how things get done. That's my opinion. So I've been trying to get the team to let them know that I will back them up if they
bother a few people with their advocacy. Is that a reasonable thing to do as a leader? I think so. It comes with balance, right? I mean, there have been people that advocate for the customer, but they come across as a Serbic. A Serbic. And they end up irritating people constantly. So you got to figure out where the line is. That's a great point. So I want to learn how to influence people without authority. You are the CTO of Azure. I assumed that when you, what's that?
Do we start? Yeah, we're starting. This is the show. Oh, and even this part right now where I just said, did we start? This is the show that's staying in the show. It's in the show. All right. That's how this podcast role. This is Mark and I thought you're having a pre-show discussion. No, there's no pre-show. So what we do, even this, this is a meta thing referring back to the meta thing. It's still in the show.
What's going to happen in a second is they're going to play the music. When I say, I'm Scott Hansman, and I want to learn how to influence that authority. Hear that? That's the music. And now we're back from the music part. You're the CTO of Azure. Can't you just tell people what to do? Actually, yeah. I can. It doesn't always work though. Why can't you just make a meeting?
Even I realized this when I had my own software company, I started a company called Winternals in 1996 that sold to Microsoft in 2006. I was the chief software architect and co-founder. I had the ultimate authority. And I realized even then telling people what to do is not a good way to get them to do what you want them to do.
And so even then when I had authority, you can't just use authority to lead people. You've got to use influence. Of course, Nelmana role where it's where I don't have direct authority over most of what I'm trying to do. I don't have got to use that influence more. But even when I was at Winternals, I realized you've got to sell people. You got to sell people on the vision and why it matters and get them motivated to care about it, to get them to do things that you want them to do.
Yeah. So here we are. Sell them such as book has that whole create clarity generate energy deliver results. Yeah. I feel like it's sheep hurting or like that old classic Super Bowl commercial what they heard the cats. Hey, you can push all the cats and cat hurting is that you're really just trying to say, Hey, everyone, there's good stuff over there. Let's head in that direction. Here's kind of the vision.
It's on the other side of that hill and it's never going to be a clean line where we all march like Hannibal directly into war. But if we can get most of the cats in that general direction or in the kids are like, it's the ship turned. It's the way you refer to it. This is ship full of cats. Yeah. For mixing metaphors. Yeah, it's a big ship and it turns very slowly.
When you got that role in that title, you didn't have any illusions that you were going to start bonkenheads and telling people that we're turning. And you do like a neck a tron 90 degree turn and a giant ship. No, definitely not. And the way that certainly in this position that I'm in, which is a lot just influence. I'm able to influence and my ability to influence has generally grown over the time that I've been in Azure since 2010. And that's based off of building trust.
You know, you're helping people. You've got a track record of getting people to do something and actually it proves to be. Good outcomes come from that. That builds capital that then helps you influence. So like when you go say something, they're like, oh, this person's coming to say something. You're either warning or they're pointing at this direction. We should go and I'm going to give that a lot of weight because their history of generally being right about these things.
And even then you still have to. Here's why here's why it matters. You ever feel like that? Like why should anyone listen to this guy? Do you go or go into meetings or do you always like, how do you carry yourself with that? Like yeah, people should listen to me. I know things. Well, you've been in meetings with me. In fact, we've ever been in meetings now. I go into meetings with you and you announce, do you know who I think I am? And then that's just meetings with you one on one.
You just mean to me in meetings, man. You're the worst in me. Especially when you don't respond to me immediately on teams. Yeah, that's true. I do try to annoy you. That goes into the roundfiles. Yeah. Like I just, when I am at my most frustrated, I'm like, someone should do something. And Scott Hunter, my boss, when I got the title VP a year ago, I would go and complain to him. And he said, someone should do something. And he said, yeah, someone should. Like that's literally you now.
Yeah. Actually, that's the message Sacha gives to the exec staff. Oh, yeah. It is your job is not to complain. Your job is to go fix your complaints yourself. Yeah. The buck stops with you. That's what he tells us. If you're not going to fix it, nobody is. Yeah. There's a natural reaction though. Like I think it's normal. Tell me that I'm not the only one who's childlike in my behalf. But there's someone to do something. Yeah. And then you go and you appeal to higher authority.
And then maybe they have a bigger hammer. Maybe there's a bigger Thor, the bigger hammer. Or are you such an enlightened and mature individual that you recognize that there's no one else? You go call Kevin Scott and tell him to bring a hammer. It's generally not like a wow, these people are just completely ignoring.
It's more like the most of the time when you, when I'll call on Scott or the engineering leaders, this very seniorly engineering leadership, it's more like the org itself hasn't been given the priority. Or it's a priority, but there's no accountable person or organization to make it happen. And that means that nobody feels accountable for it. They'll all agree it's important, but nothing gets done.
And that's generally when I'll have to go talk to the engineering leaders and say we've got a gap here on driving this thing. Yeah. The gap thing has been really interesting to me. I have found a couple of interesting gaps that aren't my job. They're explicitly not my job. Like I'm interested in ARM and the shift from X64 to alternative processing. And ARM is really attractive both in the cloud and also on desktops.
And I'm noticing some some ecosystem gaps, some open source gaps and stuff like that. But it appears that in some instances it's not anyone's job. So then when I complain about it, what I'm really complaining about is like there either is someone out there whose job it is, or it doesn't exist as a job. And then when you go and try to get people to do what you want them to do, they're like I have stuff to do. Like I do. I have no more extra days to do the thing you think is important.
That's where things get uncomfortable for me. Yeah. Forcibly what I do in the influence of finding a gap like that where nobody's doing it is having the ability to convince people this really is important enough to for you to go and reprioritize what you're doing. And a lot of times I don't have to just get into the exactly what are you doing. Let me see the list and naturally they'll do that themselves.
And there are occasions like I'm talking about just a second ago where there is something that's a priority but nobody can reprioritize what they're doing to make room for it. And that's where you need the people that own the resources to say I'm going to reallocate now to get this done. Yeah. The problem is that there's always a way to say that something is more important like security things or the house is on fire. It's like hey I don't like the color of this carpet.
Yeah but the house is on fire. That kind of stuff is always challenging because then you get into those if you had a hundred dollars, would you spend your hundred dollars on? Yeah. And this is the whole important versus urgent. If you only chase the urgent things, the important things never get done and they end up becoming urgent. That's a risk always. And this is like the art of resource allocation because there's always way too many things that are important for you to do.
And there's also a set of urgent things. If you don't do them, you're not going to be able to do anything eventually. But that's your own personal resource allocation. How much time do you have? And then your own team. And ultimately there's always a cut line, isn't there? There's always a where we're just not going to be able to do that. That's not a thing we're doing. Yeah. That's tough.
So figure out the balance because there's this hierarchy and big companies and capitalism build these hierarchies of your bosses and your skip bosses and stuff like that. And you want to empower people to make decisions on their own. You want to give them clear priorities. But then you're not really sure what we should be working on. And then it makes me wonder what Sacha and what a CEO of a company of hundreds of thousands of people does. Does he give three bullets? And that's our priorities.
And then the next people give three bullets and it gets more and more granular all the way down. I probably shouldn't call him and say, move the task bar to the left. That's the thing we need to be working on right now is make it so the task bar can go to the left. Yeah, you call. Yeah, Scott Guthrie. He'll tell you to do that. Call Guthrie. And then he'll find the world and then it rolls downhill and then I'll end up doing it.
Now, Guthrie will just look at your thing and go, the task bar needs to be three pixels to the left. Oh, God. Did he get that? He gets that involved in aesthetics. So that's funny. That's a funny example, actually. I used to hang out with Guthrie when we did a asp.net MVC, early days of open source and .net. And, you know, he was already a general manager, but he would still have an intention to detail where we talk about, are we doing KNRC, curly braces or are we doing them?
That was a detail oriented thing. How deep do you get? Because I've seen you get stupid, stupid with two O's. Yeah. Do you just do that because you enjoy it? You don't need to like reach nine deep into the org and start telling people what to do, but it's enjoyable sometimes. I do it because I think it's important to understand a few levels deeper than the one you're operating at. And I always felt this.
For example, when I was learning Windows and Turnles and then teaching Windows and getting into new areas that I wanted to talk about or write an article about it or write a chapter in the and turn Turnles book, I felt I had to go one, at least one level deeper than what I was going to write about or talk about. Yep. Because if I didn't, I wasn't sure if I was really correct and accurate and complete.
And I also needed to go to that level of depth so that I could process it and then abstract it for people. If you're not doing that, then you're just kind of regurgitating things and don't really have a true deep understanding. And I think the same, that's why you see me in these meetings go deep is so that I can learn something underneath that can help me put in that understand at the level that I'm operating and care about.
What are the constraints and requirements and how things really work underneath that? Yeah. That's a really good thing. That's a takeaway for folks that are listening. If you want to learn how to do stuff, I say that a lot. You and I have been bouncing that idea of learn, find your comfort zone, find where you are and then get uncomfortable by going one layer deep. One layer deep in the call stack, right?
If you have been a C-sharp programmer for years and you've never programmed without a garbage collector, trying without a garbage collector, never opened up wind DBG, wind bag and take a dump and take that dump and debug it. You know what I mean? I'm pleased you said that. But you know what I'm saying? Like go one level up. It's got wind DBG. You've just shown your naivete. Oh, pardon me. How do you say it? Wind DBG or wind bag? It's wind bag. Yeah. It's so funny.
What was it, David Fowler has been trying to get NuGet. He wants me to say NuJ and then like the NuGet packages are nub cakes and it's so funny to try to influence people. Is he speaking of influencing that author? Is he going to say NuJ? Is that for real? Like he wants it. No, it's like saying tarje. Like I'm going to tarje or Jacqueline Pinae. It makes it sound fancier. But like I've never heard that. NuJ. Yeah. Yeah. Yeah. Yeah. I can be a thing. I tried that while it didn't stick.
I didn't know nobody was shushing into production. Yeah. Sometimes people hand them into production. I used to remote desktop directly into production machines and they call it hand summoning because it was a bad idea. But yeah. Like Scott Hunter, my boss, and Amanda. Amanda's like Amanda Silver runs all of her studio. She's a compiler nerd. So you'll catch her in VS. When you're coding every week, I wonder, like, does Sacha ever crack open stuff?
Like, when are the Sacha or the CEO equivalent of going one level below your comfort zone is? What I see him do, it is fascinating, is every now and then on a pretty frequent basis. I'll get an email from him with some other people on it. It'll be like Sacha coming across a technical article or blog post on some aspect to cloud native computing or AI accelerators or whatever. And he'll say, this is really interesting, this point that they make here. In fact, there was just one a few days ago.
I'm like, or a hacker news thread. I'm like, how is Sacha have time to go reading hacker news in these blog posts on medium? And then somebody does. Yeah. Scott Hunter does this thing we call it hunter driven development where he'll find gaps in the product because he'll force himself to do a keynote. And then the night before in the hotel, he'll find a gap or something.
And then it's like, okay, it's like if you've got a muscle that's not that's kind of tight and he's just pushing on it until you, I found the knot. Yeah. And then he started to push it on the knot and that product knot makes a better product because because our leader went one layer deep. Well, actually, this is a great example of I think something that I try to encourage people to do.
And it's really important as, and I saw this in Windows when I'd come to Microsoft with Dave Solomon to teach Windows internals is I'm not the world's expert on, for example, the registry for even one back then. I was, because there was always the guy that made the registry or owned that component. That's the world's expert. But what I found was that the registry guy or girl knew the registry but didn't know anything about memory management or didn't know anything about thread scheduling.
And so I would come because I knew quite a bit about all those things and taught the Windows engineers about the other systems of Windows that they weren't working on. But I've always felt that and maybe that, you know, it's a good thing that they were coming to the class to learn those things is that people end up falling into silos. Like, I'm working on my component. I come every day to work and that's what I'm going to do.
And they're completely blind to everything else that around their component. They just, and it's so important, I think, especially if you want to advance in career to understand how your component fits into the big picture and to understand the big picture.
And this applies even in Azure, for example, where developers are working on their specific service and they don't really know anything about the other services in Azure or how they work or the end-to-end user experience, which is so important. Like my service is this service, but how do people interact with my service? Yep. What's the SDK like for them? What's the portal look like when they go use my service?
And it's unfortunate, it's just a general thing, I think, because people get so cut up on what they're doing is that a lot of, you'll find engineers that they're working on their component. They've never seen the portal experience for their component. Okay. So then using that, what we just learned to influence people without having explicit authority over them is I've explored this. I've become a T-shaped developer. I see how I fit into the big picture.
And I can go and use customer empathy, product led growth, and tell leaders, hey, I think if you up level this as now that I've dug in, we should make a change. And I will take feedback from anyone at any level if they have an insight that shows that they understand the stack and the product. Yep. It just, I think, makes you more well-rounded. You understand your component's significance in the big story. You understand what the customers are experiencing.
And maybe it's not your job, the portal experience isn't your job, but it is your component like and pride and ownership and what I do and what I contribute should translate into, you know what, this US experience is not that great. Here's an improvement we can make. And I know because I've tried it. Yeah. So get outside your comfort zone. Go a little deeper in the stack. You don't have to be a full stack developer.
No one's asking you to smelt your own iron, put lightning in silicon, and try to make a processor. But like just a layer deep. But then also up level, where do you fit into the machine? Systems thinking. We should do a show on systems thinking. Yeah. Because a lot of people learning how to code, but there's not a lot of people learning how to think. So maybe he's gotten Mark learned to think would be a cool show. Yeah. All right. Well, I'm learning how to influence without authority.
You've given me a lot of thoughts. I got a team meeting coming up a little later this afternoon. I'm going to put some thought into this. Thank you for this show. Yeah. Thanks, Scott. We are learning here on Scott and Mark learned too. We're learning how to do a podcast. So if you like this show, reach out to us on social, give us ideas. I'm what we can talk about in the next episodes. And your shares, your reviews, your stars on wherever you get your podcasts are very much appreciated.
We're doing this because we love to learn and we hope you love listening to it. Catch you again next week.