 Yeah, super excited to be here. This venue is amazing. And anytime I grew up outside of Boston in Marlboro, worked for Bose and EMC, so any chance that I get to come back to Boston is I jump at it. So anyone here an enterprise architect or an enterprise architecture or ever been an enterprise architecture? I'm raising my hand too. Had an enterprise applied architect title at Nordstrom. They attached applied to it because that made them feel good about calling me at 2 in the morning when something I signed off on failed usually spectacularly and usually right before a sale event. So that was awesome. Thank you. I promise, EAs, you're all lovely, excellent people. This is not going to be a riff on enterprise architecture completely, so it'll be good. So we should always start with a why. Why are we here? This is going to be different for different people, but for me, I want to deliver customer value faster and more humanely. This is kind of what's top of mind for me always. In a slalom, it's super cool. I get to see clients at all different stages of this. And what I observe is that what I get most interested about is the intersection of tools, people, and how you organize. And for me, that's what really unlocks lasting change. So when we talk about faster, that's code for speed to value, or cycle time, or make more money, or do more good, my favorite. And then humanely, don't burn people out while you're doing that. So don't work 80 hours a week. Don't be waking people up at 2 o'clock in the morning for no good reason. So how do you combine all of that to do better? This is one way. So I come across this quite a bit by modal IT. You get mode 1 systems of records. So these are the stable commodity systems. And they're usually legacy. And they're usually super, super critical to your business. And so they're heavily governed by enterprise architecture. There's a lot of process wrapped around these. And that's because every time there was a failure, the team would look at that and like, we are never going to have that happen again. And some process gets layered on. And then another failure happens, and more process gets layered on. And so you end up with a set of systems in an organization where people are very, very stable. It's difficult to change, even if you want to. And because they're inward looking, they're focused on the systems and making sure they're stable and making sure they're available, they're often not looking outward at the larger customer. They don't have line of sight to that customer. It's not because they're bad people. It's not because they don't know to do that. It's not because they don't know the larger customer exists. The incentives are all inward. And then you have mode 2. So this is a wholly separate part of your organization, systems of innovation. They get all the cool things. And then I say maybe. So they're the ones likely to be doing agile. They're likely to be practicing lean. And they don't get all the governance that the mode 1 gets. I say maybe because it turns out they still super rely on mode 1 systems. And if they want to do something that requires a change back there, it's kind of a sad panda all around. So I look at this simple model, mode 1, mode 2. CIOs love this because it's really easy to understand. And I struggle because I think of organizations as complex systems. So we kind of think about that. And this is a definition from the book Thinking in Systems. So if systems theory or systems thinking is new to you, definitely check out the book Thinking in Systems by Daniella Meadows. But a system is more than the sum of its parts. It may exhibit adaptive, dynamic, goal-seeking, self-preserving, and sometimes evolutionary behavior. So this is what every large organization, even small ones, that I come across, if you look carefully, you see this going on. And then we go back to bimodal IT. And we see there's no flow between mode 1 and mode 2. And that's intentional. But you're isolating parts of the system. Complex systems, they love inputs. They love outputs. They love feedback loops. And when you start isolating them, things start to stagnate and they slow down. So in summary, bimodal is an overly simplistic way to organize. So be just very careful of anyone who tells you, I got anything that's simple in your organization. It is likely sketch. Be very careful. So what actually works after I ranted on bimodal IT a little bit? We first need an acknowledgment that innovation and change is required throughout the entire organization. You cannot have a group of haves and a group of have-nots. You need a system that takes into account transition states and feedback loops throughout the organization. Your most critical systems, those are the ones that you want to be able to change the fastest actually and recover the fastest and be the most adaptable. So we're going to talk about this idea of pioneers, settlers, and town planners. And if you haven't heard of this, this is Simon Wardley's terminology in his model. Check out his blog, his Twitter feed. He's got a lot of great stuff that goes in depth on this model. He also talks about mapping, which is how do you come up with a solid strategy of understanding where you are today and where you need to go. It's good stuff. So I'm going to cover each of the pioneers, the settlers, the town planners, kind of high level what they do, some of their traits. And then we'll talk about some aspects of the model. And then we'll get into a real example of it. And then we'll get into anti-patterns that will cause this to completely fail. So pioneers, these are the people that in your organization bring in the new idea, either they've adopted it from somewhere outside of the org, or they've kind of been influenced by a lot of ideas and come up with something brand new. There's a minority of people in your org are actually pioneers. They're building new things. And they're building things that the rest of the org is going to look at me like, I don't quite trust that. I'm not getting on that way again and going cross country. But it's a critical part of all this. They live outside of standards in ITIL. You could maybe think of this as shadow IT. They fail quite a bit. What they build usually isn't trusted and probably shouldn't be. And they're comfortable going with gut feel. They are not going by metrics. They don't have any data to back up that the thing they want to do is the thing you're going to be doing. They're just feels good in their gut. Turns out you need these people. You just don't need everyone to be a pioneer. OK, so settlers. Yep, we have some gamers in here. So these are the people. These are the teams and the people in your org that see what those pioneers are doing. And they're like, I'm not getting on that. But I have some ideas to make that even better. And I can actually use it in production. So they're the ones who are starting the village and helping build trust that actually this is a thing that we can do. So some traits. They're the ones making prototypes real. So they're actually being used. And by doing that, they're building trust throughout the organization. They adopt each other's ideas with some customization. They make it their own. So now you get the beginning of an ecosystem. And they're focused on continuous improvement. So what this means, though, is as they're adopting the thing that the villager next to them adopted, say a house. Say they're all building houses, they're going to improve it a little bit. So not every house is going to look the same. And then you're going to get occasionally someone like, yeah, a house is a good idea. I want to do this completely different design. So you end up with kind of a proliferation problem, we'll say in quotes. Because I don't think it's actually a problem. But now you get town planners. They're like, if this village keeps growing like this, it's going to be crazy. It's going to look like downtown Boston. So what they do, they excel at looking at the overall village, the system, and saying, hey, we think we can turn this into a commodity and scale it and making it more efficient. Not everyone wants to or needs to or should be building their house. They want to come into the village and then go to their work. So they're the ones who are going to be like, yep, we're going to build that for you. You push the easy button. Hillcopter plops a prefab house down into your lot. You get a few options for customization, but if you're off to the races, go do your job. These people, so they focus on what is common and well-defined. They're able to industrialize and scale. They have a focus on operational efficiency. They build the services that pioneers and settlers are going to rely on for future experimentation. And they're very metric driven, unlike the pioneers. So they are all about the data. Otherwise, how else do you become efficient? So a few things about this model that makes it very different from others that you might see. It's a theft-based poll model. So in nowhere in this model are things being pushed or mandated. In all cases, it's being pulled. So the pioneers bring in the idea. The settlers take that idea. They take it. It's stolen and pulled in, and they make it their own. The town planners are looking at what's going on, and they are taking that idea. They're stealing that idea and making it their own. And then the reuse is your feedback loop. If what the town planners are building isn't being used, they're not building the right thing, and they need to re-examine that. But no one is mandating anything here. It's all being, it's all poll system. Compare that to bimodal IT, where things are contained into each of these modes, and there's a lack of flow or poll system, or even mandates necessarily between the two. Some other things to know. Pioneers, settlers, and town planners are all roles with excellent people. So don't ever get the idea that the pioneers are some kind of rock star. I mean, they are good people. They are excellent people. The settlers are excellent people because they are able to take those ideas and make them real. The town planners are super excellent people because they can build something that scales and is usable in the future. So everyone is excellent in all these roles. So there needs to be a lot of empathy between these different teams and realizing that, hey, we all bring different skill sets to the table. You can have and should have pioneers, settlers, and town planners even within a team. So don't get the idea that you have a team of just pioneers and a team of just settlers and a team of just town planners. Even within a team, you need someone who's taking that crazy idea and trying to make it work. You need a couple other people on the team who are like, yeah, that's cool. We can make that actually work. And then you need the town planners on the team that turn it into something that the team is actually able to use in the future and have it be sustainable. So it's a strong argument for diverse teams and making sure you have diverse skill sets represented within that team. You can maybe think of this as a subsystem of the larger system. OK, so this is so important to this model that I say it again. Foster the feedback loops and maintain the pole nature. If you get into a spot where everything is being mandated because you think you've figured it out and like this is the one true way, you're moving away from this model and you're going to get yourself stuck and start to stagnate a little bit. OK, it's all great theory. So let's make it real. This is a story of continuous delivery adoption. Names are removed to protect the innocent, but it's a real story. There was a small group of pioneers and they were like, we need to do better. This was a large organization, thousands of people in technology, had no continuous delivery, very little build automation. And we had a small group that said we need to fix this. We're under too much stress. We cannot meet the needs of our customer. So they came up with this idea of let's do continuous delivery. We know where to do it. We're just going to make this happen. We had sponsorship and common vision from the top. CIO got on board with it. And the team over a period of time got to a near minimum viable product state, like could ship code to production? Ultimately, though, this particular model or what the team built was not adopted. And where we fell down on that was we're trying to push it onto a team. And I should say, I had no idea this model was a thing. When we were going through this, it happens to map to it really well. But we were trying to push it on a team. And that team was like, no, I don't think so. We're not adopting that. You pioneers, we do not trust what that thing was. So that was the failure. However, everything we did up to that point was had a strong focus on how do we make it easy for the rest of the org to see what we're doing and adopt these ideas? So we had weekly demos. We had all our code internally open sourced. Later, some of it got externally open sourced. So everyone had access to what we were doing, what we were learning, and what our plans were. Because of that, another team, a completely different team, they saw that, and they're like, we want to do that. And they took those ideas. So they pulled and stole the ideas with our excited blessing and then shipped that thing into production. And now they're able to do continuous delivery into production. They made it their own. And it was awesome. We completely celebrated that. But it really demonstrates and made it solid for me that it has to be a pull model. That was quickly followed by other teams adopting something very, very similar. They either took the same exact code and continued to build a pipeline and put it in their team. Or they started customizing it and modifying it, like different styles of house. And some even radically different. They went with completely different tool choices. So you have a lot of the teams using Go CD. And then someone's like, oh, no, Bamboo's better. Someone else is like, no, I'm sticking with my Jenkins. But so now we have what a typical CIO or enterprise architecture team would say is now we have a proliferation problem. I saw it as a huge success because we had continuous delivery going on everywhere that we didn't have it before, even if people are using different tools. However, it turns out, like houses, not everyone wants to build their house, not everyone wants to put together their own pipeline. In fact, most people don't. So I enter the town planners. So then our idea is we're going to build a commodity pipeline and a platform for the organization to adopt with the intent of the pioneers and the settlers can now just provision and deliver on this pipeline and focus on what the next thing is. This is still kind of TBD, whether this ends up being successful. I will say here it's super tempting to have the pioneers who came up with that idea enter and build this platform. You have to make sure you have some actual town planners, some people that understand scale and understand operational efficiency and understand how to make something a commodity because I promise you the pioneers don't know that and it ends up going a little sideways. All right, to recap, you're going to love my graphics. These are awesome. OK, the blue is your org. The low dot is your pioneers. The color of the dot is their tool choice, we'll say. So you have one team trying out a thing. And it could be any team. They're the pioneers. The settlers started adopting that. So now you have lots of tools throughout your org, lots of teams doing the thing. But success, because now they're doing continuous delivery where they weren't before. Now it's time to turn it into a commodity. Most of the teams are now using that platform that got built. So make sure you go through this process. Don't land like we're going to build this platform and commodity before you've seen pioneers and settlers take over the start adopting the idea. Don't jump into a enterprise-wide continuous delivery pipeline. I mean, I'd be super happy to build it for you, but I would be super sad when it doesn't stick. Notice there's still a couple people, a couple teams, using different tools here. That's OK. That's good. It's even desired. You need something to test against to make sure that your platform or your commodity, whatever you've built, it's still the right thing. So you have a couple teams you can compare against. And if they come up with some ideas that are good, you just steal those ideas and put them into your platform. You need to maintain that theft-based pull nature of what you're building. OK, anti-patterns. What is going to cause this to be chaos and sadness? First, lack of a shared vision and common outcome. And this goes for almost anything, really, in a complex organization. Everyone needs to have a shared vision and a shared purpose. Like, where are we going and how are we going to get there? And that enables teams to experiment but be pointed in the right direction. Everyone needs to be incented on a common set of outcomes. If you're back in that bimodal IT model, you remember, mode one is incented looking internally, making sure their system is safe and protected. Mode two is incented on, like, let's change features as fast as we possibly can. And there's direct conflict there. Everyone needs the same incentive. Don't jump into a new model all at once. We see this with agile a lot. Hey, I have a 400-person delivery team or a delivery org. We're going to be agile. I heard agile is a cool thing. It's going to solve all our problems. I am declaring tomorrow agile day. And we hired some scrummasters. It's going to be all good. And then it's not. You get, at best, teams doing stand-ups and saying they're agile. So be really intentional about this. Start small, typical change management things. And then the other one is using enterprise architecture to prevent waste and forced adoption. It is the wrong way to use enterprise architecture. From a leadership level, it is super tempting to do this. Like, no, no, we got this figured out. All these teams just have to snap to this. Not the correct way to use enterprise architecture. In an existing org with legacy systems and large complex interconnectivity, enterprise architecture are going to be your best friends for figuring out how all of that is tied together. Likely, everyone in the org thinks they know how it all works and maybe EA is the only one who does because they see the wider picture. So use enterprise architecture and use your EAs to uncover where to start, to start untangling all that complexity and making it visible. They're going to be your best friends here. Do not use them to push or mandate things or as a gate to get into production. That's my other favorite one. I think there could be a whole talk on innovation labs. Do not rely on innovation labs or centers of excellence for your pioneers. This gets into sometimes mode two where they get all the cool things and no one else does. Innovation labs tend to be set up off to the side of your organization and that's intentional because they need to be outside of all your existing process. It sounds like a really fantastic idea. The challenge is it's outside of your existing process. So whatever they built and the way they built it, when they toss it over the wall into your org to actually build, it doesn't work, often doesn't work and sometimes makes things worse. So I would say if you're in an innovation lab, the best thing you can do is be super, super public about what you're doing, what you're succeeding at, what you're failing at and making it really, really easy for the settlers in your organization to steal your ideas and when they do steal them, celebrate that. Celebrate it as the settlers idea. Make sure there's, make it really easy for the org to pull from you. Same deal with centers of excellence. This is easily fixed. Change excellence to practice. So now you're not centering all the excellence and only the excellence is on this little ivory tower. You now have a center of practice that is open and welcoming and inclusive to the rest of the organization. And now the rest of the org is able to distribute the excellence and pull from it and steal it and make it their own. Centers of excellence often kind of get into a habit of mandating things, coming up with standards, coming up with the best practices. Change that to be a practice. Okay. Do not forget that your organization requires a systems thinking approach. There could be a whole talk on defining what systems thinking is and how it works. That book, Thinking and Systems is a great, great introduction to it. Organizations are complex. There are inputs. There are outputs to everything. There are feedback loops and your org will want to kind of maintain the same level. So the classic example is maybe a bathtub. You have an input, which is water, right? And you're filling up the bathtub. You have an output, which is the overflow drain, hopefully. Your tub will maintain some amount of equilibrium. No matter how much water you put into it or take out, it's not gonna overflow. But if you put in too much, you inject too much change or too much water in this case, it will overflow. So you just, you need to be cognizant of that. And maybe you do want a transition state. Maybe you want to get a bigger tub, but that's what tells you you need a bigger tub. So watch your inputs, your outputs and your feedback loops. Water's filling out of your tub would be a horrible feedback loop because now you gotta fix your whole bathroom. Okay, so key takeaways. Create flows and not barriers or mandates or gates or long checklists that you have to sign off on. And each role is filled with excellent people. If you can remember those two things, you'll be in good shape. So this is evolving and we're not finished. I'm really excited to hear what everyone else is doing and how you're approaching this and how you're optimizing your organization and ideas for how to do it in the future. So thank you very much. You can hit me up on my email or on Twitter. It's probably easiest. Thank you. I appreciate it.