CoRecursive: Coding Stories - Story: Jeffrey Snover and the Making of PowerShell

Episode Date: July 4, 2024

What if you had to fight against your company's culture to bring a revolutionary tool to life? Meet Jeffrey Snover, the Microsoft architect behind PowerShell, a command tool that transformed Windows system administration. Initially met with skepticism, Snover's idea faced resistance from a company that favored graphical interfaces.  Snover's journey began with a simple mission: to make Windows as command-line managable as UNIX systems. Despite facing pushback and navigating through company restructures, his persistence paid off.  This episode explores how Snover's relentless drive and clear vision overcame numerous obstacles, leading to a tool that is now fundamental in modern enterprise environments. Listen to how one person's determination can challenge the status quo.   Help Adam Find His Next Role I'm on the hunt for a new developer relations role.  If you know of any companies where they need someone who can speak engineer, who can communicate to developers, that's me. I'm your guy for explaining complex stuff in a way that's catchy and fun and makes sense to software developers. If you know of any roles like this, let me know. Who should I be talking to? Reach out: [e-mail], @adamgordonbell, Linkedin, My Calendar. Links: Episode Page Support The Show Subscribe To The Podcast Join The Newsletter  

Welcome to Co-Recursive. Each episode is the story of a piece of software being built. Before we dive into today's amazing episode, I need your help. Like truly, I'm on the hunt for a new developer relations role after being laid off from Earthly. During my time at Earthly, I really honed my skills in combining coding with communication, right? I'm talking about making tutorials, doing conference talks, YouTube videos, the whole shebang. My developer-focused content had a lot of impact at Earthly, you know, hitting the front pages of Reddit or Hacker News and showing up in search results and letting people know about the cool stuff we were doing. Yeah, so now I'm looking for a new role

where I can keep flexing my software development muscles and my communication powers. And so I'm looking for a DevRel role. I know it's a bit of a niche, but if you're aware of one, that's where I need your help, right? If you know of any dev tool companies or dev op outfits or app security tools or AI ML places where they need someone who can speak engineer, who can communicate to developers. That's me, right? I'm your guy for explaining complex stuff in a way that's catchy and fun and makes sense to software developers. So here's how you can help. If you know of any roles like this, let me know, right? Who should I be talking to? You can reach out to me, adam at corecursive.com

or on Twitter at Adam Gordon Bell. I'll put a link to my LinkedIn in the show notes and a link to my calendar. If you want to set up a call and just tell me about an opportunity, then go for it, right? I'm excited to find a new role where I can keep doing what I think I'm pretty good at. I think I'm good at developer communication. And hey, maybe you even know about something cool that I haven't even thought about. And if so, let me know. I'm all ears. But all right,

that's enough about me. Let me know if you can help me know. I'm all ears. But all right, that's enough about me. Let me know if you can help me out. But now let's get to the podcast. Today, we have the story of the creation of PowerShell, a tool that transformed Windows system administration forever. And it's a fascinating story because of all the challenges it took to get it built. And especially because at the time that PowerShell was built, the culture at Microsoft was definitely going a different way. But was it okay to swear? Oh yeah, you could swear. You know, I had executives, Jeffrey, exactly which part of fucking Windows is confusing you, Jeffrey. Two keynotes ago, Bill Gates got up there and said, look,

here's command.exe. It's the last time you're ever going to see it. He types exit, carriage turn, it goes away. Like, remember that? And then what the hell is this Snover guy talking about? Comes in from the outside, doesn't drive a fricking Porsche. So let's get that in focus. Okay. Not driving a Porsche. And he's saying we need to do command line interfaces. But over here, you look, I mean, I wrote this GUI. I got a promo. John wrote a GUI. He got a promo. Like who's the person that wrote a command line interface and got a promo? That's Jeffrey Snover. He's now a distinguished engineer at Google. And yeah, he is the creator along with his team of

PowerShell. Today, he's going to share his insights on navigating large organizations and driving change, how to achieve significant outcomes despite strong opposition, right? This is the essence of technical leadership. PowerShell, if you're not familiar, was groundbreaking, not only influencing other CLIs, but enabling Microsoft's move to the cloud and maybe most importantly, cultivating a vast network of skilled Windows system administrators. In fact, Jeffrey got his start at Microsoft because in 1999, Bill Gates at the height of the relevance of Windows. Well, Bill Gates was worried that Microsoft just didn't understand the data center, didn't understand the enterprise market. That's where our story starts. So this was kind of a fixation. Hey, how do we make sure we're not complacent,

that we're not sitting there patting ourselves on the back and saying, this is great. So yeah, we've been wildly successful at the PC, but look at all this money being spent in the enterprise software marketplace. We want to be good at that. What do we have to take? Now, again, there's the organization and there's the leadership. Bill understood that. And so then when the organization tried to do it, tried to do it, tried to do it, that's where they had that famous meeting where it's like, okay, I think we need some help. Let's bring in some people who understand the problem better. The problem was clear. They didn't understand the server market. Their executives were skilled in the personal computer realm, but they lacked enterprise

