Damon Edwards

The point of this, we're trying to make it a conversation and not a panel. We're four guys who aren't a fan of panels, but we're actually doing a panel, so hopefully we'll be better than your average panel.

The point of this conversation we want to have here is about: in enterprise, external help is a fact of life, right? Obviously, a lot of conversation is about, you've got to raise the internal capabilities of your organization. But in an enterprise, whether it's, "I need fresh ideas," "I need more bodies," whatever it is, external help is a fact of life for all of us.

And we know it can go extremely well, and we also know it can go extremely bad, right? So the point of this conversation, not a panel, is about how do we get external help? When does it go well? When does it go bad?

I think we've seen a lot of companies by the nature of our professions, so we want to be as honest as possible and talk about the failures and the successes. And we want to make this as interactive as possible. So we've got a couple questions to kick it off with these guys, and then after that, if you've got a question along the way, just raise your hand. There's only, like, 30 of us, right? So just raise your hand and shout it out and we'll get to it.

So let's start over there with Marcos. Like all aspiring musicians, Marcos went to work for Accenture, right? He's been there for 11 years. He's going to go back to rock and roll someday. And he's focused on the whole SDLC, configuration management, infrastructure as code, continuous delivery, all that good stuff, and runs a team of 250 people, but still finds time to write code.

Then we've got here Steve White. Steve runs Contino's CIO/CTO advisory practice. He's been at it for 17 years, working in the leading technology teams, working with large enterprises, doing Agile, DevOps, technology transformation work, all of that good stuff.

Ben Grinnell right here is the managing director at North Highland, where he spent the last 12 years building a 300-person business here in London. He's also spent three years walking the talk as a transformational CIO of a major government department serving 25,000 employees. So good breadth of experience here.

I'm Damon Edwards, by the way, managing partner of DTO Solutions. We do similar Earth-like things, big enterprise stuff.

So for each of you, just kind of want to go around the horn here, have a couple questions. One is, what are your top two leading indicators of when a transformation is going to be a success? What are the two things you look for to say the commonality between organizations that are successful, to know, "Oh yeah, I see that. I think we're going to have success here"?

Who wants to go first?

Steve White

I'll take that first.

Damon Edwards

Dave.

Steve White

Hi, everyone. Steve White from Contino.

I think for me, the two things are primarily you've got to have executive-level buy-in. You can't just, as a small technology team within a large organization, decide you're going to go Agile, you're going to transform, you're going to launch code straight into production, unless you get that exec-level buy-in.

Number one, for me, it's having a C-level buy-in to technology transformation, digital transformation across the organization.

And the second one is, when you've decided to do it and you're actioning it, is to get the communication right. If you get the communication wrong, people think they're going to lose their jobs, they think the company's going to go bust, they don't understand it. You've got to have regular communication.

And when you've told the same thing three times, then you're a third of the way there with communication. Someone said that earlier today. It's a good point. The more you have to say and repeat and get the message across to the teams that this is a change for the positive and not change for the negative.

Damon Edwards

So before I move on, you say executive buy-in. What do you mean by that, right? So executive says, "Well, I hired these consultants. Go do it. I must be bought in," right? What is the difference between an executive who's bought in and not bought in?

Steve White

For the best success, you need the entire executive team, from the CFO, COO, to buy in to this change.

I'm doing some work at Barclays at the moment. The entire C-level team have bought into it. In fact, they're incentivizing every single employee's bonus by getting them to adopt Agile strategy and bonusing on how fast they do it. That's executive-level buy-in.

Damon Edwards

Okay. Marcos, you want to?

Marcos

Sure. Thanks.

I think, "Is the transformation going to be successful?" is kind of difficult, because does the transformation ever stop? I think everyone's still on a journey.

If I can change the question to how you know you're going to get off to a good start: bad starts or good starts come from good scope, from what I've seen.

I've heard people say if you're going to try and do Agile, you need to try and implement it in an Agile way and start understanding that mindset straight away. One of the things about DevOps and trying to do DevOps in a DevOps way is about fast feedback.

So if you get the scope nice and small to start with and know what feedback you're expecting to get, it helps you to kind of get into the mode of learning with DevOps.

And the other thing about the scope is it's got to be something real. So if you start with something that's too theoretical and has no kind of material interest on an actual product or something that's going live or an existing project, then it will be hard to integrate. It's got to be kind of tied into something that's meaningful, other than just trying out a bit of DevOps.

