 So, thanks for having me back Seattle. My name is Scott Nassau and I'm excited to talk to you about our experiences within the Microsoft Enterprise. The past few months have reinforced the importance of a learning organization and growth mindset in our journey. So, this talk has changed a little bit from how it was originally intended. So, we're going to focus on growth mindset, learning organization while honoring the experience of individual contributors. One of the things that we asked our engineers is, tell us about the journey that you've been on for the last couple of years. By far, my favorite submission, it's really like that vacation your mom planned to take you and a couple of friends to the amusement park, a short five hour drive away on the hottest August day of the summer. That's the trip you learned that one of your neighbor friends is really weird. Someone ate too much junk food and is inevitably going to throw up in the car and everybody else is going to throw up too. Your mom is going to power you through it and family trucks will take some messy hits. But you're glad you didn't miss the opportunity to hit the park and now you know how weird your neighbor is. And as long as you have that car, you will know where to look to see those stains that remind you of the trip. All of us have challenges within our organization. A typical organization probably has normal rational hesitation to change. You probably have functional silo problems or organizational alignment. And then just typical challenges of lean agile DevOps. The Microsoft organization has a few other challenges. So Microsoft has changed quite a bit over the last few years under Satya's leadership. Exhibit A, PowerShell, Azure, et cetera, but the residue that remains in your organization is probably due to monolithic tools, a culture of screenshots, and clicking next. Also closed-sourced, undocumented APIs and other friction. Reliance on vendors for direction, road mapping, and training. And then finally, silos that have been encouraged themselves by Microsoft. Some organizations choose to buy more of their capabilities versus build them. And you're going to have other challenges such as limited engineering tradition. If you're buying commercial off-the-shelf applications, they largely are not documented. They're black box applications and there's no how to manual for how to automate those. So at Columbia, we have all of these challenges. But the core challenge in my mind is how do you do DevOps if you don't have a learning organization and if you don't have a commitment to learning? So we're going to look at this a little bit. A learning organization is an organization skilled at creating, acquiring, and transferring knowledge and it modifying its behavior to reflect new knowledge and insights. So if you want to do the DevOps and you don't have a learning organization, what do you do? Maybe it's enough just to tell everybody, hey, go have a growth mindset. I think that's a bit short-sighted. So as I mentioned at the beginning of the talk, we asked the engineers at Columbia Five primary questions, describe the journey that you've been on, what's been your favorite and least favorite aspect of the journey? What advice would you tell 2015 yourself about this journey that you're about to go on? And what are you most anticipating over the next couple of years? It's been rewarding, bumpy, and lots of self-doubt. I definitely felt like an imposter. So throughout the submissions, you see a lot of imposter syndrome. It's a real thing, especially in a Microsoft-centric enterprise. Eventually, I felt like I could grow and contribute. The team is growing quite a bit and can regress the old ideas and mindsets. I learned quite a bit about dealing with folks I don't agree with. So as you start to work differently in your organization, more cross-functionally, as you start to flatten silos, et cetera, you're going to have more disagreements. They could be personality-based. They could be philosophy-based. They could just be style-based. So the bottom line, getting good at being able to respectfully disagree is important. It's been hard to ramp up due to the slew of tools, behaviors, and new ways of thinking. In the open-source and Linux worlds, we take it for granted, loosely-coupled tool sets. The Microsoft world, monolithic, all-you-can-eat, one-size-fits-all tools that do everything. So weaning ourselves off of that thing onto this other thing has been very difficult and that's what this comment is alluding to. It's been your favorite aspect of the journey. I've enjoyed expanding my sphere of responsibilities and interests by breaking down IT silos. The variety and level of activity within the team has been rejuvenating. I enjoy being on the leading edge of enterprise IT. DevOps is certainly not new for Unicorns, but it's still in the beginning stages in the Microsoft-centric enterprise. The encouragement to experiment or fail without the possibility of punishment, especially with chat ops. And then one of my favorites here, it's been about people, teammates, mentorship, learning to ask for help, and developing confidence. So imagine if you have that imposter syndrome and you don't feel like you really belong. Pretty hard to ask for help, right? So let's honor some reality here. Let's talk about some of the least favorite aspects of the journey. Constant change. All the experiments. Not enough time to go deep. Imposter syndrome again. Feeling lost, helpless. Discomfort due to the width and breadth of the areas. Lack of prioritization across projects. Maintenance and support. So we've layered on new behaviors, new attitudes, new practices, new tool sets. We also have all the same stuff that we had before. So that becomes a very difficult minefield for your engineers to navigate. What advice would you give your 2015 self about the journey you're about to go on? This is by the same person that did our opening quote, by the way. Over the next two years, you're going to have to disappoint someone. It could be your manager, it could be the business, it could be your teammates, it could be your family, it could even be yourself. You're already at 100% and changing the way you work will seem like adding another 30% of work. Choose wisely who you disappoint and remember that you're not in this transformation alone. Spend some time assisting the business units you support to be more self-sufficient. Give them the tools and rights to help themselves so that you can focus on the true elements of infrastructure. The near future and speed of infrastructure isn't going to allow itself to be built and maintained by Microsoft wizards. Those wizards that simplify the process and guide you through the whole procedure in terms of how to implement something. Even Microsoft is changing its tool sets in response to the reinvention of IT infrastructure. And if you have any doubts, review what the sessions are and Microsoft ignite these days. Don't be overwhelmed by DevOps nirvana. Try to stay focused on incremental improvements. Each improvement is like a savings deposit that will compound over time. That's a pretty powerful idea. When we start to think about small changes, they start to accumulate and they snowball and they add up to bigger capabilities. Prepare for a lot of change. Be willing to embrace the change. Reflect on why you do things. Is it still valid? Was it ever valid? One of my favorite stories over our last two years, two engineers have sat together for lots of years. They couldn't believe that each one had been building servers differently all these years. And it wasn't until we really started to dissect what we're doing and trying to automate that they say, you do it like that? Well, I do it like this other thing. So not having uniformity, not having standardization. Your existing skills will become obsolete and your expertise is at risk. Find new ways to get started on those new ideas. What are you most eagerly anticipating over the next couple of years? Public Cloud, Chef, and Automation. This is a pretty significant departure from where the team started two years ago. We were afraid of all things public cloud. We were afraid of automation. We were afraid that automation was going to take our jobs away, right? So radically different mindset in the team over the last couple of years. As we talk to the various engineers, we ask them three other questions. Tell us about your career progression. Tell us about your educational background and tell us about any vendor certifications you have. So the observation from all those questions, many veteran IT pros, so those are your Windows admins, started their career in help desk. They advanced to the ranks and they likely bypass college. Certainly not the only pattern you'll find in your organization, but it's definitely something you need to kind of think about in terms of structuring activities and your transformational journey. So let's come back to the question. You want to do the DevOps and you don't have a learning organization. What do you do? Years ago, I was a camp counselor. During my end of summer briefing with the camp director, he said, there's something I want you to work on over the year. I said, what's that? He said, I want you to be more mindful of your learning opportunities that you're working with with kids. I'm like, okay, I get that. He said, no, really, I want you to really embrace that. And then he gave me an example. He said, when you're on the archery range and you're teaching the kid to address the target and breathe and everything else. He said, do you know what you're really teaching? I said, what's that? He said, you're teaching that kid to self-regulate. Emotions, behaviors, body. You're teaching them something that is transferable outside of the realm of archery. I said, okay. He gave me another example. And he said, when you're pitching in baseball or whatever, you want to put the ball where the bat's going to be. You want the kid to taste success. You want to give them a desire to do more. So the question for all of us, are we putting the ball where the bat's going to be? Are you framing activities such that your engineers are going to be able to be successful and have that first taste? This is Carol Dweck. She's done a lot of research on growth mindset. One of her observations is, if you use the term failing grade for young children in elementary school, they will typically disengage and they'll give up and they won't work through the difficulty. By changing failing grade to you're not yet meeting the standard, you're actually encouraging more resilience, you're encouraging the child to dig in more. So let's not waste any more lives. Because once we know the abilities are capable of growth, it becomes a basic human right for children, all children, to live in places that create that growth, to live in places filled with yet. Still not working. So let's hack this a little bit. What if we were to replace lives with careers? Children with people in places with workplaces. Let's try it out. Let's not waste any more careers. Because once we know the abilities are capable of growth, it becomes a basic human right for people, all people, to live in workplaces that create that growth. To live in workplaces filled with yet. Do you use yet in your organization? Or do you tell an engineer they're not meeting the standard? So let's advance the hypothesis. DevOps practices can be used to teach Microsoft enterprises to become a learning organization. So we started to talk with the idea that you need a learning organization to have a successful DevOps transformation. So what I'm suggesting is we'll use DevOps to teach a learning organization. Once we have the learning organization, we'll reinforce the transformation and continue the momentum. Circa 2014, this was what the landscape looked like at Columbia. On the one hand, very strong background in virtualization, storage, low turnover in the team, strong operational background, and good relationships between the teams. We have this habit of having primary engineers for all of our capability services and technologies. And while that's good, one of the side effects of that is that the rest of the team didn't feel empowered to work outside of their assigned areas of technology. Actually made us less resilient and less robust in terms of having engineers being able to cover different areas. So as a new manager to the team, I said hey, how about we take the alternates and they own the technologies and the primaries become the alternates? Everybody thought I'd lost my mind, so we didn't do it. And talking to other practitioners and other companies, one of the things that struck me is they would typically have multiple organizations. One organization would install the special DevOps tool, another organization would take it away. Yet another organization would put something else on there. We had a unique opportunity at Columbia that we had a centralized engineering team, and we didn't have to work through some of that pain that you'll see at other companies. So here's a public service announcement. Your mindset as a leader matters. The role of the leader in a learning organization is that of a designer, teacher, and steward who can build shared vision and challenge mental models. The leader is responsible for learning. So here's some questions to reflect on. Do you believe in your team? Do you have the humility to let your teams see you stretch outside of your comfort zone, to fail, to grow? Are you setting the standard that you want them to attain? Are you prepared to lead by example? Who's read the book, The Goal? Okay, awesome. Do we remember Herbie? So Herbie was the slowest member of the pack. So what do we do with Herbie? We put Herbie at the beginning of the line. And the reason for that is you want your bottleneck to set the tempo of the organization. So as you design your activities and your transformation, there is an opportunity to set your learning activities based on your Herbie and your organization, right? You don't wanna leave people behind. You don't want to exacerbate the imposter syndrome. You don't want people to feel lost or confused. I'm a former Army officer. So I have exceptionally high standards for leaders, both myself and the ones around me. I'm gonna share with you the be no do model that we had in the Army, just as relevant to DevOps as it is to the Army. So be, be a servant leader, an adaptive learner and a creative thinker. Know yourself and seek improvement. Know your people and help them to achieve their potential. Know the doctrine and know when to be constrained by it. So Jean was talking at length earlier about DevOps leaders that were really flying beyond their air cover. That's what that's really talking about. Know your profession, contribute to it and develop with it. Do the right things right. Do provide a clear and actionable vision. Do make timely decisions and do maintain balance and moderation. So I continue to reflect on these all these years later after my time in the Army. The DevOps Enterprise Forum wrote this white paper last year and it collected a whole bunch of tactics for change that you could try in your organization. Many of these showed up in our own journey at Columbia. So making a compelling case for change. If you're a Simon Sinek fan, as am I, this is begin with why. Why are you doing this journey? Why now? Why does it matter? DevOps information sessions, making the work visible. So in our case, we use TFS Kanban, Experiments, Gimbal Walks, so the idea of a Gimbal Walk is go observe how the work is actually getting done. Later on, we added whip limits and blameless retrospectives. Sorry about that. In terms of our own learning organization progression, 2015 was really the cognitive phase. Exposing new ideas, expanding knowledge and beginning to think differently. In 2016, we're starting to internalize those new insights and altering behavior. And in 2017, performance improvement, that's where changes in behavior are leading to measurable improvements and results. 2015 was really the start of our journey and it started with this idea. We want to go from zero artifacts inversion control, zero history in terms of using version control to 250. Doesn't sound like a lot, but I can tell you that everybody was pretty nervous about that. Also, we use Jeffrey Snover as our expert witness to tell the engineers, hey, you know what, DevOps is a real thing. It's something you really need to care about as a Windows engineer. Q2, we started to reach out to other practitioners such as Nordstrom and do reference calls and we started to investigate automation with PowerShell and VMware vCloud automation. Q3, we had a ton of difficulties in stabilizing tools, automation, et cetera. We're way in over our skis. This was the height of frustration for the engineers. And I would tell you that most of the team probably wanted to throw in the towel and say, yep, I'm good, I've had enough. But we persevered. So by Q4, incidents, other opportunities that would come, we were really trying to automate first. It was the automate first idea such as our ransomware remediation. By the end of Q4, we're at 100 plus Greenfield servers and our Chef implementation and instead of 250 artifacts in version control, we had 500, right? So once we got started, it's the idea of compound interest. You start making small changes, it starts to snowball. 2016, started to experiment with Slack, more VMware DevOps investigation. By Q2, we had a problem. We had all this PowerShell scripting that we had accumulated. That's awesome. We didn't really have a way to expose that and have other parts of the organization to consume it. Can't just send a PowerShell script to someone and say, hey, run this, especially if they haven't had the tradition background or training to really use that. We also had a data center migration from a private data center to a co-location. So we largely did that with automation. Automation to run through the VMs and actually move them. Automation to let the application owners know that their VM is being moved and then automation to do smoke tests and regression tests after they were removed to the other side. Q3, we were exposed to some new ideas at velocity conference, chat ops and rotations. A number of us were reading team of teams by General McChrystal. We had moved from Visual Studio TFS to GitLab for a source code management, also using GitLab CICD. And chat ops became a real thing in our organization. So Chef, Hubot, Slack, and GitLab. We're huge chat ops nerds, by the way. Q4, we're at 500 servers now in our Chef implementation and we're actively leveraging Chef Automate. Chat ops, more than 150 scripts. We're also using the Etsy day one idea so we bring in a new hire and on the first day we're expecting them to commit to our production chat ops environment. It's a little bit aspirational. It's a little bit hard sometimes, but it keeps us honest to make sure we have as few dependencies as required. That way, again, it's to put the ball where the bat's gonna be. You want your new hires to experience an immediate taste of success in your environment. Oh, we also identified a number of sources of friction that we'd never known that were there before, but because we're starting to work differently, starting to work more in pipelines, automated, et cetera. Friction around prioritization, friction around principles and practices. So again, having these opportunities to kind of work across organizations and trying to figure this out. 2017, this is part of our tool set really predicated upon Chef, GitLab, Hubot, PowerShell, and Slack. You can see all the rest there. So I would say that we've kind of departed from typical Microsoft enterprises and we're actually using a lot more of the open source or loosely coupled tools in our tool chain. We've done a lot with pods and in our context, a pod is a team of four to five engineers. It's a good balance of tenure at Columbia as well as experience in the industry. Really a representation of different skillsets. So a little bit of storage, maybe a little bit of server engineering, databases, collaboration, orchestration, et cetera. The idea is that that pod can actually be assigned to a variety of different things such as a continuous improvement project, an infrastructure project, or even taking a week of on-call rotation. So the benefit is we've been able to really ramp up our cross training. If you remember, I talked about having a fragile organization where only the primaries would do things, this has really enabled us to break through that idea. We recently had a team builder at Topgolf. Topgolf is one of these places that you hit the balls and you have to hit them in the targets and you get prizes and points and all this other stuff. But we had a team builder and we were in the middle of a massive storage migration from two old arrays to a new array. This engineer didn't wanna miss the team builder so he was like, hey, I will write the tooling and telemetry to be able to manage the storage migrations from anywhere. So we put that into our chat ops environment and sure enough, at the team builder, we're all hitting the scripts in our Slack environment to kind of see what the status of the moves were. Great thing about chat ops in our environment, we've really reached a point where whenever we have an incident or an opportunity or request, work request, et cetera, engineers are like, hey, we should create a script for that. So we really turn the corner. It's not should we automate, it's how should we automate or what are the things that we're really trying to achieve in our automation. We also had to put some Slack rules and engagement in because we already had a number of collaboration technologies such as Skype for Business. So this has made a lot of people uncomfortable so we're working through that. And in terms of our portfolio, virtually everything that we have, we have a footprint in our Slack environment now. So it spans from Azure to Netscape, or load balancer, SharePoint, Teradata, Commvault, EMC, VMware. If we have it, we're putting into Slack because it's a single pane of glass to be able to work through permissions, work through other friction you may have in your organization. And increasingly, sister organizations, more of the operations organizations, we're giving them extensible scripts that they can run. Every week, we have a scheduled retrospective every Wednesday at nine o'clock and the engineers know that it's going to happen. We rotate who is facilitating the retrospectives and we don't just hit the post-insent reviews. We also hit the good things and the near misses because there's learning there too. Sometimes we do two retros or three but every week we're going to have a retro and that's been absolutely fundamental in our journey. I came back from winter break so we started this journey two years ago where we're afraid of public cloud, et cetera and we're like, hey, we have all these proof of concepts that we want to do, awesome. And really we've migrated to a cloud-first orientation especially for green field capabilities. Or do we pass because that's in a Microsoft organization that's where it's easy to kind of get things going. Heavily leveraging Terraform and ARM Templato, we do want to use infrastructure as code in that practice and everything that goes live is going to have to do a game day exercise. Meaning it's a chaos monkey example, we want to tear apart that environment and make sure that we can get it all back the way it needs to be. In terms of Chef, we're over 1,300 servers now. The breakthrough to get from 500 to 800, one of our engineers wrote a script to Brownfield, a whole bunch of servers. So we interrogated vSphere, we figured out what was particular about it and then we were able to inject that and write files that would describe those environments. Certainly not everything, but it's something and we have them into the same framework and then we can kind of extend that and extend our base code books. We're also starting to look at Sensus, so Sensus, Grafana, InflexDB for our monitoring. And then our security engineers, they're super excited because we have 1,300 servers in Chef now and they get a lot of leverage without having to do much work. They're working on CS code books and compliance. Green-blue deployments, increasingly we're moving this way in terms of SAP application servers, net-scale load balancers, even our vSphere environment. So being able to rebuild vCenters, green-blue style, and we cut over to them instead of upgrading them in place, that's definitely on our roadmap. Learning labs, so the idea that we can create a self-contained lab that will show a new hire or someone that is coming from a different organization how to achieve our practices, whether it's the chat-up example or other things, this has really given us a lot of leverage as well. So we come back to this idea. DevOps practices can be used to teach Microsoft enterprises to become a learning organization. Certainly in our case, we're finding that to be true. We've had to be flexible and compromised at places, but it's gonna continue to be a critical tool in our toolbox as we go forward. Thank you.