experience. That's when they found Jeffrey. A Microsoft executive who I met a couple times before, awesome guy, Dave Thompson, he reached out and he said, well, Jeffrey, I'd like to talk to you. I was like, well, okay, well, I'd like to talk to you, Dave. Anyway, so at the end of that conversation, I ended up having my final interview with Jim Alchin. And again, the question, what would you come to work for? I said, no, your software is crap. And he said, Jeffrey, I know, and I need help. And you're the guy that can help me fix that. And think of it this way.

If you do that, if you come here and help me fix this, think of the effect you'll have on the world. That was like a laser guided missile to my psyche. It's like, yeah, I'm in. The goal was clear to establish Microsoft NT-based operating systems in data centers and to out-compete Unix vendors like Sun and IBM and HP. How do we do that? And the answer is we do the same stuff with a lot lower cost, right? Same capability, a lot lower cost. One, we have an

intrinsic price advantage because we were on Intel and most of the Unix vendors were using it as a mechanism to sell proprietary hardware. So we had Intel, but we also had this like open hardware ecosystem. So that gave us a structural advantage. So now our software just had to be as good and boom, we win. But the software wasn't as good, especially for managing many servers. You are physically clicking a mouse and configuring things on every machine. And the setup you need for each business might vary. A bank is different than an industrial control process. It's different than, you know, the scientific lab.

Everybody's different. And so basically, if the scenario doesn't work, then what do you do? And the answer is IBM Professional Services or Arthur Anderson or, you know, systems integrators, right? And all of a sudden I say, my hardware costs 10, my software costs two, and then my systems integrator costs me 40. Like, wait a second, in that equation, the hell, we're right back with these guys.

So the key thing was you can't have systems integrators. If you have systems integrators, the whole price equation is broken and it doesn't work. And then they get all the value and then they also own the customer. So anyway, so you had to get rid of the systems integrators. And so the answer is, well, in-house systems integration, right? That's what the Unix model was. These Unix guys aren't going out there hiring IBM professional services. They were doing it themselves, right? Because they were programmer admins. And so he said, that's what we got to do. We got to develop our own professional class of administrators,

people who can do more than just click next. They become our systems integrators. They're not going to cost what IBM's going to cost, where it's an upfront thing, it's a salary thing, and then they can become heroes. And so how do we do that? And the answer is, of course, the Unix composition model, right? Have a tool chest of small tools that then these people can put together to solve unique problems, automate it, and then go solve the next one, the next one, the next one. This plan is what Jeffrey calls a plausible theory of success. It's not probable, right? But it's plausible. There is a path where this could possibly work. And so Jeffrey joins Microsoft's Windows Server team to help with this mission.

Like literally, I faxed in my letter of acceptance, and 20 minutes later, I get a call from Dave. I'm thinking, oh, wow, I must be looking at the fax machine. That was pretty quick. No, it wasn't. He called me up to say, hey, Jeffrey, just heads up. There's been a reorganization, and you're not going to be reporting to me. You're going to be reporting to this other person. What? Oh, no. and you're not going to be reporting to me. You're going to be reporting to this other person.

What? Like, oh, no. I already faxed him my letter of acceptance and hit enter on my email to my boss saying adios. So I was like, oh, holy shroly. But the idea was that they were, he owned Windows Server, and what they were doing was they were taking the management technology out of Windows Server and combining it with some management products. So it's going to be a management division. And so he says, you're going to be the chief architect over this management division. I said, so is this a good thing? And he says,

yeah, it's a really good thing. And I think that was the only time Dave ever lied to me. This management division, right? They're all about making Windows easier to manage. So it's still really what he signed up for. But the problem is the group is made up of these people who've been succeeding by seeing the world through this lens of personal computing. Now, again, they had small business server, right? You know, an admin in his server, right? Boy and his dog. You got one server, you go there and all that sort of sensibilities, you know, you walk up to it, you have a mouse, you have this little screen, like happy days, click, click, next, next, next. And they had been very successful with that, right? So again, they were thinking, hey, that's the way to do it. This is all good stuff. And I was coming in saying, well, yeah, but for the enterprise, you know,

we're going to have data centers, which are going to be large. You can't be expecting people to walk up to each server and log into it in a data center. They said, no, no, no, we got that problem solved. I said, okay, I didn't know that. How do you solve that problem? Remote desktop. Wait, but it's still, you connect to one of those machines, right? So yeah, you connect to, it's like, no, it's not going to work. This is a server. Another example was like somebody who's producing a service. And I said, okay, well, tell me about the service that you have for the server. And they're like, blah, blah. I said, okay, but how do you start it up? And they said, well, you start it up from the, you enter a command line to start up. I said, okay, but how do you start it up? And they said, well, you start it up from the, you enter a command line to start up. I said, okay, but how's the user going to do that?

They said, well, that's how they'll do it. I said, wait, so you're saying every time they start the system, someone has to log in, enter a command line to start your process? They said, yeah. Okay, that's not going to work. So, you know, just the whole sensibilities were off. The Microsoft team, for their part, considered Jeffrey old-fashioned, right? He was discussing how Unix and mainframe vendors were tackling issues. But the modern Microsoft way was a user interface for each problem.