Damon Edwards

Ben?

Ben Grinnell

I would've said the exact same one for the first one, which is the executive-level buy-in. And I'd define that as just that whole group understanding, really, the Three Ways. So it's that level of understanding.

They understand that you're trying to shift left. They understand that you've got to close that feedback loop with your real customers. And if they get that, then that's probably all they need to understand, then give you the buy-in to do that.

And then the second bit, and I've seen a lot of failures in this instance, is you can start small, but you've got to have the appropriate parties at the table. So you've got to have business there, you've got to have dev there, and you've got to have ops there. And quite often I see two out of three ain't bad, but it's rubbish. Doesn't work.

And if you've got an outsourced environment as well, then you've probably got to add procurement and have all four at the table, because without one party that isn't bought in, it doesn't really get going.

Damon Edwards

Yeah. So how many people here struggle with the executive buy-in concept?

Quite a number, quite a few. Okay, we're going to come back to that one. So that's a good placeholder there. A little teaser for later.

But before we do that, I want to do one more of these kind of around-the-horn classic panel questions that we hate so much. But let's talk about the flip side.

I'm sure not you guys, but there are a lot of projects that fail in the world, right? I'm sure all yours are very successful. But of any you've seen, what are your leading indicators of failure?

One of each, right? One being, going in, how do you know a company's not ready? Whether it's buy-in or some other thing. What do they not have that you go, "This is a red flag in my mind. We're walking into a bad scene here."

And then number two, once work is in progress, what is another red flag? The work-in-progress red flag to say, "We're in trouble here," or, "I think things aren't going to go well."

Who wants to go first to talk about indicators of failure?

Ben Grinnell

So I think one of the things we've seen with all the talks you've heard today, and all the ones you'll hear at things like this, is you've got to take an Agile approach to your transformation.

So one of the things I see as failure is when the mindset of the organization isn't there. So they'll hire a bunch of consultants, and maybe that's me, and they'll ask me to draw up a detailed operating model of what the destination looks like.

And if you ask any of the people on the panels that have been through that journey where they are now, whether they thought they would get there 18 months ago, they would've drawn a completely wrong model.

So you've got to take an Agile approach, and a lot of people who are trying to get on the bus aren't comfortable with that approach. So they want to know where they're going before they start. And you've got to get them comfortable with, "We're going in that direction."

Steve White

I think for me, similar to what Ben said, you can't do transformation without cultural change. It's not just changing processes, tools. You've got to actually change your entire culture, the way you think about things, and reorganize your teams accordingly.

So that might mean moving product from one country to another, or person from one country to another. You've got to have a much more holistic cultural change to make it a success.

The other point where I've seen things fail in organizations is that initially there's a big charge, "Let's transform. Let's go for it, guys." And then there's no investment. And that investment doesn't necessarily need to be money. It needs to be time, people, tools, money, the whole lot.

You can't under-invest. If you under-invest, the project will stall, the transformation will stall, it will lose momentum, and it will fail. You've got to give it a big kickstart with all the resources to get it going, and then the ball will roll down the hill on its own.

Marcos

I think for me, things are going badly when you're establishing or ingraining another silo. It's really sad. There was a lack of particular automation before, and then that got created, which is through some early progress. But if that's in a different silo, it's going to be rejected. It's going to be violently rejected by those people that should be part of the journey.

So when it starts to become its own thing, it's theoretical, it's in the lab, it's potentially giving good things a bad name, which is pretty horrible.

Damon Edwards

Yeah. So I want to go back and talk about the leadership issue or the issue of trying to get the senior executives.

The folks that raised their hands, does anybody have a good example, or what's the common refrain you hear from executives that you have a hard time getting buy-in from?

When you raised your hand, what were you thinking about? Was it they don't believe in it? They don't think it's real? They think it's somebody else's problem?

Audience

I think what's key here is that they think it leads to chaos.

Damon Edwards

Ah, okay. So the chaos. So they're afraid of, this doesn't seem controlled and rigid enough.

That goes to, I think, the point you were saying, Ben, about there's the issue of they want to see the perfect plan, 37 steps out, five-year plan, the budget. "Tell me exactly where we're going to end up."

How do you address that? So you talked about the need to be more Agile and/or more iterative, I guess we should say. How do you address that? How do you get them to see that when that's not how they operate today, and you're kind of coming from an outside position?

Ben Grinnell

