The Relationship Between Culture and Performance

Mike delivers this keynote presentation at AgileIndy 2023 where he explores the relationship between culture and performance and how trustworthy systems of delivery help establish and reinforce your cultural identity and norms. 

Video Transcript

We have to respect both sides of the equation. Both sides have to be true. We have to have an economically viable business and we have to have a great culture where people want to come to work. Having a great culture where people want to come to work that doesn’t produce results, not good producing results to the expense of our people, not good. So we have to figure out how to balance the two points of view.

(Musical Interlude)

Opening Remarks

I appreciate you guys letting me come and think out loud in front of you. And that’s typically how I think about a lot of the talks that I give because everything in the agile communities about doing it and learning from it and sharing with people and getting feedback and figuring out how to do it better and that kind of stuff. And so what I’m going to do today is I’m going to talk about a topic that we all love, but for me has been kind of a controversial kind of lightning point a little bit. And so I’ve been thinking about this idea of culture before I get started, how many people think that creating an agile culture is an important part of doing transformation work?

Systems are a Predictor of a Balanced Culture

Okay, fair enough. How many people think that culture’s like the biggest impediment to doing transformation? So I’m going to cheat a little bit on this talk and I’m going to tell you the end, and then we’re going to do a talk and then I’ll tell you the end again when we get to the end. Okay? So, if anybody wants to stack, you can text the word CULTURE to 33777, and my team will send you the deck.

But I have a really strongly held belief that how well you organize your company, how well you organize your teams, how you do governance, what you measure, what you control is as much a predictor of how well you’re going to do with agile and how much of an agile culture you’re going to have is anything that you try to do with training or workshops or whatever, trying to get people to think and feel and be agile.

So what I’ve been saying around for a long time is that if your belief system is that you get people to do an agile culture or be an agile culture, if that’s what you believe the mental leap that you’re trying to make is that if they are open to the idea, if they’re open to being adaptive and delegating and not being command and control, all the goodness is going to flow out of that. So we start with culture, maybe we go to practices and then all those teaming strategies and dependencies and governance and metrics and all that stuff that we struggle with all the time will just kind of work itself out. So the belief when you start with culture is that the idea is that your delivery systems are going to emerge. When I first started thinking through this idea, I was actually really thinking about the idea of practices because back in 2010, a little bit earlier than that, Jim Kundiff, the Scrum Alliance, and those guys were really popularizing the CSM certification, PMI was doing the PMI ACP or a lot of us were part of that.

Few people in the room were part of that. And what we were doing is we were kind of hoping that if we taught people how to do agile stuff, that they would get the results out of it.

And so we ended up with a lot of folks doing standups and sprint planning and story cards and sticky notes and burndown charts and reviews and retrospectives. All that stuff’s really cool, but there’s a lot of people that are doing all that stuff and not getting a whole lot of agility out of it. Anybody on that boat you rush, you guys just aren’t raising your hands. I get it. Okay, I see how it goes. Nobody wants to self-identify on that one. Okay, got it. So what we’ve been trying to do with this expeditions and Basecamp stuff, which we’ll talk a little bit about as the talk goes on is what we’re trying to ask ourselves is how do you create the conditions in an organization for the practices to actually deliver value and for the culture to begin to emerge over time? Because a lot of times when we walk in and we experience culture challenges, what we really are experiencing is cognitive dissonance. Like imagine if you’re a 30 year architect running a COBOL mainframe system doing a payments processing engine there where nothing can be off by a penny and you’re having all these problems and somebody comes along and says, man, if you were just doing daily standup meetings, everything would work out.

It is cognitive dissonance. So a lot of what we experience as a culture problems is cognitive dissonance. How is it going to work? The good news is, is that when you explain to people how it works, sometimes those people that are resistant become your biggest allies and they actually help you do it. So we’re going to explore that a little bit.

What is an Agile Culture

So, here’s the end of the talk. So if you’re bored already, first 10 minutes of the thing, start with systems, start with structure, start with governance, start with metrics, go to practices, and then you can get a culture to emerge out of that. So that’s the end of the talk, but it’s also the beginning of the talk. So you guys got to listen to me for another hour. So I’ve been playing with this talk all year long. So I got to speak in, I’m trying to think where I’ve spoken this year I got to speak in Raleigh, North Carolina, spoke someplace else.

Oh, Detroit, that’s where I’ve spoken. Can’t believe I forgot about the guys in Detroit. And then here. So this is probably my third talk this year, and I’ve been doing various iterations of the talk. Oh, I actually got to speak with a client in Belgium and I did this talk a couple of weeks ago. It was pretty cool. Anybody have been to Belgium? Kind of a cool place. So I did this with a room full of executives, 50 of the top executives in a pretty large telecom company over there. You imagine telco, really big, really complex stuff. And so we were exploring the idea of what is culture? And when I think of culture, when people talk to me about culture, these are some of the words that I see and you guys probably have your own list. So we want a culture where people trust each other.

We want a culture where people take ownership. We want a culture where people feel empowered to make decisions. We want a culture that values responding to change over, following a plan that want to manifest the lines. We want to be adaptive, we want be emergent, we want to create safety, we want to have a cultured teamwork. Maybe we want our leaders to be less command and control. We want people again to feel empowered, enjoy coming to work. We want things to be fun. And one of the side effects of being a business owner for the last 13 years is that if you’re not making money, you don’t get to do anything if we’re not profitable. I had one of my employees tell me one time, and forgive me this little aside, this wasn’t something I planned to say. He goes, I said, you have to teach clients how to buy from us.

And he goes, my job’s not to teach clients how to buy from us, my job’s to help them get better. I said, well, if you don’t teach ’em how to buy from us, we can’t stay there and help ’em get better. And there’s some truth to that in any business, we want to empower our people, we want people to love coming to work, we want all these things and those are great things. But the thing at the end of the day is we have to figure out how to put product in the market faster. We have to figure out how this great environment, how it translates into working tested product to get shipped to customers on regular intervals. And so agile for Agile’s sake is starting I think to wear pretty thin. I was talking with Dave Pryor, who’s CST, who I have on staff, awesome human being. If you’ve never been to one of Dave’s classes or gotten to meet him or listened to his podcasts or whatever, awesome guy. And we were exploring a lot of layoffs that are going on in the agile community right now because a lot of coaches that are out of work. And I think it’s because somehow along the way we focused on the culture side and the practices side and just believed that it would go towards greater agility. And it does sometimes, but it doesn’t all the time.