So why not just do that? And the answer is that's not the model, right? It's a toolkit approach. It's the small tool approach, right? You have a tool chest of small tools, and then as unique problems come up, an admin will compose these tools in different arrangements to solve that novel problem, and then it goes away, and then you iterate, iterate, iterate. And so their mindset was, well, no, that's a bad idea because it requires a smart admin to do something.

Instead, tell us what the scenario is. We'll put it into our queue. We'll spend a couple of years developing it. Then we'll ship it as a new product. Then if and when they adopt the new product, problem solved. It's like, but immediately after you sell that product, the scenario changes. So we'll then tell us again and the next version will include it. It's like, you're just not getting it.

Jeffrey's initial solution for managing Windows was to use Windows services for Unix. This was something you could download, add to Windows and get a Unix shell and you'd have awk and grep and whatever else. And his theory was a skilled administrator could learn these tools and then use them to manage servers. Then, turns out, didn't solve any of the problems. And here's where I began to understand the true where you are versus where you want to be. There's a core architectural difference between Unix and Windows. Unix, everything is, it's a file-oriented operating system, okay? So everything, if you can manipulate a file and restart processes, you can manage everything, right?

That's why AuCREP-SED, those are managing tools because they manipulate files, okay? So then when I said, okay, great, take AuCREP-SED and a shell and all that and put it on Windows, happy days, right? No, because Windows is not a file and read-to-operating system. There are very few files in Windows. Instead, everything's behind an API, right? So, awk didn't work against the registry, sed didn't work against Active Directory, grep didn't work against WMI. Windows was all APIs that call and then you get structured data back. So none of that stuff worked. The only thing close to a solution was WMI, Windows Management Instrumentation,

and it allowed for some management tasks, but it was largely underused. Jeffrey's group saw this as an opportunity. They could develop command line tools to manage everything, user setups, network configuration, application installation, all using this WMI. I remember the meeting when I was there and I finally convinced my exec that, yes, this is what we had to do. And then she said, OK, get it. I totally get it. Which 10? I said, which 10 what? She said, well, which 10 command lines should we do?

I said, well, we need to do thousands. She said, yeah, yeah, yeah. But we're probably only going to get to 10 this release. So which 10 should we do? I was like, oh my God, we're doomed. Is there really thousands of APIs sitting in Windows? Was this Windows 2000 and Windows XP? Yeah, so it was XP and beyond.

Yeah. Yeah. Pulled that number out of my ear. But yeah, probably. You know, it depends on what you call a command. Yeah, you need like lots of commands focused in on the objects in WMI. That's why you probably need thousands. Okay, so then the next step was, okay, hey, I need more than 10. I was able to secure funding to get contract engineers to do this. The existing engineers are like, well, the command lines, they're beneath me. You know, you're off talking about this crap, but nobody cares about it. You're wrong.

And I'm not going to waste my career, you know, spending time on this shit. But Jeffrey still had this vision clear in his mind, right? It was the reason he came to Microsoft. Enable a system administrator to script and manage hundreds of headless Windows servers in a data center. And Windows 2000 had just shipped, so there was an opportunity to integrate some of these commands into Windows XP. And they're like, yeah, but the coding window is 10 weeks.

10 weeks? F me, what the hell are you talking about? 10 weeks? What can you do in 10 weeks? Oh, we can do a lot in 10 weeks. I don't think so. Obviously, I misunderstood something. I'll have to wait till my next window of opportunity to figure things out and do something. Well, it turned out when they said, oh, our coding window is 10 weeks. What they were doing was they're just writing code for 10 weeks. And some of that code would be like a function, a comment, fill in this function, check it in. And then, so you have 10 weeks worth of that. Then nothing works after those 10 weeks, nothing. And then they spend like a couple of years making it work. Like,

what the hell is that? Yeah. Why did they just check in like a stub of a function? Like what's the... Oh, because after 10 weeks, you couldn't do anything new. But you couldn't fix the bug. The bug is, doesn't work. I mean, how crazy is that? So Jeffrey's group pays contractors to write these command line interfaces that use WMI. They managed to implement 70 actions, but really that was barely making a dent in the needs of administering

Windows servers. It was a start though, right? So they decided to seek more funding and continue this work. So now let's bring in another weird aspect of Microsoft. Nothing goes out the door unless the test organization signs off on it. Okay, great. And I will tell you that there's an incredible, there are mountains, mountains of awesome features in a dustbin, Microsoft dustbins, because they developed this stuff and didn't have the test organization's bandwidth to sign off on it. And I had some issues with them signing off on the 70 commands that I had done, but I got that, right? Because we spent a lot of money on this. It's like, you were going to find a way to freaking sign off on these things. It's like, okay, but if I do this again, this is going to be a problem.

So what I said was, hey, think about HTML, right? You test the browser, but then you don't have the test organization that owns the test browser. They don't test every HTML page. This is clever. Instead of writing code for each command, you know, you have a format for setting up a command, describe it in XML or whatever config format, how each command works. And then you make this generic command builder. And the organizational trick is saying, hey, any specific commands config is just metadata. No need to test them.