Well, I think the problem with starting with Agile, a lot of companies did before they started doing DevOps, was they started with Agile on the things that could fail. So we ended up with a situation where most of the executive believes where they can afford to take risks, they can do DevOps, and where they can't afford to take risks, they won't.

So I've seen several companies set up a fast lane and a safe lane. And everything we've heard today is regular small deployments are safer and more reliable. So you've got to get that into the mindset, because people still believe that Agile is what I do to have a sandbox and to play around, and that's the risky stuff, and I'm not going to touch my big infrastructure with that. And getting past that myth is quite hard.

Damon Edwards

Yeah. So Steve, you said that organizational buy-in of all the executives. Can you get a little deeper into that in terms of, what is the buy-in? What's the level of buy-in that they need? And what are the biggest oppositions that you, or the biggest stumbling blocks or impediments that you see to getting that buy-in? What are they afraid of, I guess is the question, right?

Steve White

Going back to your point earlier, they're afraid that they're not going to see the big Gantt chart with a date and how much they're going to spend. It's more a leap of faith. Even though they know, well, we think we're going to deliver better results faster, they don't necessarily believe that.

So I think one of the ways we've done it in Contino is do lighthouse projects. We'll take a failing project or a failed project, and we re-initiate it and redo it and deliver it, and then we roll that to another project. We measure KPIs on it.

And then after a while they think, "Oh, actually, this way of working is a lot better than what we're doing over there. Can you guys go and do that project?" And then you build up a bit of momentum, and before you know it, they're going, "Right, let's all go Agile. Big Bang pro..."

We go, "No, not Big Bang, not silver bullet." It doesn't quite work like that. But you slowly build up the momentum, I think, and you get your proof points. You demonstrate that it is a better way of working, and it can deliver success and return on the investment.

Damon Edwards

Yeah. Someone have a question?

Audience

When you said that the senior executive buy-in is hard to get for a concept like Agile or even DevOps, I have seen people at the very top of an organization being moved into this bimodal thinking. With Gartner, the fast lane and the slow lane that they think of it.

So the big guys, the top-notch guys, they are into bimodal. Whereas we workers, we think we can get going by being Agile, and this doesn't really work very well together.

Damon Edwards

Right. So the question was about the bimodal, that the higher you go in the organization, I guess, or the more detached from the day-to-day work people are, the more the bimodal concept that's floating around, it seems appealing, right?

It's like, "Oh, I don't have to fix that broken stuff. I can just do something new on the side." Of course not realizing that it's all connected underneath the plumbing, right?

Steve White

Yeah, I think it's a little bit dangerous to have, personally, the bimodal way of working because you're undermining the change. If you've still got the old way of working and that's seen to be working, and then you're bringing in this new thing, which will fail at times, then people can say, "Look, this is all working nicely, and you guys are trying to change the world. That's not working as well."

I've seen some senior execs really go for it. In one of the organizations I spent a year at, William Hill, the MD of online wanted the developers to release into production, actively encouraged autonomy within the sales, and said, "Look, guys, you know your product better than me. If you want to release that new feature, just release it. If it goes wrong, it'll be up to you to fix it and keep it..." But that's how far down the road William Hill went with autonomy for teams.

Damon Edwards

Yeah. Marcos, I have a question for you.

So this idea of do a pilot or get a pocket of success always seems a good logical step. But as we know, the greenfield tends towards brown, right? If left to its own devices, the green stuff turns brown, not the brown stuff magically turns green, right? Just sort of the law of the enterprise antibodies.

So I'm wondering, when you have a little breakout success, you try it with a project or a team, how do you get that success to propagate in an organization? Even when, as the gentleman mentioned, you have this kind of bimodal idea going, "Oh, that's great. You just keep doing that with your mobile apps. We're not going to touch our system of record because this is real business," right?

How do you translate this pocket success into a broader program in an organization?

Marcos

Well, I think what you don't do is try to clone it and replicate it exactly. You need to look at how that has been fit for purpose in that particular domain and how people are behaving, and what they've learned on the way, and the decisions they've made for themselves, and then try to provide that empowerment to the new areas that you want to develop.

I think it's a very dangerous idea that you're just going to clone the same thing and it will be fit for purpose. As you say, in the brownfield, systems will have architectural limitations that make things very difficult and can only be changed over time.

But I think a great thing about mode two is the experiencing and seeing it and realizing, we did get there and there's hope.

Damon Edwards

Right. Wait a minute. Go first here. Yeah.

Audience