So that’s the first little thing I’ve been thinking about. Okay, so what is an agile culture? Why is culture important? We were just talking about this because we believe that if we have the right culture, we’re going to get agile stuff done, we’re going to build the right products, we’re going to have fast feedback cycles, we’re going to have attention to quality, early delivery, predictability efficient, lower cost innovation, things like that. But there was this cartoon, I used to actually have it in my deck, probably should have put it in at this one, but it was like these two scientists standing at the board. You guys ever seen that one? It’s a bunch of on one side and it’s a bunch of math on the other. And it says then a miracle happens here.

And the caption of the cartoon is I think you need to be more explicit in step two. So a big part of what we’re going to explore is how do you be more explicit in step two? The other thing is kind of interesting, it’s one of the topics that I see is that who’s responsible for an agile culture? Is it the leadership’s responsibility for being agile, right? They’re supposed to get out of the way and trust everybody to do their thing. Is it the teams? Are we trying to establish culture in teams? Often in organizations where real agile teams don’t really exist, we don’t really get six to eight people cross-functional, dedicated everything and everyone necessary to deliver working tests and increment rise it up to them to be agile. What about our customers? I mean a lot of times we’re operating in really complex supply chains.

A lot of times we have external vendors that we’re working with that have to become part of this equation too. Is it up to the organizational leaders? I don’t know. Is it up to the systems and stuff that’s going on in the cloud? So we have to kind of sort through all that. What do we mean by culture? So this is where to me it starts to get interesting and this is actually a pretty recent thing that I’ve been thinking about. So again, aside from my talk in Belgium, this is kind of hot off the presses out of my brain and I’m thinking in front of you, and if I actually had to do this slide over and I had some more time, I would’ve said the four competing views on culture.

And so the reason why I said red and blue culture is there’s an instrument I got turned onto about five or six years ago called color code and it’s like personality assessment and it’s based upon the same underlying sciences, like a disc, everybody done a disc. If you’ve done a disc, you’ve probably done something like this one. And what was interesting about it, and the reason why I like it is because when you talk to somebody, you can start to discern personality type a little bit. When you look through this and what it does, it’s really simple. It says, it basically ranks you as to whether you’re logical or emotional controlling or non-controlling. And so red is logical controlling blue is emotional, controlling white is logical. Non-con controlling. Yellow is emotional, non-con controlling as you might imagine. We’re all mixes of stuff. I’ve actually had employees that are equal in each of the four colors. If you know me personally, this won’t surprise you. I’m like almost 80% red, logical controlling almost no blue, no emotional expression, but I like that fun. So that’s kind of the yellow quad. And so what I started to think about was I think a lot of us talk about culture through our personality and what we value.

And so a lot of what we do when we talk about trust, empowerment, safety, fun, collaboration, we’re trying to create connection because that’s kind of what we want. We want to have connection and intimacy in the workplace and I think a lot of times that stuff is kind of missing. And then that touchy feely mumbo jumbo stuff that us CEOs like we struggle with it. It’s supposed to be funny, you guys can laugh a little bit with me, hits with the reality of well we got to get product put in market. So I’ve been thinking, I was thinking about this idea of red culture versus blue culture, but in my little model you actually have yellow culture too. That’s where all the fun comes in. That’s where I want to get up and go to work every day and I want to solve really cool problems.

I like being here with these people. We like to have that as well. And then some of us have a white personality type or dominant white personality type. We kind of like to follow rules. So everybody here, probably a lot of our scrum masters are that way. Nope, do daily standups. It can only be 15 minutes. This is the three questions you ask us. So you start to get a lot of that kind of stuff. And so if I were thinking about it, what we’re trying to do, if we want to maximize culture, if we want to do well, we probably have to think about it through the two lenses at a minimum, if not for lenses, how do we create intimacy and connection? How do we create fun? How do we play by the rules so everybody understands what the rules of the game are and how do we produce results?

So, a balanced culture I think would address all of those aspects of personality. The funny thing was I didn’t even think this was all that crazy insightful. All I knew was that I didn’t like the culture first stuff. And I was talking to this business advisor I have and I was telling him about this idea and he goes, this guy’s like 65. He ran a company of about 1400 people, does private equity and investment banking and all this really interesting stuff. And he’s like, that’s super insightful. And I went, oh, okay. Well I guess I got to build a slide for it and come talk to the people in Indianapolis about it. The most important thing.

So, what I was thinking about, so that insight, so take that insight culture’s, at least two things, maybe it’s four things. I think that’s fairly comprehensive once I break it out to before and then you start to think about how do the different methodologies address different kinds of culture aspects, that kind of a thing. And so I was thinking about Scrum and so I just lifted this off of Mike Cone’s website and it’s attributed, so I hope he doesn’t mind too much mountain good software. Cool guy. Learned a lot from him 15 years ago. So think about scrum. So I’m going to stick with the red and the blue for just now since I don’t have any slides around yellow or white. And so think about the red and the blue side. So if I’m going to do scrum and I want a culture of scrum, scrum is a thing, right?

Six to eight people, sometimes a little more, sometimes a little less. Their team, they have everyone and everybody necessary to be able to deliver the work that’s in the backlog. They write user stories in a specific format. They maybe estimate them using new story points, planning, poker, they burn them down, they produce a working test and increment of software at the end of every sprint. And basically if I know the size of my backlog, I know the velocity of the team, I can start to anticipate scope or duration. That’s a very red view of Scrum. That’s what tends to resonate with me. I came out of project management, like I said, PMI ACP, all that kind of stuff. So to me it was a lot about how do I deliver an agile and for people like me, that’s a big part of culture.

I want to work on teams that have a culture of actually producing stuff and doing what they say they’re going to do. I want to work on a team that can make and meet commitments. I want a team that’s going to go out and kill it on a plan, but I also want people to feel trusted and empowered and connected and have fun. So now think about Scrum through that lens. So I’ve got these people, they basically get to meet with their business person every couple of weeks and then inside of that they get decide how to do the work. They to connect with each other, collaborate, trust each other, plan together, have fun, get to know each other, do retrospectives. We can create personal safety in that environment, all those kinds of things. But the interesting thing is I don’t get in Scrum the blue side of the equation unless I’ve implemented the red side of the equation because what happens if we don’t implement the red side of the equation?