Just test the tool. And bam, the testing organization's bottleneck and the process has been sidestepped. People fought me against that. Like, that's a stupid idea. You know, it's going to take forever. Nobody, they just didn't see it. It's like, okay, and here's one of the life lessons. Every now and again, you just need to know when to be a butthead.

So this was one of those moments, right? If you're always a butthead, you're never going to get very far. But if you're never a butthead, it probably means that you're not taking enough courageous changes and driving a reticent organization where it needs to be. So this was definitely one of those times. They did not want to go down this path, but I was just adamant. It's like, no, we must do this. Jeffrey won the battle for his metadata-driven solution. And over his Christmas vacation, he diligently produced metadata and he got done 72 commands.

I was like, oh my God, you know, I just spent basically $4 million and a long time to get these 70 commands. I spent, I forget what it was. It was like $60,000 to get this engine. And then I spent my Christmas vacation and I got more commands than them. It's like, wow, this is gold. This is good stuff.

And then I said, hey, you know what? That engine is missing a number of features. Can I get some more money to improve it? And I said, yeah, yeah, I can. And so we did that and we added a bunch of features like filtering, formatting, et cetera. And here's where the magic happened. We added it to the engine and all 72 of those commands got better. I was like, oh, this is gold. This is gold. And what I had discovered was, hey, with my architecture, I have a base investment. And then the incremental cost to write these things is really, really small.

It's really flat. Incremental cost to add new function. And I can invest in the engine and the value goes up. The functionality goes up for everything. So I can invest in the engine and the value goes up, the functionality goes up for everything. So I get better economics, I get consistency, I get uniformity. I mean, just win, win, win. Now these commands aren't PowerShell, right? This is WMIC, an earlier solution. But if you're familiar with PowerShell, this might seem familiar, right? It's generic. It's data-driven.

Things are coming together. But still, the problem of getting coverage for everything in Windows is an issue. And at this point, Bill Gates and.NET enter the picture. Bill's an interesting guy, more of a business guy than a technology guy, in my opinion. Technology, he's got opinions, et cetera. But when it comes to business, guy's freaking genius. And so here was the challenge. We had shipped XP. XP was an excellent operating system. Excellent operating system, right? We got rid of the crap old sort of handcrafted kernel, brought in Dave Cutler, god of operating systems. We had the NT kernel now available for everybody. So we had this awesome operating system and we couldn't get anybody to use it.

They were all stuck on Windows 98. Windows 98 was demonstrably unfit for purpose and we couldn't get people off of it onto XP. What Bill had figured out is that if people won't get off Windows 98 for something good like XP, then once they get on XP, how will we ever get them to upgrade? And so he realized that he had a severe business problem. And so he said, here's the way we're going to solve this business problem.

We're going to draw a line in the sand and we're going to engineer a Windows 95 moment, right? A Windows 95 moment when the world changed. It was the world before Windows 95 and then there's the world after Windows 95. And this new moment is going to be called Longhorn and it was going to have a new way to do develop code.net. It was going to have a new graphics model, WPF.

It's going to have a new graphics model, WPF. It's got a new communications model, WCF. And it's going to have a new storage model. Just a whole new way, just a complete generation shift. And no one was going to be allowed to invest in anything that wasn't this. So I'm going to engineer this moment and transform the industry. It's actually brilliant thinking. Didn't work, but brilliant thinking. Now, Bill is a business genius. Yes. But by this time, Jeffrey also knew Bill was a force of nature. Bill was famous for his Bill G reviews, where executives would pile into a boardroom and give him status updates on various projects.

So I remember one, it was so bad. It was so bad. It was so bad. So we had been beaten up, beat up, beaten up. And then this one time, we were going to have three topics. The first guy, he's going to come in and do exactly what Bill told him not to do in the last meeting. The second guy who's coming in has made no progress since our last Bill meeting. It's like, oh my God, we're going to get killed.

And then the third guy has a new top. Talk about diagnostics. And it's like, okay, well, that's actually some pretty good stuff. So we're in good shape here. Anyway, so our exec was out that day. She was sick or something. And so we go in and it's like, hey, well, it's just us. It's like, this is going to be bad.

First guy talks. What guy who did exactly what Bill told him not to do. And Bill's all smiles. Like the hell? That's weird. Second guy, okay, here's where it's going. Brace for impact. This guy's going to get it. Goes through it. Bill smiles. Oh, this is great. Fantastic. Great progress. All this. I'm thinking, oh, you know what? He hates our exec. That's what it is. Turns out that's not what it was. What happened was, was that that morning, just before that meeting, he, as part of his other work, he had acquired a bunch of patents for malarial treatments.

And so he was riding high on that. Anyway, we didn't know that. So we're just thinking, what the hell? Then Jeffrey's up. He's covering changes to diagnostics for a person that's out. It's not his area, but the changes that are being covered make a lot of sense to him. I start to present. Like the first slide, Bill's face changes like a bad Mexican meal just hit his intestines.

