 All right, like any good story about Illinois, this one starts in Peoria, because that's where I lived. When I first got out of school, I worked for a company that was in Peoria. I'm not gonna tell you who it was, but there's only one reason to live in Peoria. And I was there doing system administration. And what I found was doing AIX and doing Red Hat Linux work was really great and I enjoyed it, but I actually enjoyed making system administrators better more than I enjoyed doing the system administration work itself. I went to Caterpillar Financial in Tennessee after that, Go Predators. And then I decided that I was gonna work more on the people side of things. I wanted to make system administrators better. But the thing was when I was doing that, I didn't wanna not do technology. I wanted to understand the work that everybody was doing. And so I was like, well, why do I keep getting asked this question of, Mike, what do you wanna do? Do you wanna go into management or do you wanna be technical? And I was like, this is a dumb question. Like, why can't I do both? There are people that are good at multiple things all the time, why can't I be one of them? Now the management model that some companies is that people are interchangeable. They're like caps on a pen, you can just take off one and put it on a different pen, put it on a different pen, put it on a different pen. I can manage ERP, I can manage database, I could go manage web servers or whatever and then assembly lines. And I was like, this is not what I wanna do. This doesn't work for me. So I left and went to Puppet. I moved to Portland. This is the third state we're in already if you haven't been paying attention. So I was, I went to Portland. Went from a company of 100,000 people to a company of 35 people. Got a few changes there. When I got there, I said, hey, I want to do a bunch of technical stuff. I wanna make commits, but I also wanna leave people. And they were like, great, we don't have managers, really? Let's try that. And I said, cool, I'm gonna be a manager. I can take down the system from the inside because I understand how people work and do this job. I wanted to make sure that we were not passing the buck, that we were not, you know, blame storming regularly, that the AV worked properly. Anyway, I'll just keep going. So I'm Mike Stonkey. I work at Puppet. I'm a director of engineering there. Let's see, I helped organize DevOps Days Madison, which is October 30th and 31st. You should all come. And then for software, what I really like are the parts of software that are around operational side. So I like pipelines, packaging, building, compilers, you can finally mess in with GCC while I watch hockey games. It's things I do. I also like growing teams. One of my favorite things to do is mentor teams or grow teams. My team was one when I got to Puppet. That team now is around 38 people-ish, so it's grown a little bit. And so I kept getting asked though, this management or technical, well, why don't we have both? And so I kind of have done both for about six years at Puppet. And I've learned a few things. I've made mistakes and I'm still not perfect at it. And some people will say you need to pick one and I usually tell them no. But one of the first things you should do is automate your management. And what is management? It's saying what you're gonna do and then doing what you said. That's all management is. Just expectation management. So I have a blog post that's called Working For Me and it tells you how I like to operate. It helps. If I have to make a choice between technical stuff and people stuff, people stuff has to come first 100% of the time. The computer will wait. It actually no-ops pretty well. People don't. So you have to think about that as you're working with humans. Priorities and context are really what my job is. As a manager, after I've set expectations, I have to make sure everybody understands why they're working on what they're working on. If they can't understand that, then I haven't done my job. They should stop at any time and ask me why they're working on what they're working on because if I don't know, I don't understand their job. So computers do exactly what you tell them. Humans, not so much. And so when I get frustrated with that, I go back to the command line because computers do exactly what I tell them. So kind of as a refresher or recharge for me, I might start slinging some code. I usually work on a chat bot, not anything that important anymore, but it's still pretty nice for me. When I'm doing technical work, I have to keep in mind that I should check my title at the door. I'm a director of engineering. I don't have better ideas than the engineers that work under me. I need to know that, and I do remember that and have to remind myself of that quite often. I also need to not put myself on critical path. If we're gonna shift next week, I should not say I'm gonna sign up and fix these three or four bugs because I don't know if I'm actually gonna have time to do that because I work with humans who, like I said, don't know off all that well and sometimes I need to take care of what they're doing. And then I also get asked the question of what is technical work? And this keeps coming up in my brain. If I'm planning when we're gonna ship something or what the work process looks like or what the flow looks like, like is that technical work? Is that management work? I don't even know. And frankly, most of the time I don't care. It just needs to get done and so I'm gonna take care of it. I wanna provide a career path for people because I understand technical work and I want career paths that are both, I wanna go into management and I don't wanna go into management. No one ever says I wanna be an IC when I grow up. Now the last thing that I've really gotten to do as a manager who is technical is I get to foster the culture that I want. This is one of the best parts of being in leadership is you can kind of say, here's the culture that we wanna reward, here's the things we like. And so I try and do that as I'm working with folks because I've actually done a lot of that technical work and hopefully can understand it and work with them. Thank you.