Well then, the project managers come in and they start controlling us and telling us what to do and making us attend to their Gantt charts and their estimates and all that kind of stuff. So what we’re seeing is we’re seeing a fight between the connection, the blue, the yellow side, and I got to get stuff done on the red and the white side, so they’re kind of at war a little bit. I think we need to have both. We need to figure out how to have both. The cool thing is I think Scrum gives us the mechanism for having both. We create the container that the team gets to operate in. All the blue stuff comes to pass. We don’t do all the red stuff that sits on the outside of Scrum and then people come in and they start messing with our stuff.

So, I put this one in for this client that I was talking to in Belgium. I’m not expert on Spotify. I’ve never implemented Spotify. Anybody trying Spotify? Is that a thing I heard Henrik Berg isn’t even doing Spotify anymore, but I mean I know Henrik not all that well. He hasn’t told me that, but that’s what the rumor I had was. So I don’t even think Spotify’s doing Spotify anymore, but we call it Spotify model. What was interesting about Spotify model to me when it first came in, because I do see evidence of tribes and chapters and guilds and things like that, and what I think Spotify was trying to recognize is that in most complex organizations there are things, right? There’s managers and there’s hierarchy in that regard. So we might want to manifest that in a, again, I’m trying to think it might be like a guild or something like that, or a tribe rather collections of teams that deliver against value streams.

We have communities of practice, so I kind of think about what Spotify did is it came along in an instantiated, a lot of that and that’s cool, that’s a nice ad and it’s kind of neat to have it explicit, but at the end of the day it’s still fundamentally predicated on scrum teams and collections of scrum teams. And so it didn’t, in my opinion, do a whole lot to advance the red side. It doesn’t do a whole lot to inform us if we can’t get scrum teams working the right way, but it did give us some constructs and some additional language that I think was super valuable. Anybody trying safe around here? Gosh, you guys aren’t doing any Agile, anybody doing agile in the room? Any methodologies that I have in LeSS, Disciplined Agile Delivery, maybe Al Shalloway’s, flex stuff? I bet you the guys at S&P probably have something figured out on their own.

So, (unintelligible) a pretty smart guy. So, with SAFe, right? What I think is interesting with SAFe, I was sitting in Fort Collins and it’s this lean software thing and Dean was there and me and Dennis were there and probably Chris Schenkel was there, a few other people were there and I asked Dean, I said something to the effect of you’ve done a really good job of putting together this methodology, but you’re not giving folks guidance on how to organize their scrum teams or how to figure out their value streams or how to encapsulate and break dependencies or whatever. You’re just giving them a tool to manage dependencies. He goes, yeah, I get it. He goes, that’s the domain of consultants, that’s the domain of organizations to figure that out. I’m kind of teaching and selling a process and a certification. It’s like it’s cool.

When I look at what safe really brought to the table was a first order recognition that in most large organizations you are using aggregations of scrum teams that have dependencies between them. And when I read on LinkedIn and other forums where people are really attacking safe and the overhead is safe, I’m like how do you want to manage dependencies? And what most people say is, well, we’re just going to self-organize them and self-organized dependencies tends to result in bad planning, late dependency resolution, missed deliverables, missed deadlines, and so it all becomes red side stuff. It all becomes command and control because at the end of the day, if we don’t get the teaming strategies right at the scrum level, we don’t get the encapsulation at the team level. We don’t get the protection of the team that the boundaries of Scrum offers. Then we don’t get the blue side cultural benefits and then the organization imposes a bunch of red overhead on us.

So we have to respect both sides of the equation. Both sides have to be true. We have to have an economically viable business and we have to have a great culture where people want to come to work. Having a great culture where people want to come to work that doesn’t produce results, not good producing results at the expense of our people, not good. So we have to figure out how to balance the two points of view. And so those three methodologies, others have tried to deal with that in different ways, biasing one direction or some of the coolest conversations I’ve had with folks are they’re like, Mike, I love your take on culture change. And I’m like, you do really? I mean it’s like third on the list. It’s behind all the systems and structures and practices and stuff like that. I think there’s some people that want the culture so bad and they kind of intuitively get that there’s a process to get there, but it does make me laugh when people say that they like our approach to culture change.

I don’t feel like it is an approach to culture change, but I’m very red, so it’s like I tend to put the blue side of that.

Impediments to Successful Culture Change

Now the challenge that gets in the way, this is something else I’ve been saying for gosh, almost 15 years to the point I feel like I’m a broken record is dependencies. Anybody? Now you guys can raise your hand on this one. Anybody have dependencies between teams and the organization? Yeah, seriously. So I’ve kind of a rule of thumb around dependencies, you either have to break dependencies or you have to manage dependencies. What you don’t get to do is just wish the dependencies go away. And what you also don’t get to do is trust the team to self-organize that the dependencies go away because I mean, think about this. Let’s go back to my COBOL legacy mainframe a c H process.

I grew up in financial services, so that’s always the thing I think about really complex legacy systems and you say, okay team, we’re going to create eight scrum teams. I’m going to empower you to self-organize your impediments away, move to the cloud, move to a services oriented architecture, just on and on. I had this exercise I used to run through with people when I’d come and speak at smaller user groups. You guys are a little bit big for user groups, that’s why I didn’t go here with you. But the idea of that if you were king for a day, you were king for a day, you could change anybody’s hearts, minds, they do whatever. You said you could change culture overnight with the flick of your scepter or what would you do tomorrow? What would you go do once culture was changed? And what you would do is you’d figure out how to start breaking dependencies because dependencies kill agile.

At the end of the day, one of my good friends in the agile community, this is probably 10, 12 years ago, I don’t know if he still believes this, but I did a post on, I think it was at version one still at the time, I did a post on dependencies. He goes, but Mike dependencies are everywhere. Dependencies are inevitable. I’m like, yeah, true. Either you manage them or you break them. So if anybody hates safe and thinks that it’s incredibly anti agile, I said, okay, cool, break your dependencies and you don’t have to do safe anymore. Simple. And the presence of dependencies, you don’t get to not manage them or else you won’t deliver anything. You might get the red or you might get the blue, but you won’t get the red side of things. Oh, that’s actually what I want. I want to drive that home.

And so you think about it, matrixed organizations are a problem, like technical coupling of cohesion issues are a problem. Encapsulation issues are a problem. Org charts are a problem. And so what my hypothesis fundamentally is, is that agile transformation isn’t about large scale culture change, although it can be and it isn’t about large scale process adoption, although it can be. What it is is about breaking dependencies at scale. It’s about increasing encapsulation, creating the opportunities to minimize orchestration so that each of the scrum teams can operate with agility. That’s transformation to me. And anything else is practices adoption or really cool training classes and sticky notes and stuff like that.