And it's just a matter of like minutes before he's losing it, right? And he's screaming at me. You fucked him. You fucked him. You fucked him. You fucked him. Spit. I'm not making this up. Spit is coming across the conference room table and landing on my glasses as he's like, you fucked him. I have no idea what the hell he's talking about, but he's so, and it's like, wow, wow, what? This other execs on the other side of the table is like, Bill, Bill, Bill, Jeffrey didn't fuck those people. I fucked those people. I'm like, what the hell is going on? And so I just keep trying to try to go on. And what had happened was he got very excited about the diagnostics in the past. And somebody

had convinced him, oh, the key to diagnostics are these Bayesian networks, blah, blah, blah. And so they had these things, these Bayesian troubleshooters, and they shipped them in Windows. Bill just loved it, right? AI. He loved these things.

The problem is these things didn't work. And even getting them translated into all the various languages that Windows supports was going to cost a lot of money. And so the decision was made to just stop shipping them. Bill thinks, oh, you guys fucked my favorite Bayesian network diagnostics people. So that's why he was screaming at me. And I was like, okay, well, can we get beyond that and just talk about this?

The answer was no, but he didn't say no. And so I felt it was my responsibility, like, hey, I got to speak truth to power here. So let me just break it down. Bunk, bunk, bunk, bunk, bunk. Beat the crap out of me. People are like, oh my God, you were like a fricking Weeble. He'd knock you down. You just get back up. He says, we were looking for a towel to throw. It was so bad. And it really was. It really was. So at the end of that meeting, right, concludes, didn't conclude well. I ran out of that conference room and ran to the men's room because I thought I was going to puke. I just hovered over the toilet for like a while. It was

bad. It was really bad. I mean, no joke. So Jeffrey made it through that tough review, but then he realized from these other Bill G meetings that Bill was really pushing everyone towards.NET, aiming to shape that specific outcome. Because that was when he was beating us up,.NET,.NET,.NET. And I was like, man, that's just not going to help me. Okay, well, let's find out what he's talking about. So that's where I began to say, ah, this can help me. Bill's going to go get everybody to give me coverage because I can't get anybody to give me this WMI coverage because I did not generate that loop where everybody said, oh, I can't wait to write a WMI provider. I get so much value from it. So it wasn't getting coverage there, but he was going to get me coverage for.NET.

And so then all I had to do was to write the utilities on top of it. That's how I got down that path..NET was using Bill's anger to get you leverage. Exactly. The Bill Bully puppet. This.NET insight gave Jeffrey an even stronger plausible theory of success. But of course, things wouldn't stand still while he tried to execute on that. Because at the same time, his org's leadership was struggling to figure out priorities. Windows Server kept saying, hey, I need you to do X, Y, and Z. I'm willing to work with you, I understand what you're doing, but I need the following things. And they weren't getting what they needed from the organization.

The exec's like, nope, I'm going to do this. I'm not going to play ball. And then one day she woke up and half her organization was gone and it was moved to windows server and so then will remain went into crisis dysfunction etc and so because of that because of my role right i've been in this role of like okay figuring out figuring out the products, et cetera. And that's effectively stopped, right? Stop having staff meetings. There's no all hands. There was no message. I mean, you just went into complete dysfunction. It's like, oh, fuck, what do I do? What do I do? That's like, okay, well, this isn't going to last for long, right? Something's got to change here, but I got nothing to do.

There are many ways to handle a reorg. One option might be to reconnect with the Windows server group and try to focus on this broader goal of helping them understand the data center and the enterprise. But despite his organization virtually disappearing, Jeffrey stuck to his plan. It was still plausible and he was excited about its potential. But how could he keep it moving? Turned out there was another group

or in some other organization that were producing a shell. And so I said, hey, you guys, let me tell you how the right way to do a shell, right? Here's how you should do it. And they're like, I don't know what you're talking about. We're just going to take K-shell and port it. I said, yeah, but we should do better.

Like, you're going to run to the problem I ran into when I did the first thing. You're going to have a shell and then nothing's going to talk to it. So you're not going to move the ball forward. And so I tried to explain to try and explain it. They didn't get it. And so as much as I tried to explain the ideas, they didn't get it. I said, you know, just go away. And I'm going to lock myself in a room and then produce the prototype of what became PowerShell. And so I produced basically a 10,000 line demo prototype of this that had all of the core architectural principles of PowerShell.

And I invited them back. I said, let me show you something. And I was able to show them. And they said, but what about this? And I showed them. And they said, what about that? And I showed them. And I said, what about this?

And I showed them. And their eyes just got big. And they're like, this, this, this. I said, okay, great, go do this. And then eventually they were going to go do that. And I helped them get funding. And then I realized like, man, this is probably the best idea I've ever had in my life. I should go work on this. Getting himself on that project though, that wasn't easy. It's like, hey, Jeffrey, wait a second. We hired you in as this industry expert. You're the chief architect for our products and our services, varied from like 700 to, you know, 1200 people. And now you're going to want to go work on something that's got a team