So pretty much all of the kind of examples that we see are about senior-level executives taking risks. Even in The Phoenix Project, the execs there were prepared to put their neck on the line and take some personal risks.

What would be a top tip when you're talking to a C-level exec to convince them that this risk is worth taking?

Damon Edwards

So the question is, the big success stories you hear about, there is a senior executive that takes on the risk, that believes in it and becomes a champion for it. And your question is, what's your recommendations for how to, if you don't have one, develop it, or foster it, or spark it, how to find it, right?

I guess that's the question. What are you guys going to say to that?

Ben Grinnell

I guess one of the difficult things you've got is you're talking to a senior exec, so by definition, they've already been quite successful at doing what they've been doing, and you're asking them to change.

So I think one of the things is to understand what you're asking them to do and how it can be successful from their point of view, because they might be a senior exec owning a big P&L that they've built up over time. They've done 20 years of their career to get to that point, and you're asking them to tear it all down.

So understand from their point of view, but then just making sure that they've got little successes along the way that you can earmark to them and you can show them.

Steve White

Yeah. That's true. I think a lot of senior executives get there because they're very ambitious. And if you have a steady state, they want to see things move faster, get done better. They see the competition, especially in the fintech world.

Barclays, as I said earlier, know that if they stand where they are today, they're going to get overtaken by small fintech startups. So there's a necessity for them to change. It's a survival instinct that kicks in, I think, in some places.

Marcos

I think I'll just add, you have to quantify or explore what risks they're worried about. They may be worried about getting rid of the person who's in charge of testing and making the development organization accountable for quality.

But maybe that rolls up to the same executives that are reporting into them anyway. So there's perhaps a fear about losing control. You need to explore specifically where that's coming from and see what's actually different.

Damon Edwards

Yeah. And I'm going to add one more to that, which is often your best ally is the business.

And for them, you're like, "Well, how are they going to get involved in this?" Because they're frustrated because it's like a factory. The factory's not visible to them. So they just see requests going in and nothing happening. It costs too much and takes too long.

And if you can make the work visible, so things like value stream mapping, lean analysis. It doesn't matter what's in those boxes. The fact that you can do some graphical storytelling and turn it into basically a supply chain management problem.

So think about that. How do you turn our problems in an organization into a supply chain management problem that doesn't require really much technical knowledge or any technical knowledge to understand, like, "Oh, that's where the bottlenecks are. That's where the bad handoffs are," and to say, "Wouldn't this be better if we could get rid of this, get rid of that, move that over there?"

If you can talk to it in that way, often the business, it energizes them because they can finally see inside the factory for once and they're like, "Oh, I know supply chain management here." This is their MBA brain somewhere from years ago clicks off and they go, "Oh, I get this. I can contribute to this."

Audience

Well, that's about finding a common language. Is that right?

Damon Edwards

Yeah, exactly. It's a business problem. I would say DevOps is a business problem. It's not really a technology problem. Technology is just how we're going to help fix this, but it's really fundamentally a business problem.

If you can turn it into a business problem, that conversation goes easier, and then you start to get that positive pressure back from the...

Steve White

I totally agree with that. One of the little exercises I like to do is draw out a timeline from requirement gathering, "I want to change this feature on this product," to when it goes into production, and then map the time for each stage.

Time to build, time to test, time to do security testing, operational acceptance testing. And then the executive will then start asking questions about, "Well, why does it take two weeks to test that?" "Well, because we're dependent on this third party."

And then when you start breaking it down and say, "Well, can't we lose that third party? Can't we..." And change things, and that's how you can get more Agile practices and then buying into the new journey.

Ben Grinnell

And I think once you've identified what they're concerned about and what their real worries are, it's tapping into the community like this and finding examples, preferably in their industry, of similar companies.

I mean, we're not pioneers in this space anymore. There's people in this room that have done it. There's a lot of research available now. So it's giving them examples that really are playing to their fears of their competitors or other companies in their industry that are doing exactly this and making great progress.

Marcos

I would just add, in terms of the point about control, if that's the fear, I've sat down with a control department in a bank and talked about continuous delivery and pipelines and all of the automation that you can put in there.

And I've sat down with security teams as well to talk about infrastructure automation. And then the penny drops, and they realize the traceability is unbelievable, and they get an immense amount of control, but at speed. And maybe some of the fear that automated robots are going to screw everything up starts to go away.

Audience

Hypothetical question. Obviously not, so...

Damon Edwards