Nobody’s walking out yet. Okay, that’s a good sign. Okay, good deal. Okay, so what I find is that most organizations in a transformation end up needing some level of hybridization or what we call often compensating controls. It’s a little bit like if you’re going to renovate a building, you put scaffolding around it, and then as you renovate the building, then you can take the scaffolding down. And in some ways safe is a compensating control for dealing with organizations that have a lot of dependencies. I actually think in dean’s effort to I’ll say bow to the agile gods a little bit, there’s a little history there. It’s probably a little too light for some organizations. There’s some organizations that I think are doing safe in too lightweight of a manner because they bias us more towards the blue and less from the red and they’re not as explicit enough on dependency management.

If you’ve got a lot of dependencies, the best that I think that you can hope for in most organizations right now is you could probably do some scrum, you can probably do somet level stuff, but more often than not, you have to put some pretty rigid queuing systems and requirements decomposition and try to do some small batch planning around them. But there is a tremendous amount of effort that goes into orchestration and companies that are trying to do agile with dependencies. It is doable, but it’s heavier and safe. So, if you don’t like safe, break your dependencies because you probably need more than safe is telling you to do there.

Organizing for Collaboration

So what I’m going to talk about a little bit are some of the patterns and ways of thinking about things that we’ve explored over the last 13 years at the risk of even expeditions and base camps.

And I’m going to introduce an idea that I’ve talked about over the last few years called summits that are interesting. What I want you guys to draw from, it isn’t my language, but draw the principles from it. I changed the language and different clients of ours use different words, and so there’s nothing magic about the language. This isn’t a branded methodology. It’s a approach and a way of thinking that we have found pretty valuable. So there’s typically four classes of teams that we look to form in an organization. So almost any organization that we go to is going to require if there of any size, some sort of shared component, anybody like working an organization has a shared a p i you call or a service that gets consumed by more than one application, something like that. That’s typically what I’m talking about with the idea of services team Dean talks about in his first safe book, gosh, 10, 12 years ago or something like that, maybe it was a second safe book.

He talks about the ideas that at some level of scale and the reason I’m ran this is you quoted me, so this is his book, but it’s my quote. He talks about at some level of scale you’re going to have to have some sort of a component architecture. You’re not dealing with a single application. And so again, this came from for me was back in my financial services days, we were building complex apps that had web services, backend reporting engines, all this different kind of stuff. If you look at some of, I was out in Sweden a couple years ago listening to some people from Nokia talk talking about the complexity of using agile and a cell phone world. Almost anything that we’re doing of non-trivial complexity is going to require some sort of services orientation, some sort of component architecture. So just get comfortable with the idea that you’re going to create a team customer is the other parts of the application which is going to happen.

Not every customer is an end customer. Sometimes you have system actors at play, so that’s a pattern. You can come up with 18 different ways to name it, different instantiations of it, but that’s a pattern something shared where it’s customers and other application. Then you have the idea of a product team or a product team for me is like some subset of the user interface that is making a service call out to one of those shared components. It could be a standalone thing, maybe all the logic’s in its own thing, but then up underneath it, maybe it makes a service call to a login or a payment function or something like that where that’s all fairly standard stuff. What we tend to do is we call it a program team. Sometimes I call it a product team. Sometimes customers will have different names for it.

It could be a value stream team under the right set of circumstances, but almost always in the presence of dependencies, there is some group of people that understands how that system works and is competent to do the decomposition, the high level architecture to understand where all the dragons are lurking everywhere and to make decisions about that decomposition in a way that’s smart and it’s prioritized and it’s dependency aware and it’s synchronized and all that stuff. Typically, I like to see that manifest, and I’ll talk about this on another slide as like a Kanban. Sometimes I’ll very provocatively put analysis, design, build, test, deploy, because we all know Kanban is just waterfalls, small batches. I say that actually I wrote a post to that effect about 10 years ago, and David reached out to me and said, I want to be mad at you, but your post was right, because at the end of the day, analysis, design, build test, deploy still exists.

We still do analysis, we still do design, still do bills, we still do tests, still do deploy, but we want to do it in much smaller batches than typically we had prior to agile waking us all up. So a program team for me is the team that kind of shepherds the decomposition, prioritizes the build, manages through the integration and facilitates deployment in again, two to four week batches possibly, right? Because a lot of times dependency laid environments, continuous integration, continuous deployment is a little bit way off. The last team that I call out, sometimes this gets split into two. It’s like a portfolio team and investment team, but somebody’s got to make economic prioritization and trade-offs in the face of scarce resources. Does anybody have unlimited resources to build whatever you want?

Okay, I can’t tell if you guys are just not raising your hand of the way I asked the question, or if you guys just don’t raise your hand. Is that an Indianapolis thing? Most places people raise their hands time. No, but all kidding aside, right? It’s like companies don’t have infinite money to do all the things they want to do and they don’t have infin capacity to deliver. So somebody’s got to be responsible for making change or making prioritization decisions. That’s what I’m talking about. And so what tends to happen? So think of that as a pattern, a small group of people that get to understand what the markets are doing and understand what the board wants to do and what the investments are looking for and what the RI is supposed to be. They want to understand what their OKRs are, what their KPIs are, how they’re going to manage to those, achieve those things, and they’re going to turn those things into epics that get decomposed into features.

The features get decomposed into stories. There’s a traceability and there’s a hierarchy. Again, presence of complex portfolios, dependencies, things like that, right? Okay. So that tends to look something like this in large part. I like to quote my sources. I actually ripped this slide off a long time ago from Ken Schwaber. I don’t know if he meant it exactly this way. I think he meant it more in a large scale scrum kind of way, but I tend to think of organizations as nested teams. Teams within bigger teams within bigger teams, and then as you start to nest out, that’s where the program and portfolio and things like that. So encapsulation and orchestration at every level of the enterprise.

The Role of Governance

Now, this is what I think about when I think about governance. So a lot of times people don’t like the word governance because how governance is typically used.

The way that I think of Scrum is it’s a governance framework for a single agile team. Think about it describes how that team’s going to work, it describes what they’re going to do. It describes how they’re going to operate. It describes how they’re going to measure progress. It decides how they’re going to make trade-offs. That’s governance. So Scrum has a governance, okay? Safe is in effect a governance model in the presence of dependencies. And so what I prefer is Scrum or Kanban at the execution work surface level and then some small batch program, product level governance that basically takes a feature two to four weeks, something like that, collection user stories and then runs them through some sort of visualization technique that lets us understand, understand because sometimes we’re doing analysis and design and look ahead. One of the biggest challenges, and if you guys are doing this, I just encourage you to stop somehow we got in our head an agile that we don’t do any planning until we show up to sprint planning.

