 This next myth is one that Oren snuck in on me, that we decided to keep, which is just getting older always lead to management. Thanks Oren for putting that one in as your manager. I appreciate that. Maybe it's some kind of a subtle reference that I should maybe not read too much into. But in my career path working in IT, again, I said I started a long, long, long time ago just in the cable to get that printer to work and then progress through being a LAN administrator, being a WAN administrator, I got started in Banyan Vines as well back in the day, and then progress through to going off and being training and deploying people using new PCs, configuring and working with client server environments for that large environment. I ended up taking some training myself and then someone asked if I'd be interested in actually becoming a trainer at that point in time and a consultant, because I was able to explain things well to different people. Fast forward to where I am now working at Microsoft, and it's been a great journey. But at one point, I got out of doing public speaking, and I went and worked in engineering for five, six years, and on the Azure engineering team, the point I was doing is I was shifting my focus to become deep in certain areas to learn the background of different technologies that I now talk about again. But then someone came up to me and offered me the opportunity and said, hey, if you could connect up and build a team of people that did the stuff that you used to do, talked to the audiences that you used to talk to about different topics that are super wide for the stuff that you do, would you be interested in it? I'm like, yeah, because it gives me scale. It gave me vertical scale to go off and do what ultimately I'll have to do, which is help people solve problems. So they become more successful in their careers inside their work environments, and then they help their people go off and be more productive and do different things. That's ultimately a core of what I believe I should be doing. So now I've got a team of people that do that because I really did hire people that are smarter than me, because there's no way that I could go to the same breadth and depth of knowledge that these different specialists have. So Pierre is not in the room anymore, but Pierre is on my team as well, and he's my guy that's the generalist Azure all up, very much into automation, very much into networking. Orin is beyond super deep when it comes to on-premises and hybrid technologies with Windows Server, but then has this pedantic memory of being able to remember almost anything that he reads to be able to apply a big breadth of category of stuff across the board. I've got another person on my team that works specifically on VMware solutions because we have a VMware offering inside of Azure as well, and so on and so on. So I built this team that gives me vertical scale, sorry, horizontal scale, and that has vertical depth because I couldn't do that as an individual. I was a choice and I loved it and it's been great, but it's absolutely not for everybody. I would never wish upon anybody to be a direct report of Orin. What's your philosophy on this, my friend? My philosophy is I wouldn't want to be a direct report of Orin either because I would be awful to work for, simply because I have no idea of a reasonable amount of work and what's not a reasonable amount of work and how you take leave. That's always been a bit confusing to me. But one of the reasons that people will smile riley at the idea of this myth is that we have all seen people move into management and their technical skills of atrophied, and that's something we also fear because for a lot of our career, our currency is our set of technical skills. So I'm going to interrupt you here and just say you're treading on what's in ice, my friend, as a manager in the room, but you can continue. Go ahead. Go ahead. Our performance review is next week. Well, again, where I'm going with this is that we have seen other people move into management and have their technical skills atrophied. Why? Because I spent so much time dealing with these weird components called people instead of dealing with the fun solvable components called computer. Now, that's one reason why we might avoid management. It might also be and I cannot stress this enough. Unless you really want to manage people, don't do it because one of the things that we see a lot of, and you've probably seen throughout your career, is people that have been bumped into management because they wanted the higher pay packet, but they're absolutely terrible at management. There's a thing called the Peter principle, which you are promoted to the level at which you become incompetent. That is that if you're really competent, you keep getting promoted and you stop getting promoted when you can't you're not the best anymore at what you do. You can't go up any further. That doesn't mean management. So some people choose to get the higher paycheck of being a manager, but find that they're out of their depth. If it's something that you're passionate about, absolutely go and do it. Me, not a chance. Now, so what do you do? How do you go? Because this is the thing, I'm at my stage of my career, I'm a principal at Microsoft, and I'm looking around at people, and I know that most of the people at a partner level are managing very large organizations like Rick's boss, my skip box. Let's interrupt for one second. Just to clarify, principle level, partner level is three more steps above that, as far as progression in your career at Microsoft, and then above partner level, three more steps above that, is your VP level, and then there's even more VP levels before you get to the Satya level. But this weird is that the principal level is a big turning point that he's going to talk about here. So where I'm going with that, is that when you're looking around and you've reached a certain level of your career, the people that are still what we call an individual contributor start to get a bit thinner on the ground. Most of the people who are your peers at the same level tend to have very large teams, and Rick hooked me up with Jeffrey Snover as a career coach, and that was actually very useful because Jeffrey managed to go all the way to distinguished engineer at Microsoft without having anybody report to him, but the guy invented PowerShell. So what do you do with your career? You've probably heard the analogy of being T-shaped. That is that you're a good broad generalist, but that you're excessively deep on a specific area. So one of the things that you want to also think about as you move into this later phase of your career is really becoming the absolute expert on a stack or an area of technologies. Now, the first fear you'll have is I'm becoming an expert on a technology that's not relevant. Well, here's the thing, over the previous 25 years of your career, you've worked out what technologies are absolutely relevant to your business, and you've probably got a fair idea of what's going to be around and what's not going to be around. We know, even though there's a new name for the cloud version of it, that in some way, shape, or form, Active Directory is going to be around probably for the next 30 to 50 years. Now, why do we know that? Because we've still got people running Windows Server 2008, still got people running Windows Server 2003. So people don't tend to migrate off things as quickly as they used to. SQL servers are going to always be around. There's 800 billion lines of COBOL still in production. So there's certain technologies which are very rock solid that solve business problems that if you're an expert on them or you're very deep on them, that makes your career more valuable. And you will understand through the course of your career and your own understanding of the landscape, you'll have a fairly good idea of what's going to be around. There's a thing in economics called the Lindy Effect. That is that when a technology has been in use for a certain amount of time, a long time, it's probably going to be in use for a long time in the future. It takes a lot of change and a lot of momentum to disrupt a really lodged in technology. And that's something, if you look at the pace of technological change, in the 1990s, it was very fast. But now, if we think about why are people still running Windows Server 2008 or Windows Server 2012, which reaches end of support at the end of this year? It's because for the most part, the newer versions of those technologies aren't so massively different and aren't so revolutionary. When I was working in 2000 at a big metals company in Australia, I remember remoting across to a server that was running Windows NT 3.51 and thinking in 2000, oh my gosh, there's a server that's six years old. What an ancient piece of technology. Has anybody today remoted into a server that's six years old and gone, that's ancient? Or is that just standard operating procedure now? You've successfully managed to make every single marketing person at Microsoft kind of pass out, I think, with what you're talking about. But again, completely concur. There's a certain tipping point that you will come to know when it makes sense to go off and shift to that particular next version or whatever happens to be. However, another big long diatribe, which I'll save us all from because Orin and I go off on tangents with it, is around the complexity of IT projects and the amount of cost overrun that happens inside those IT projects. Generally, is that big barrier for being able to start it in the first place? Or you go ahead and start it and you realize after the fact, oops, there's all these other cost factors involved or other complexities involved that end up tanking that particular project and not being all that successful. As you mentioned, the IRS as an example, still running the majority of the entire taxation system for the United States on mainframes and on COBOL because it just works and they don't have resources to go off and even explore new things. But adoption of those new things potentially are not gonna offset the disruption that it might cause and or the cost factors for what it can cause. And there's another element to that as well and this is a slightly separate thing. In terms of cost overruns, the average IT project cost overruns by 700%. Now, that means that's the average and that's simply because there are certain tail IT projects that have gone so far over their budget that they've skewed it a lot. But in terms of likelihood of a project going over budget, the only thing that beats IT as a classification is nuclear energy. So that's why a lot of organizations are reluctant to embark on revolutionary change in IT. So our last myth we're gonna talk about before we give you some actions are specifically around the whole concept of evolving from a job into a career. So a job is a point in time and a career is a continuum.