Asking for a friend?

Audience

If you had, say, five business units, 68 product lines across those business units, across a global spread in terms of quite a footprint, and you want to be able to scale DevOps en masse, at speed, how would you go about doing it?

Damon Edwards

So the question is, hypothetically, he's asking for a friend, if you had five different, was it business units or divisions?

Audience

Yeah, five. Yeah.

Damon Edwards

Yeah. So five divisions or business units, 60-plus teams.

Audience

It's like 70 product lines or something.

Damon Edwards

Seventy product lines, hundreds, thousands...

Audience

Thousands of people.

Damon Edwards

Thousands of people. And the light bulb goes off in the organization: we've got to do this, we've got to transform.

Audience

You've got sponsorship from those executives.

Damon Edwards

They go, "Go do it."

Audience

Right. They're, "Go do it."

Damon Edwards

It's a good question. So what do you do? What's your initial pattern that you come in and say, "Hey, here's the steps we're going to take to start doing this?"

Audience

Because everybody says start small and build, but it'll take you 20 years.

Steve White

Yeah. There's no easy answer to that question, but I think I would do the three S's.

So first of all, I'd try and simplify maybe the number of products, if possible. Combine products, reduce the number. Simplify as many things as you can, first of all.

Streamline. Look at all of your processes, touchpoints, try to reduce those to the smallest number you can. Automate there as much as you can. Give autonomy to people and automate using computers and coding.

And structurally, I would look at having your teams structured around the products, your teams' locations, offices structured around the products, not the products structured around the organizational structure and the teams.

So there's my three S's.

Damon Edwards

That's good. I thought the first one was going to be scream.

Ben Grinnell

I think I'd look at if your company's that big and everyone wants to do it, then look at the community. So I'd do it through a process of starting small in lots of different places, but with some managed diversity.

So if you look at the way this community works, everyone's trying it in their own way, and everyone's getting further together by sharing the information and working out what works best.

So you could start small in a lot of areas and just hopefully manage those communities to communicate with each other enough to make sure you grow something faster. But you wouldn't spend six months working out where to start or what the design is.

Marcos

I completely agree. Start small everywhere in parallel, and then you're looking at the balance, I guess, of shared versus sharing. And I would lean towards sharing.

So trying to get a community with all of those different experiments and some kind of correlation of what's working so that you're not making the same mistakes in many places is great.

Trying to get one enterprise automation tool, spend a long time getting it ready, and then push it out to everyone as a standard and manage it centrally, that's what we're trying to avoid.

Damon Edwards

Yeah. I'm going to do a yes-and here.

I think that it's true to start in a lot of places. I think what holds it all together, the glue, is the notion of an improvement system. So if you're going to formalize something in the organization, it's having a formalized system for basically constantly looking at how we work and fixing it, right?

So if you look at some of the lean things like retrospectives, Toyota Kata, right? The whole A3 kind of improvement storyboard ideas. The idea is there's a formalized way to get organizations to have a common way to look at their problems, to talk about their problems, to decide what they're going to go fix next, to go and work on it, to see where they're at, do it again.

And I think across the big enterprise, what does scale very well is to teach everybody a common improvement system, right? So if you look at Toyota Kata as a great book on this. We did a lot of this, we call it DevOps Kaizen. It's like, how do you put that Kaizen or continuous improvement system in place across the organization?

And that's what helps enable and empower all of those little pockets of innovation. So it's like, I agree with something before, instead of spending six months, we see a lot is like, well, the enterprise architects get involved, and they're like, "Well, we're going to design the right DevOps pattern that all of you will implement across your organization."

Instead, look the opposite way and say everyone can pick their own patterns, but we're going to have a common set of principles we want to talk about, and we want to have a common kind of improvement system, a formalized technique in our organization that's going to overlay what we do and constantly be looking at what do we do, what are the problems, how are we going to fix it.

And then that bubbles up to a radiator that executives can see and say, "Ah, I see we're getting better over here and not better over here," and that type of thing.

So the improvement system idea is something that I think is extremely powerful, one to throw in there.

Ben Grinnell

Yeah, I'd just add, it's learning by doing. You can't go and teach everyone the way you've designed in an ivory tower for three months because you'll be teaching them three months ahead of where they've got to on their own.

So I think you've just got to make sure the whole organization can learn by doing and improve.

Damon Edwards

Any other...

Someone's got a question. Okay, sure, Brad.

Audience