You guys know that the product owner is supposed to bring a prepared backlog, and that doesn’t mean that they just wrote a bunch of shit the night before. It’s like they’re thinking about their markets and their customers and they’re interfacing with the technology. There’s something that’s happened in there that isn’t just right in user stories. And so at scale, that product owner metaphor gets expanded and it’s basically define the feature, do the story mapping, do the release plan, all that stuff. That’s all I’m really talking about. But this idea that if you plan anything in agile, that it’s not agile, it’s agility that we’re looking for small batches, getting things in front of customers frequently. Agile isn’t no planning, it’s responding to change over following a plan. It’s understanding much of the planning is wasteful. I think you can go too far and it’s wasteful not to plan.

A team needs three to four sprints of ready backlog in my opinion. Outside of that, we start to see defect rates go way, way up. So walking in the room and going like, what do you guys want to build this week? It’s not good strategy. It’s just not. And then that gets subordinated to a portfolio. What is a portfolio? Well, so typically it’s like everybody gets in a room, they come up with a three to five year plan, and it’s all these detailed Gantt charts. It’s just a prioritized list of ethics. I did a podcast, I guess it wasn’t technically a podcast. His marketing team, Stephan recorded it for us where I was talking with Andrew Young, one of our consultants when we were talking about OKRs and KPIs, what OKRs and KPIs are just big stories at the end of the day, right? KPIs are like the stories that we use to acceptance criteria for how we’re going to run the organization.

OKRs are basically the new stuff we’re going to do to advance the organization telling it’s all same stuff and agility comes from smaller batches. So at the user story level, couple of stories of sprint feature level, couple of stories a month, quarterly level, couple of epics a quarter or something like that. It’s all about batch sizing at the end of the day. I told this one executive I worked with that he’d be halfway to his agile transformation if he just stopped approving something over three months and think about that, right? You want to forcing function for your organization. If you’re a C-level person, don’t let your team build anything longer than three months and they’ll bitch and they’ll moan and they’ll tell you why they can’t and why that’s inefficient and all these different things, but then they’ll figure it out. Okay, halfway there just with that.

The Role of Metrics

Okay, so measurement and accountability. This is another thing that kind of gets in the way. It’s not like we’re agile, we don’t measure anything. I think one of the greatest sins of the scrum guide from the scrum alliance was a couple of years ago, 10 years ago, time flies. They took out the idea of a sprint commitment. Anybody still honor the sprint commitment? Have you signed up for this many points? That’s so many points you deliver, right? And so this idea of a sprint suggestion or a best effort, the guy that taught me this almost 20 years ago now, he said, this is the way I described. It’s the beauty of the sprint commitment, the beauty of the team getting to decide how much work they do, they’re accountable for the work that they sign up for. Now if they signed up for too much, they don’t have to keep doing that, right?

Yesterday’s weather and all those kinds of things, stable velocity, sustainable pace, all that kind of stuff, they don’t have to keep over committing. But we’ve given up on the idea of a commitment because we gave up on the idea of teams. We gave up on the idea of building backlogs and we gave up on the idea of forward planning. And if it was your $8 million, you’d want a little bit of an idea of what you’re going to get from it. So again, the goal that we’re trying to do, and so I’ll anchor us back to our theme, it’s like we have to have a credible strategy for delivering the red side of culture and to create the conditions in doing so for the blue side of culture. So think about it, right? If I have a team that has everything and everyone necessary, I can do all the agile goodness inside that team.

They have a backlog. That’s their interface to the rest of the organization is defined by the product owner. They have a responsibility to produce a working tested increment at the end of the sprint with a stable velocity inside. They get to do whatever they want as long as they adhere to the interface with the rest of the organization and the middle team. The middle teams make decisions that are cross-cutting. They disambiguate the portfolio, they make the things that the team doesn’t own very real. They remove more of the organizational impediments. They’re incredibly empowered to go out and to think ahead and to plan and do all these things. And then they cascade down. They give constraints to the teams underneath them. So the teams underneath them get to decide. These guys get to establish the boundaries. These guys get to make the economic prioritization and trade-offs. These guys get to decide the strategy. And so we build systems of teams. We build systems of governance. We build systems of metrics that enable us to have a culture that we want. Again, I don’t think what we’re saying is we want a free for all on this.

Iterative and Incremental Change Models

In other iterations of this kind of a talk, I’ve done things where I’ve tried to help visualize what does it take, and it gets into this idea of expeditions and base camps that we were talking about before. So I’m not really going to go into that, but I’ll give it a little bit of nod to it. The challenge that we’ve got is that enterprise transformation, really large scale. And here’s another thing just to kind of call out. It’s like if your definition of agile and doing agile is a small team doing stuff, cool, you can disregard everything else that I’m going to say on this talk. But if your idea of doing agile is like how do I create an agile system of delivery for an entire enterprise, then what I’m going to say matters. So the challenge with enterprise transformation is it isn’t just a team level sport.

And so a lot of times we get really hyper-focused as Agilists and conferences like these on agile team level delivery. So that’s just the delivery side of things. But product management is often its whole thing strategy. That’s a mouthful, but how do I take my strategic intent and cascade it down into the organization so that the leaders who are ultimately accountable for where this product goes in market have a mechanism for making sure that they’re able to do so? Budgeting and funding matters. These things. Sometimes we get frustrated with the people that put financial controls around us, but at the end of the day, most of the organizations that you guys are in have external stakeholders, whether it’s privately held or whether it’s publicly funded and you’re accountable for certain things. So you get certain money put in, you’re expecting certain performance on the backside.

That’s the reality of it. And the leaders, I want to say Sarbanes actually, all these different laws that came in over the last 10, 15 years, it’s like those, the C-level people are held accountable for making sure that they are good financial stewards of the resources they’re put in, the idea that every team gets to decide their technology. Most technology and architecture decisions happen at the enterprise level. These are strategic decisions. And then you have compliance and controls. How do we know that we’re making good use and being good stewards of the resources that we’ve been given? Talent and culture obviously, and this is still I think, a largely unsolved problem in our industry. We bounce against it all the time, and there’s some things we come up with that I think are interesting, but how do you handle progression? Entitling and salary increases on teams of very flat, cross-functional, shared accountability, shared ownership kind of things.