of like a couple people. And I said, yeah, but we need to fund it to more. I said, okay, but it's a couple people and it doesn't matter. It's a command line interface. It's like, but this is important. Like it's a command line interface. And I said, well, I know I want to work with this. And basically the answer was, well, okay, well, we'll let you work on it, but you know, you can't keep that job and we're going to take that away from you. And so, yeah, so I got demoted. It was really painful actually. So I didn't, you know, I didn't tell any of my friends. I didn't tell any of my family. It just was so painful.

Obviously, I had to tell my wife because it had a big economic effect on us. And because my focus was on having an impact on the world, that was far more valuable than, you know, a title, far more valuable than, you know, money, et cetera. I said, hey, you know, I think I can change the world with this thing. And okay, I got demoted. That sucks. Could cost me a lot of money. That sucks.

But if I can pull this off and get it in Windows, man, I could affect the lives of many millions of people. Jeffrey's new team named their project Monad and lacking staff, they outsourced some of the work to India. And so to align everyone with the project's vision and this plausible path to success, Jeffrey created the Monad Manifesto. And although the collaboration with the India team eventually dissolved, this document became a cornerstone of the project. Basically, I laid out the argument in very clear notion,

like, hey, what is the problem? What is the traditional approach? What is our new approach? Why is this valuable? How does it differ from other things? And then at the end, I had this concrete Jeffrey Moore market relevance statements, which I found to just be incredibly hard to do. But then once you have it, it provides incredible clarity about what you are, what's important,

and what you must achieve and where it's okay to not achieve things. And it basically takes the format of for user who qualifier, offering value proposition. Unlike alternative, offering differentiator. And then repeat, repeat, repeat. For admins who need to manage Windows Server, PowerShell provides a comprehensive, coherent, composable management solution. Unlike command.exe, PowerShell provides a common parser, PowerShell provides consistent formatting, PowerShell provides a pipeline, blah, blah,

blah, more details and all that. Unlike Unix shells, PowerShell, and then for users, for providers, for development teams. One thing Jeffrey did was outline all the stakeholders for this project and how it would benefit them. Because this whole thing had a huge bootstrapping problem. You know, at Microsoft, everybody's hair's on fire and they have 10 jobs and they get to decide which nine they're going to fail and not get fired, right? And the command line interface is something that not doing it would not get you fired and doing it wasn't going to get you promoted. So it was like, okay, but my success depends on all of those teams giving me coverage. Like, how's that going to work? So I had to articulate that I'm going to knock on their door and ask them for the code that they and only they could write

and only that code. And I'll provide all the rest of the code. I provide the formatting. I provide the sorting. I provide the filtering. I provide the parser. I provide the remoting. I provide the, you know, elevated privilege. I provide all of that. You don't need to do all that, any of that. You just need to tell me how to manipulate your objects, okay? And then you don't have to test all that. Like, I test all that. With the MoDev manifesto as his clearly articulated theory of success, Jeffrey now just needed to make it happen. Convincing the product teams was crucial,

and so he met with the Active Directory group and attempted to win them over. Knock on people's door, they're like, you know, you're one of the nine that I can fail and not do something. It's like, yeah, but come on. And at that point, you have a little bit of personal credibility and you get people to try something. Like, can you just like have some people do this? Because I think you're going to find it's easy, you know, get people to spend a couple of weeks on it. I'm trying to remember who had the weight with who, but we got them to spend a couple of weeks on it. I'm trying to remember who had the weight with who, but we got them to invest a couple of weeks of somebody's work. And we worked with them and they were able to develop a couple of commandlets. And then they had user groups,

continually talking to the users, et cetera. And they showed it to them and they just got such a strong reaction that there's like, oh, okay. And then the customer reaction, like, oh my God, my engineers tell me this is good. We should do it. So let's do it. And so now a rational product owner looks at this and said, okay, that's a good deal. Let's finish that work. I liked how little it cost me and I liked the reaction of my customers. So let's do it. And then they helped get the next one, which helped get the next one. At this point, the capabilities of PowerShell were expanding. And although there was a big bump in the road still coming, the Shell team was very busy building things out. We would be in somebody's

office at a whiteboard, like brainstorming. There's a group of us and just like drawing pictures and what about this? And always challenging herself, like go big, go big. Like don't go for the easy solution. What's the bigger answer? When somebody had done something and everybody rushed to their office to see what they had just done. We realized at some point like, oh yeah, this is familiar. Computing used to be fun. And then it sort of wasn't fun anymore. But this is fun again. And as I thought about that, I realized that the mouse is antisocial. The GUI is antisocial. So what's that mean? You have a problem to solve and you solve it with the GUI. What do you have?

Problem solved. But when you solve it with a command line interface in a scripting environment, you have an artifact. And all of a sudden, that artifact can be shared with someone. By the way, the way you did it can show cleverness. I've never seen anybody use a GUI in a clever way, ever. There's no cleverness to it. No, like, oh, my God, you should see the way Adam clicked that mouse. Oh, my God.