Right here on the improvement systems. So everyone loves Toyota and that story. Where else can we look to hear about other systems and other approaches? Any recommendations, case studies?

Damon Edwards

Yeah, I got one. There's a book called Team of Teams.

So do you know who Stanley McChrystal is? He's a general. He's the US general who led the surge in Afghanistan. Basically totally refactored the Special Forces because they were designed to fight the wrong war.

And it's literally, a CTO sent me this text. He's like, "You've got to read this book, Team of Teams." He's like, "The Special Forces does DevOps. They just don't call it DevOps."

They have decentralized control. They don't care about redundancy anymore. All they want to have is, they call it a shared consciousness with decentralized control. They have a daily stand-up, and it's literally the same time of day all around the globe. They have this giant video conference call where everyone's on it, from the lowest analysts to the highest generals. They're all on this call every day. They call it their battle cadence.

And so you read the story and you're like, wow, I just replace all these stories, instead of war stuff, with people building systems, and it's the same principles.

So that's a great book to put in front of non-technical folks or even technical folks because you're like, wow, I see the same principles, but they're in play in such a crazy different domain, and yet they were working. And it's just a fascinating read, too.

Audience

Can you shout out the author again?

Damon Edwards

Oh, Stanley McChrystal?

Audience

Stanley McChrystal.

Damon Edwards

Yeah. It's called Team of Teams. It was a kind of a Harvard Business Review bestseller kind of bigwig guy.

Ben Grinnell

I'd add one that actually you might be aware of, John, which is the Black Swan Farming website's Maersk Line study about cost of delay. It's just an amazing case study if anyone wants to see it. Black Swan Farming.

Damon Edwards

And there's one other book, too, that's good, is the Don Reinertsen, I think his name is, The Principles of Product Development Flow or something like that. That's great because it's a little geeky, but it breaks down all these ideas, small batches and focus on flow. It kind of gives you a lot of the science behind it.

It's not just a bunch of theory. Or it is theory, but it gets down into the science behind it.

Sorry, I don't know if anyone's got a book or... No? Okay. All right.

The lady over there.

Audience

How much autonomy, how do you find guidelines on how much autonomy you give to developers to make changes to systems? Because one of the concerns that architecture teams have is that developers don't have the full picture. So how do they know they shouldn't touch the system because there might be serious implications?

Damon Edwards

Ah, the dreaded... I'm going to repeat the question for the camera.

So the question is, how do you trust those damn developers, right? Because you know they're going to break things because they have no idea how this architecture is supposed to hang together.

Okay, I put it a little differently. The question was, what do you do about system architecture? This idea of autonomy, decentralization, that sounds great, but isn't that chaos? Isn't that going to break stuff? Aren't we going to get in a situation where we're worse off than we are today?

Steve White

Ideally, you don't just have a development team. You have a multi-discipline team, and in the team, you've got your architects. The architects are talking to the enterprise architects within the organization. You've got DevOps guys. They've gone through a pattern where they've released hundreds of times before. It's safe. It's a small incremental release. If it fails, they can roll it back quickly.

That's where you need to get to, to allow a developer to release into production. And then, of course, you get things like PCI compliance, where you can't just have a developer legally launch into production, and you have to figure out how to put some processes around that and make sure it gets the right sign-off and stuff like that. It's not straightforward.

Ben Grinnell

I guess I'd just say, as far as the consequence of their team's actions go, if their team just don't feel pain from creating a bad architecture, then it's difficult to trust them there.

But if they feel the consequence of the architecture within that team, then you can start trusting them because it just starts to make sense to do the right thing.

And I think there's a lot of fear in that. But if you get a conversation where you've got someone sensible from the business is empowered, someone sensible from ops is empowered, and someone from dev, then the conversations about how you monetize, how you take the lowest risk, and everything else, they're really sensible conversations and they come up with good answers.

So give them autonomy.

Damon Edwards

Yeah. And since I'm the moderator, I get the last word because I guess our time is up.

But I would say one thing is you often have to change your architecture. I think if you design systems to be built in a decoupled way, having giant monolithic systems is going to force people to work in a monolithic way. So they reinforce each other.

So you're going to have to hit it at both levels, the organizational and process, and also think about how are we going to build systems that can be built and maintained, designed for manufacturability as the kind of principle.

So I am getting the furiously wave back there that our time is up. So Marcos, Steve, Ben, thank you very much. Thank you, all of you who had the questions, and give these guys a round of applause.