There are some really interesting things around job titles and holding people accountable in different rules. A lot of states in the US or right to work states, but you go into Europe and things like that, or you go into a unionized environment, it gets really complicated and the talent culture side pretty quick. And then also giving the leaders and the organizations new levers for running their business. And that’s another thing that I think we’re really, really poor at as an agile community, is understanding that the people that are higher up in the food chain than us have a certain fiduciary responsibility and we need to give them levers. If we don’t like command and control, then we need to give them some different levers. Otherwise it’s a very red kind of thing. So this is where I’m going to talk a little bit about some of the things that we’ve seen on the transformation front, and then we’ll see if we can start connecting some dots.

Back to where we started with the idea of culture. So 10 years ago, something like that, 7, 8, 9, 10 years ago, we were trying to figure out how to disambiguate some things with a client and trying to figure out how to communicate intent, put together a little bit of a customer, a little bit of a roadmap. And so we came up with this idea of expeditions and base camps. My kids were in scouts. We did a lot of backpacking and hiking. During that time, I became kind of obsessed with the people that were climbing Everest. Anybody ever climbed Everest? No desire to climb Everest. I like my toes. I like my fingers. Don’t want to be a frozen corpse on top of a mountain. But I was fascinated with the people that like to do that stuff. So that’s what was going on in my brain during all this time.

And Dennis and I were sitting in our house, our house, my house, my office, and we were discussing the idea that phasing a transformation, the idea of phases became very overloaded. And so it’s most things with how Dennis and I collaborate. I got really frustrated, went off, thought about it for a little bit, and I came back to the idea of base camps. And what I was trying to articulate with the Basecamp thing was when we do transformation work, we have to accept the fact that it’s a journey, that it’s a process, and that we don’t get to go straight to the end on day one. It’s almost like if we wanted to get physically fit, I got really unhealthy probably the last time you guys saw me. It was probably five suit sizes bigger. Getting healthy is a journey. Staying healthy is a journey, but getting healthy is a journey.

You can decide you want to be healthy today. You can change your habits, you can change your behaviors, you can change your beliefs, you can change whatever, but the process of getting healthy is a much longer thing. And we have to be respectful of the intermediate states that we have to go through in order to get to a state of good physical health. It’s not just your on the cover of a magazine and super healthy fitness model on day one, right? So the software version of that, what we found is if we can just get predictable using agile methods first, we’re in the game.

Even a not perfectly formed scrum team in the presence of dependencies with enough forward planning and orchestration can use Scrum established stable velocity against an known backlog. You guys have to appreciate that is a huge win. All your friends will tell you you’re not agile. You ever seen that overweight person jogging down the road? I mean, they’re doing what they can, right? How’s that guy? So you’re not agile, but you’re getting there, right? You’re using Scrum, you’re introducing a team-based metaphor. You’re doing backlogs, you’re doing all these different things. You’re can make and meet commitments, and that’s really cool. Okay. The next one after that is, okay, how do we start to reduce batch size and start get more predictable? That means we have to start reducing the size of things that get approved in the backlog. We have to start breaking things down into epics.

We have to start breaking things down into features, have to get them into user storage. We probably have to change some of the release management stuff. We might have to think of DevOps and CI/CD, but now we’ve become predictable. So we can go to the organization and we can ask for more agency, more permission, and we say, okay, let’s start to figure out how to make this stuff go smaller. Then you’re going to hit a wall. This is wall we hit about four or five years ago with a lot of our clients couldn’t help ’em go any faster because their technology dependencies were just overwhelming. Encapsulation issues, orchestration issues, all the solid principles, all the different things, services, orientation, moving to the cloud, all these different things were killing their ability to actually be agile. They were brute forcing the predictability with Agile. They were doing things that maybe create a little cognitive dissonance to operate in small batches, but man, they were starting to get things in market quicker to really start to go faster. And to really be more agile, you have to start thinking where the seams are in the organization or in the technology and start to break the big things into little things.

What we’re starting to see with a lot of our clients is this thinking informs business architecture. It informs your domain design. It informs how you’re thinking about moving things to the cloud, how you’re thinking about deprecating costs, how you’re thinking about technology modernization and uplift, how you’re thinking about justifying technology spend by tying it to the business. I’m telling you, you start to go down this rabbit hole of breaking dependencies and increasing encapsulation and better alignment with the business. And for us, it was really difficult to get to a place we could have those conversations until we said, Hey, look, we can make and meet commitments. We can put things in market faster. You want to go even faster, you want to be even better. This is what you need to do. And then this space camp for idea, the idea of team or we had a lot of debate internally.

When I say fund teams, I don’t necessarily mean you fund a persistent scrum team, but it’s like this whole projects to products conversation that people have. It’s like, yeah, we don’t want to fund projects which are transient tokens of investment. We want to fund products. Well, what is a product? A product is either a team or a collections of teams. It’s something of encapsulated value. The reason why we can’t get to product-based funding is because the way we think about injecting dollars into the organization is variable. The dependencies and the way we deploy resources across the organization is incredibly variable. So when I start to get into an organization where I have encapsulated dedicated teams that I can start to feed requirements into and can now make and meet commitments on a regular cadence, then I can start to say things like, okay, I’m going to give this group of teams persistent annual funding and let them go solve problems.

The other thing that’s interesting about this is that when I have teams that are encapsulated, I can actually make the decision that I don’t want to work on that product anymore and I can go put that capacity onto a different part of the organization. Not everybody’s that fungible, but it’s possible at that point. Some of the things Jurgen Appelo talks about, and I hope I’m not misunderstanding, but dynamic allocation or resources across teams. That’s a little beyond some of the stuff that I get into, but you could imagine if you had a persistently funded organization, you could just dynamically allocate people across things. All that stuff is really, really difficult to do if we don’t have encapsulation, if we’re doing dependency management, if everything is role-based. But when we started thinking about the organization in terms of what it builds and -unintelligible-  and stable throughput and all these different things, it starts to open up a world of possibilities for us.

And then the last bit was invest to learn. And one of my stories behind that was this idea of, we went into a financial services organization probably eight or nine years ago that was really getting decimated in market by a competitor. And I don’t remember quite the order, but I want to say the competitor had 30 people assigned to their product and they had like 4,000 people assigned to their product. I mean, it just wasn’t even close. And they’re like, the product person is like, we need to be doing Lean Startup. And I’m like, you are going to screw those people if you force them to do lean startup stuff. I mean legacy mainframe, no encapsulation, traditional project planning. What are they even going to do with a lean startup mental model? But imagine a world where I have an encapsulated product business problem, business architecture with encapsulated technology, a dedicated team with a dedicated funding.