Guys, guys, guys, guys, come on. Check it out. Adam's going to click the button. Oh, my God. That's amazing. It just doesn't happen. But with scripting, you're using a language, right? You're communicating. It's like, oh my God, did you see what Bruce did? That's phenomenal. This guy's a freaking genius. And then, hey, give that to me. I'm going to steal that technique and apply it to my code. Or then I have this artifact and I publish it and people are using it. There's a debt of gratitude. Like they owe me a beer, right?

Or they'll come back and they say, hey, Jeffrey, why did you do it this way? Why didn't you do it that way? It's like, oh, my God, that's a better way to do it. Thank you. And so it's a social environment. Anyway, it really was this moment like, man, we are having a blast. Like, and it hasn't been that way in years. For Jeffrey, this made the demotion feel worthwhile, right? It gave him a sense that there was potential impact here.

For many at Microsoft, a Porsche or a promotion or the total compensation package were the important rewards. But Jeffrey was measuring things differently. The art of it is that I'm an existentialist. Okay, so what's that mean? That means I don't believe in a life after this. I don't believe in any grand narrative. I don't believe any of that. I believe life is what you decide to make of it. And that caused a lot of, like when I went through that, kind of discarding

of comfortable beliefs and embracing of this. That was a very difficult period. But then after that, I said, okay, well, then what do I want to make of this? And it really came down to, I've got a certain number of amount of time and I want the world to be different and hopefully better because I existed. It's that simple. So it's really about having impact and mattering that made me say, yeah, I want to do this. And with that conviction, PowerShell looked like it just might happen. After all, it's attached to this great new.NET operating system initiative, Longhorn. So then began the buforama, right? A bunch of engineers making terrible decisions about how and where to adopt.NET. And the reality was many of these technologies, like, hey, if you had done it over the course of, you know, five to seven years, the brilliant idea. They were like, no, no, we just know, we just know. You set a deadline and our engineers will rise to the moment. They'll sleep here nights, weekends, they'll get divorced, but the hell with that. They'll be making enough money. They can afford a new family. I'm not making this up, but people will rise to the occasion. And when they tell us

it's not working, we'll say, make it work. And they'll do it because they have. They're a really amazing group of people until they weren't. And it didn't work this time. And they couldn't force people. And they couldn't force reality. They couldn't make it work. Take a notepad, for example. It was native code and just used around 15 kilobytes of memory. Well, somebody got the idea that said, hey, you know what? One way to make sure everybody's using.NET is I'll rewrite the common control dialog boxes using it. You know, use.NET and the WCF. So now all of a sudden, I got this native code notepad. I bring it up, starts instantaneously.

Everything's fast, fast, fast. And then I say save as. And the dialog box comes up a minute and a half later. And I go from this 15 kilobyte working set to a 15 megabyte working set. And then I can save my file. Terrible idea. Terrible idea. Other people were looking to figure out, hey, how can I get.NET in the kernel? I think I got to some point, I won't remember the details, but it had been like maybe seven months that the nightly builds didn't work. And so there had been this, okay, no new code, only code to fix the builds and make things work.

And then that wasn't working. So it basically had to do a reset. So the Windows people decided that.NET was the problem, when perhaps they had just bitten off more than they could chew. But PowerShell got pulled out of Windows like all the.NET code during this reset. And now Jeffrey has to find a way back in. So that began like a multi-year just hell as they began to really come after command line interfaces, anything that do with .NET. So they just like on a regular basis would come at us and try and get us canceled. First, Bill Gates always got it. Bill Gates got it. That helped me exactly zero. Helped me not one bit, right? Then I had the head of Windows server. He got it. He had like crucial moments,

right? There were crucial moments, but like the day-to-day stuff, you know, it just felt it was a very hostile environment, a very unwelcoming environment. Lots of people throwing rocks at us and we were just trying to go underneath the covers and get our job done. Doing the actual building was actually going really well. I mean, it was just so delightful. We would run into each other's office like, hey, have you seen what Bruce just did? And we all run into Bruce's office and we'd see something did like our heads would explode like, oh my God, that's fantastic. And oh, hey, I heard Jim's doing something. We all run into Jim's office and he'd do something. And you just see it coming together. And there was a reality to it that made you say, hey, all these people

are throwing rocks. They don't know what the fun they're talking about. They're wrong. This is awesome. And we're going to ship this thing. I had partnered with Exchange and they were a deep customer. So when they had this meeting, like, okay, let's kill them this time.

And I just bring my Exchange guys there and they just sit in the corner and a meeting. Okay, so we've agreed. We need to kill this Monad thing. The exchange guys would then perk up and said, no, I have a multi-billion dollar business. I'm betting on this. I need this. You can't kill it. Even though the project survived, it had funding. It was still not part of Windows. It needed a way to get back in. Winarch, Winarch is Windows Architects, they got together and said, okay, here are the seven things you have to do

to get.NET into Windows. And these were like incredible draconian set of things that, you know, some of them were based in good things, but they were just phrased in a way that was very clear, like, no. Yeah, we're going to keep.NET out of this. So again, everybody looked at that thing and everyone bailed except for two people, Scott Guthrie and myself. He cheated.

He shipped outside of Windows. I tried to figure out how to get back in. So what's the process to get into Windows. Like, is it? Yeah. Well, you have to have a formal design change process, right? What I said was they're going to go out of their way to find any, you know, weakness in our argument. So we can't be green. We got to be greener than green. And so we did that for everything, everything, everything. Finally got our story together and we said, okay, we've sent the request. Like 20 minutes later, the executive sends back mail saying, withdraw this request, the head of Windows. Withdraw this request. And so my program manager, Jeffrey, come here. Now, look at this mail I just got from Brian. Like, oh my God, what should I do? He said,

I don't know. He said, I know what I'll do. His response, he says, no. He says, you turn it down. And so he says, okay, fine. I turn it down. Turning things down formally, it triggered a review process. This process involved the Windows Server organization the group Jeffrey was originally supposed to work for. And the head of Windows Server had dialed in that this was critical to his business.

And so he was a supporter, and he basically said, hey, this is critical to my business. I own this decision. If it meets the requirements, it's going in. And it did meet all the requirements. And so then there's this big battle between the executives. It was actually messy. But ultimately, the Windows Server executive prevailed and we were able to get back in. So they shipped it. PowerShell 1 was released as part of Windows Vista. But for

Jeffrey and his team, the work wasn't done. Even before it shipped to version 1, people like, my manager's like, hey, what's the next thing you're going to do? It's like, I'm going to ship this. But after you ship it, what are you going to do after that? And it's, well, it's not done. I got to do the next version. I'm like, no, no, you're a senior guy. You need to do something else. Otherwise, you're going to get pigeonholed.

And it's like, no, I'm going to do this. And it's like, well, it's going to hurt your career. It's like, whatever. And so then that happened with version two. And then it happened with version three. And then it happened with version four. Each version, each release was executing towards the end goal of successful server administration that Jeffrey had laid out in his manifesto.

Version 1, we got this far. Version 2, we filled out these things. Version 3, these things. Version 4 pretty much came to completion of the vision. So, you know, it just took that long to do. So that was me personally. And again, being warned all the time, hey, this is going to affect you financially,

it's going to affect your career, et cetera. I was like, yeah, I don't care. I'm just going to do this, man. It's the right thing to do. And eventually it worked out okay for me. That sustained focus paid off. For those who invested in PowerShell, their skills grew more valuable over time.

Instead of frequent disruptive changes, the core ideas remained consistent For those who invested in PowerShell, their skills grew more valuable over time. Instead of frequent disruptive changes, the core ideas remained consistent, and each release made their skills more valuable. And big picture, what's truly fascinating is how PowerShell bridged this gap between the administrator and the programming world. Windows administrators who never saw themselves as coders were suddenly writing scripts and automating complex tasks. And PowerShell created this whole community of people helping each other out.

Server admins forming PowerShell user groups. People were sharing scripts back and forth. They're answering questions online. Conferences were coming together. Yeah, they become a hero. They're asked to talk at conferences. A number of people have become professional speakers because of this. It's amazing.

One woman, though, she was so nervous about presenting at a conference. She's in the speaker room doing shots. Like, what are you doing? I can't cope. She goes up there and she just nailed it. She was fantastic. And then she's at all the circuits, just giving talks all the time now. And so she's a pro.

Yeah, transformed her career. For Jeffrey, the success of PowerShell, it did diminish the sting of his demotion. But really, the true impact of this work, of this effort, is that Windows Server Administration changed. And that change to how Windows is administered actually enabled a lot. So it took me five years, but I finally got my stripes back,

became Distinguished Engineer, and then eventually Technical Fellow. At some point, I went to work in Office. And the head of the office, and we were having lunch, and he said, you know, you realize that PowerShell is the reason why Microsoft's in the cloud. What? How's that? He says, well, Office led the way to the cloud. Like we were, you know, many years ahead of Azure. And he said, we never would have been able to get to the cloud without PowerShell. He said, before that, when I went to provision a server, it's click, click, click, click, click. And you couldn't do that multiple times. And then when you got it wrong, you couldn't fix it. So having scripts allowed us to scale up.

When something went wrong, we changed the script. And he says that enabled us to get to the cloud. And Office going to the cloud enabled Azure to go to the cloud. That was the show. Jeffrey, thank you so much for candidly sharing your story. I hope I did a good job of presenting it because it's an amazing one. I learned so much from you about the importance of a clear strategy for success and the need to stay focused on these long-term goals despite the daily challenges thrown your way.

You know, sometimes you have to be willing to take the demotion or face the criticism to keep your eye on that long-term prize. And listeners, yeah, Jeffrey is very active on Twitter at jsnover, and he's now working in the SRE group at Google. So give him a follow. If you've got a PowerShell story of your own or more relevant, if you've faced similar organizational challenges driving change, if you have a story to tell, I'd love to hear about it. Or let me know what you think of this episode. You can reach out to me on Twitter at Adam Gordon Bell

or email me adam at corecursive.com or join the Slack and tell me about it there or whatever. You can find me lots of places. And until next time, thank you so much for listening.