When I have that, now I could go to that team and say, Hey, this backlog we’ve been working off of, forget it. I want to point you with this market problem. Why don’t you go disrupt that competitor? You don’t have to do that, but you could. How we handle that now is we basically go buy a company that’s actually a thing, or we go create an innovation hub or we create a group of people on the side or what have you. And you can do that too. So if anybody’s familiar with my little four quadrant story, I tend to make the case that when you’re in chaos in a legacy organization in the upper left and you want to go to this really high performing Basecamp five lean startup kind of team, you either have to go create it from scratch or you have to go through the process of untangling it.

And the presence of dependencies and the presence of malformed teams and the presence of all the things we’ve been talking about, introduction of practices and culture, it doesn’t work because it hits the reality of the environment that you’re in and the reality of the environment that these people in will win. Okay, just will. Now, this top thing, this summit thing is something we were working on a client a couple years ago that was mega big, like 13, 15,000 people, hundreds of expeditions, all moving to different base camps. And when I invented the first underlying part of this, the base camp story, I can deal with a tremendous amount of ambiguity. I’m just a very abstract thinker. I don’t need things to be specific. I’ll work out the details when I get there. But as you might imagine, not everybody in the world’s quite like that.

And so a lot of the folks on my team, this one leader in particular, were like, well, are you telling me it has to be, it’s very linear. It came from a coding background. Does it have to be team business? Does it have to be this? Does it have to be that? Well, what if I can’t change these things in the organization until, so we articulated the story, which I think is true in a lot of cases. It’s like a lot of times you have to do the product delivery transformation before you can get the funding models changed, before you can get the compliance changed, before you can get the enterprise architects to change. And so the way that we would think about it quite a bit was we would be doing expedition work down here at the delivery level. And by delivery, I don’t mean just team, team portfolio, even up to sometimes OKRs, things like that.

But we would operate with an exception with the rest of the organization. So we’d basically get permission and we’d have to almost create an interface or an abstraction layer between what we were doing at the work surface, at the product level from what we were doing with the rest of the organization. And then once we had critical mass at the execution level, then we would start dismantling the abstraction layer and plugging it directly into rebuilt interfaces up at the top level of the organization. So if there’s any architects in here, people that are used to doing large scale systems, architecture, cloud, migrations, different things, you’ll recognize the language, right? I’m not an expert in that. It’s not my thing, but you’ll recognize the pattern, right? And so you put in an abstraction layer, change all the things up here and then start stitching it together and making them interact or keeping the abstraction layer if you need to.

But that’s the general idea. So sometimes enough level of scale, you have to get enough critical mass in order to be able to change the way that the organization like truly financially governs itself.

Culture and the Power of a Trustworthy System

It’s funny how everything ties back to these really early formative stories. When I went out on my own, convinced my wife that starting a company and going out as an independent consultant was a good idea. My wife’s a saint by way, so you guys thank her for me sometime. But anyway, when I thought that was a good idea, this little client based in Atlanta, they had an office in San Francisco and they were about half my livelihood during that time. And the CEO came from San Francisco to the Atlanta office where I was. And he goes, how can I support this initiative? And I had this flash of brilliance, and I’ve used this line so many times.

It’s like hold the teams accountable for being trustworthy and then trust them. Once they can communicate to you their throughput, you don’t overload it. And that’s the dance that’s happening. You want to be trusted, you have to become trustworthy. It’s a very red and blue thing. Trust is kind of a blue thing. Trustworthiness is kind of a red thing. So if I want to be trusted, if I want to be empowered, I have to be able to do what I say I’m going to do. And so there’s a little bit of that bridge at mega scale that I’m talking about here. If you’re a product organization that wants to be trusted, you want your CFO and your board to dismantle the regulatory and compliance controls, then you have to demonstrate to them a better way of getting them what they want. So I don’t know that I’m married to these different descriptions, but we’ve played a lot around with the idea of how would I create a metaphor between one or the other.

Once my systems are fully trustworthy, then I can start to change some of the governance, audit, compliance, things like that. Once the system is trustworthy, I can start to think about how to ask the organization to make smaller bets in market and less longer term commitments. There’s a huge thing. This third one is interesting to me because has anybody tried to do value stream analysis on their organization? Is that an exercise you guys have gone through? Well, is anybody who’s done that, it’s like value streams kind of intersect and go around the value streams aren’t encapsulated. Well, everything in Agile is about encapsulation. Everything about the way safe talks about value streams and sums encapsulation. And if the value streams aren’t actually encapsulated, what do you do? Well, with this one particular client, what we were doing, which is really fascinating, is we didn’t organize around value streams, although that would’ve been ideal, just too complicated.

And the organization could not see that far ahead and they couldn’t conceptualize how to do it. So what we started to do is we started to organize around business capabilities. And the challenge when you organize around business capabilities versus products or value streams or something is you end up with a lot of orchestration costs. But what’s cool about it that the teams are doing all the cool agile stuff and all your orchestration costs get exposed outside where the actual work’s done. And you can start to see where the cost of dependencies is really high and where there’s high level of dependency and orchestration. You know what that starts to do? It starts to imply value streams because the things that have a lot of dependencies between them tend to need to be grouped together. So it’s almost like a, how do you move from something and then that’s not really value streamlined to something that is value streamlined.

And now once you get it that step closer, you can start to articulate and start to think through, well, 80% of my dependencies are here, but I’m doing all this orchestration with this bit over here. Maybe it would make sense for that to have a little bit of duplication over there. Maybe it doesn’t need to be the same thing. And so now we can start to have really informed conversations about where to deploy resources, where to allocate capital, what have you, to start thinking about how do I increase throughput? It’s just really cool, just very nuanced stuff. But what enables it is thinking about it the right way.

If you’re a leader, it’s like you can’t just go to your teams and say, I trust you. Go figure it out. They’re not organizational design people, they’re not all systems architects. They, it’s just interesting. So what we’re starting to tease out over the last 13 years is that there’s a way to think about this that respects both sides. I get the culture at the team level, but I respect the system of delivery that works around it. And I recognize that that system of delivery takes a minute and it’s a stepwise process. And as Agilists, we can’t say we like to wield that. That’s not agile, right? Oh, that’s not agile. Well, okay, dependencies aren’t agile either, but they’re there, right? And it’s just interesting. So we just have to be as agile transformation people. I think we just have to think about this really pragmatically at grownups and just go, what does it really take to get there?

If I were on the hook, and that’s the interesting thing about approaching it from a consulting perspective. If you guys don’t like us, you just fire us. We’re done. You guys have some protection a lot of times being internal people, but not always. We’re starting to see a shift away from coaching and things like that in the marketplace. And again, I think it’s because we just haven’t gotten clean enough, we haven’t gotten precise enough about how to do some of this stuff. So just to kind of drive that point home a little bit, it’s like for us, the work, when you hear me talk about expeditions and base camps in more organizations than not, and again, sub couple hundred people, you can kind of do it all in one thing, but you get much more in a couple hundred people and you’re into the thousands, you’re ended up splitting.

So for us, expeditions are really at the delivery level. And the summit is like, it’s really asking yourself, what do I do with everything else that isn’t product delivery? And do I have a plan for stitching those two things together over time? So Dennis, if anybody knows him, he asked me to put this in this talk. And so it’s a little bit like this is another way of saying the red versus blue thing. It’s like if we want to create a culture of empowerment and trust that’s open to fun and all those different things, then we have to have a system to do that. And a good system to do that drives clarity. We have everything that we need. We have mechanisms to make sure that the system is competent to deliver what it needs. It has the capacity to deal with what it needs, and that there’s a measured system of feedback so that we know that we’re getting the right results.

And within that container, I think there is a tremendous amount that we can do to drive the cultures that we want to have. I think we are all grown up enough to know that it’s not a free for all. People aren’t going to work solely to self-actualize and to be their whole selves, although we might want them to do some of that and bring their whole selves to work, and that’s cool. But we have products to bring to market and we have deadlines and we have things to meet. So if we can figure out how to do that dance, I think we have a greater shot at winning. There was a whole thing that we were trying to do for a little bit, and pandemic kind of knocked it out, and it’s been a complicated couple years. We were having this conversation. We called Elevate Agile, and I’ve been in this community, gosh, I’ve been leading Agile for 13, probably was version one, remember version one.

They’re kind of still around I think a little bit. No, nobody, you guys just don’t raise your hands. That’s what I’m learning. Okay, fine. Some of you people I know in this room know version one, right? So I worked at version one for a couple years. It was a company called Fiserv Check Free before that. And I’ve been FL around this world since about 2003. And it’s like I care about this stuff and I care about the people that do it, and I care about these organizations that we go into. And I just feel absolutely passionate that if we don’t figure out how to tell the whole story and deal with all of the different personalities and dispositions and everything and get everybody what they need to where it’s a win-win, win, win, win, win, win, win for everybody. It’s not going to be here for very much longer.

Closing Remarks

That’s just my take on it. So we’re back to where I started. Okay, so I’m going to show you guys the slides that I started with and now you guys will have a more fully realized understanding of what it is that I’m talking about. When folks talk about culture is like the thing, again, my head goes to that story. I told, okay, you’re a king for a day. You get to wipe away any disbelief. Everybody will do what you say, what you going to go do? How are you going to systematically, how are those people that have the revised attitudes, mindsets, beliefs, whatever, what are they going to go do differently tomorrow to get the right kinds of results?

So that’s like the first thing that you have to ask yourself. A lot of us in the room are advocates of practices, right? We’re safe certified, we’re Scrum certified, we might be less certified. We have our PMI ACP, we have our PMPs, we’re process people. The interesting thing about Agile, and this is when I was sitting in the room on the, I was part of the original group that did the PMI ACP with a lot of really smart people, and that’s what I was thinking. I was PMP certified. I was really deep into that for a few years. And then we were building this, and I had gone the agile world and I was doing this PMI ACP. And the thing that I think that made, and I don’t think maybe they do now, but at the time, 8, 9, 10 years ago, I don’t think PMI really got was that the PMBOK is really a set of practices that you can apply anywhere.

Agile requires a context. And if this isn’t immediately obvious, I try to be incredibly transparent. Anybody who’s ever invented a methodology as either a consultant or became one, and we’re all trying to monetize it and make a living, we care about it and we want to do good work, but obviously you got to pay your bills and take care of your families and stuff like that. So everybody’s trying to monetize it, but every methodology that was ever invented worked in a context.

So, Dean didn’t just invent safe, he was doing safe, and he wrote it down. Ken Schwaber and Jeff Sutherland didn’t just invent Scrum, they figured Scrum out on a client or on a company they ran, and then they wrote books about it and created certifications around it. So everything worked. Everything worked, everything works. The trick that you have to understand is that everything that has ever worked has a context that made it work. It wasn’t like the PMBOK where you just pick and choose and it’s like a menu of stuff. Safe requires a context encapsulated value streams, large scale Scrum. If you ever read Craig Larman and Bas Vodde’s work on that, there’s this line in one of their first works where it’s like, yeah, you got to break dependencies and encapsulate stuff and put things in CI/CD pipelines and everything. Yeah, it’s going to take you years, but just stick with it.

And then when you’re done, you can do the rest of the book. I’m being a little flippant, but that’s kind of the gist of it, right? Okay. I think Large-Scale Scrum probably has, it is right. Probably more right than anything. The reason why it hasn’t been adopted, at least best I can tell at a greater rate is because it’s hard. It requires these teaming strategies and the encapsulation issues and the CI/CD and the rapid feedback. They’re right, but it’s hard. How do you get there? Learned a lot from Sanjeev early work. I’ve learned a lot from Jim Highsmith, learned a lot from Alistair Coburn. All these guys are brilliant and they’re all really good, genuine people that solved some really hard problems for clients and made their stuff work. But you have to get up underneath and ask, what was it about the environment that made those practices work? It wasn’t just the practices, it wasn’t the culture. It was the underlying organizational architectures that made it work. So when we walk in to an engagement or I’m talking to somebody on the phone that might want to work with us at some point, pick your methodology, they’re all fine, right? The idea is is think about the culture. You want to have the performance characteristics that you want in that enterprise, and you design for both of them.

Focusing on just one or the other is not going to do it. You got to bring both. And so if you guys have me back in a couple years and I do this talk, there’s going to be four things that I’m going to do. I’m going to do red and blue, and I’m going to yell and white because having fun and I don’t like following rules, but there’s a place for it. And getting things done and being connected as human beings, all that stuff matters. So we have to do is we have to build systems that create the conditions that we want to work in. And it’s hard. And so that’s what I like to do. I like to figure out how to get from point A to B. I think I’m out of time. Might’ve just nailed that. I was like within a minute. Wow. Okay. So all my storytelling worked out. Awesome. Great guys. Thanks for having me. I appreciate it.