Sam Yeats

Good afternoon. My name is Sam. I am from Sydney, Australia, and today I want to talk to you about the topic of making it stick. How do you rewire large and complex organizations for outcomes and create an expectation of continuous change?

I am going to break the talk into three components today. We are going to start with finding your why. Going on a change journey is hard, and being clear on your purpose and what drives you is really important. We are going to talk about some of the complexities of wiring up a complex adaptive system, and, of all the things you could do and should be doing, what is one thing you could do from my lessons and journey?

I want to start just by telling the story of a team. This is a value stream. They exist in a large and complex organization. It is one of a thousand teams in this company. If we zoom in to a reasonably sized value stream, within Dunbar's number, there are about 15 teams in this structure. They have a clear customer goal, and they are working to replace a critical monolithic application.

If we zoom in even further to this team, we have Team Neo at the center. I believe this is really the unit of organizations: that cross-functional team, two-pizza team, as we have heard many times today.

The team has been through quite a journey. A few years ago, they used to be pay to play. They were building features based on whoever had money to give to them. They had a moment years ago where they stood back and said, actually, we could turn this around. If we publish a roadmap of our product, maybe teams could give us feature requests and we could prioritize and build common capabilities for everyone. That was a game changer for this team, just thinking about themselves as a team and how they interact with the organization.

They have been listening to these talks at DevOps Enterprise Summit. They have heard about team topologies. Apologies, team APIs. They are leveraging all of these techniques to get their work done day to day. They have shipped an MVP, a big step. They have some pilot users, but the next thing to come is deploying into the main customer app, where there is no turning back.

At this moment, they start to face into the realities of existing in this large and complex organization. The concept of risk and security starts to face them. This team has done a really bold thing for the organization. A few years ago, they had a small security incident, and that really sparked this conversation with security about the modern services they were delivering.

They used the opportunity to bring security into the team, and they went on a two-year journey. I am saying two years for the purpose of the slide, but it was probably a four-year journey to take security on this, embedding them into the team, embedding them into what they are delivering.

There were highs and lows through the journey. Leadership changed. They had to reset, restart the conversations. But at the end of the day, what they built and that partnership with security ended up scaling for other teams. There were hundreds of other teams that started to leverage this same approach.

If you zoom out, to get things done in this organization, there are lots of central areas of the business, which they call enabling teams, that come and ask questions through the team's journey. What are you working on? What are the priorities? When will you deliver? What are the risks? Engagement in procurement, legal, privacy. To top it all off, sustainability pops out and says, how are you contributing to our ESG goals?

All of these asks come at different points in time. They come from different templates, all asking the same question, but at different points in time. My kids play this game on my iPad, for any Seinfeld fans, Frogger, crossing the road with the game console. This is often the feeling that, when I watch my kids play, I have a bit of PTSD about trying to ship things into production.

It just so happens, as John Smart published in Sooner Safer Happier, many traditional organizations live in 90% wait time with 10% flow. The opportunity is massive in order to enable companies to empower their teams to actually ship things.

There comes a point, for me it happened to be at a baggage carousel on Australia Day, coming back from Munich, where I bumped into the CEO of one of Australia's largest organizations. Similar to what David from HSBC mentioned this morning, the printer conversation that triggered his transformation journey.

On occasions, you are presented with a choice. Do you continue to work in the system and work to empower your teams, work within the constraints you have been given, deliver value, and experience the joy of working in these cross-functional teaming structures to get things done? There is no better feeling than being able to ship value to customers.

But for some of us, you have the opportunity to work on the system and to think about rewiring the system and solving some of those systemic impediments that are not just affecting your team, but affecting the whole organization.

This can be, especially in large organizations, a complicated task. You will be targeted. There is a high chance of personal failure, and it will be quite frustrating. However, it is extremely rewarding to solve complex problems, and that is what I know drives me.

Working on the system in large and complex organizations comes with a health warning, and you need to look out for yourself. One key way you can look out for yourself is to be really clear on your purpose. For me, I love teams. I love that feeling when a team can come together, they can get something done, they feel satisfaction in their work. There is no better feeling coming home from work knowing that you have shipped something, that you have added value, and you have delivered. That is why I take on this task and have taken on this task in the past. That is what drives me. I want to help organizations have more teams that feel that same sense of accomplishment and achievement.

The other key thing I have learned in this journey is to really dig into what is motivating others that you are taking on the journey. I have many stories, which I will not go into today, where asking the five whys of other people, really getting behind their motivations, can actually unlock progress when you understand what really motivates people.

So you have chosen to work on the system. Congratulations. You have just taken on, either directly or indirectly, a whole bunch of domains that are all interrelated and quite complicated.

Then you stand back and think, actually, what have I taken on? I am not just solving for one business unit. Actually, the scope of this transformation is the whole organization, and every business unit has processes that are entrenched, leadership behaviors that are embedded, and they are all wired entirely differently. How can we bring people together around our organizational mission and purpose to deliver value?

I have this saying, and I find myself quoting it to myself probably every other day for the last seven or eight years on this journey: there is always a bigger fish. There is always something bigger at play that you need to be thinking about. You need to be curious. You need to be the first to read the annual report when the company publishes it. You need to be understanding what is happening at the board level, what is happening on the ground, pulling all this information to help you think about the scope of what you are doing and the impact you are working to have. There is always something bigger at play, and working that out can save you years if you can think through it.

You do the sums. You think back to that journey that Neo went on, on behalf of the organization, to change the mindset, change the processes and practices of security, which was that two-to-four-year journey. Then you start to think about all these other things that have been written up on a slide by a management consultant that sparked the transformation: changing mindsets, DevOps, secure coding practices, organizational design, project to product.

All of these topics are incredibly important to solve. However, they are all interconnected. You cannot run them all at the same time. You cannot stand up a Gantt chart and track them through to completion. They are highly interrelated and highly connected.

When you are leading a transformation, you need to think, we cannot push this on the organization. You can try. You can spend years convincing people to change. But how do you create a dynamic where there is a pull-through from all these areas and they start to pull through the change?

For me, being part of this community for the last however many years has been incredibly useful. Having those customer journeys to share with peers and leaders in different situations, and all the books that are available through the authors that participate, have been incredibly helpful tools on my journey. I encourage you to dig in and share those tools with your organization.

I am not going to cover all these today, because if you get across the other talks, you will be learning and digging into these specific topics in many of the other talks. Constraint is a good thing. In thinking about the talk, I was trying to think: what was the one thing that helped have a breakthrough and that I have seen work, even recognizing that you need to do all these things?

One of those things that has cut-through on all topics is thinking about: what are we doing? What is the work? What are people doing? How does that work connect to our company goals? Often companies are living in PowerPoint. They are living in spreadsheets.

I used to have this practice where every Monday I would walk 40 floors of a building from top to bottom, just doing circuits, getting a pulse of the organization to understand what was going on. I would see pockets of teams. I would see people living in PowerPoint, and that just gave me an edge to connect the dots quickly within the organization. But how do we make work visible to everyone?

Having that work visible and the outcomes of teams visible can then allow you to drive a whole bunch of these other changes.

The one area I would like to talk about today is how could you create a pattern interrupt? You have all these teams, all these central teams asking for different things. How could you create a common tempo, a common heartbeat in the organization where people come together to share what they are working on?

How could we use all the lessons we have learned over the years from the IT side of the world? How could we use these learnings around modern software architecture, modularization, to create this pattern interrupt?

I am going to talk about using a quarterly business review as this common tempo, a vehicle to drive change. How can that be used to create transparency across the organization?

How many of you participate in a quarterly business review within your organization today? Just hands up. Maybe 50%. That is great.

I want to talk to you about thinking about quarterly business review. It might exist already, or it may not exist. How could you help your leaders, or if you are leading this, how could you think about this process with a product mindset and a modular architecture?

One way is creating this QBR artifact. You start very simple. It can happen on a page, ideally in Confluence or a shared visible document that allows teams at a certain level, maybe the value stream or above level, to record the outcomes they are aiming to achieve for the next quarter.

This solves an indisputable need. Who would push back on saying that you do not need to share your goals? There will probably be many that do. But for the company, this is a lever. It is something that cannot easily be challenged. The challenge is then scaling that across the organization.

When we think about this artifact, the design principles: it needs to be lightweight. We do not want to create another ask of the business. It needs the ability to scale across the whole business end to end. It needs to be open and transparent, componentized. We are starting with OKRs, but as I will share with you, we can then move on to wiring up other parts of the system over time, progressively. We want these components to be owned in a distributed way. We want the strategy team, or the teams that care about goals, to be thinking and owning the component here, just as funding might be finance that pulls through into this artifact.

In creating this artifact, how can we use those product techniques that we use with our customers and shipping product? We have feedback cycles. We create this artifact. We have a process of QBR where it is filled in. We take feedback from the value stream leads, the leaders that are participating in the process, and we incorporate that feedback to solve problems for the next quarter. We publish release notes on a quarterly basis to say, here is the new, the next thing that we are solving for in this common heartbeat of the organization.

We slowly, progressively expand into other topics. Initially, what I like to call minimal viable wiring: what is that minimum wiring to start with before you then can wire other aspects, such as funding, workforce, maybe software, or security and risk practices, into this common heartbeat?

We want this to happen at the right level. Obviously, teams need to work with each other, use methods like Team APIs to work out their interaction modes. Here we are talking about a minimal viable coordination layer that fits within your organization.

One example where I feel this has been done really well is Telstra, Australia's largest telecommunications provider. They faced a number of years of disruption with what is called the National Broadband Network launching in Australia. They created a QBR that was deployed initially in a few business units, but has now scaled across all business units and even their wholly owned companies. It is a common heartbeat they have maintained. Despite the winds changing and leadership changing, they have been able to hold to this heartbeat over a number of years.

As it says in this quote, even just publishing the OKRs of the company and of the teams, just in the last 12 to 18 months, that page on Confluence has been viewed 17,000 times. That is just the top-line goals. If you think about behind all of that, there are leaders coming to reflect on what is going on, what the priorities are, what others are doing, and an opportunity for them to align and improve what they are doing.

If you take this modular approach, we are starting with planning as a monolith, where there are all those independent asks of teams distracting them as they come through. We are launching an MVP where we are sharing common goals across the organization to create that heartbeat. Then we are moving on to other topics: funding, which I feel is the root cause of dysfunction of many teams, impeding many teams. There are a whole bunch of other topics you can move on to.

Even the concept of defining what work might stop is a significant cultural milestone for an organization. Being able to say to your peers, we are choosing to stop this work over the newest priorities that have come in; getting a company to that point can take years of work for leaders that feel they just have to keep these initiatives running, when actually the leadership of the organization is encouraging them to stop and change. Using this vehicle of change can create this transparency to drive some of these outcomes.

I will not talk through this slide. It will be in the pack. But again, use all the knowledge that you are learning across your DevOps journey, thinking about how do you wire the company operating system using these same terms, or how do you help your company do this? How do you create a system that is observable? You are testing and checking in with users. Is it usable? It needs to be reliable. There are market commitments to meet. It needs to be resilient. This system needs to be resilient to fires that pop up that then erode that tempo of the organization.

There is obviously a huge backlog of things you can solve for, wiring up the system of work. We will not talk through all these today. The conference and many of the topics that you will hear are speaking to many of these areas. But I have found that taking this approach, you still need to deploy the changes. You still need to go on the journey with many different areas, partnering with them through the ups and downs to drive these different parts of the movement.

Having that common heartbeat is one way I have found to help things move forward, to create that transparency, focus on the work and the outcomes when there can be a lot of other noise distracting from that delivery.

I have some recommended reading on the top here, but I would love to chat. What are the war stories where things have gone wrong as you have been wiring up your organization when working at large scale? What are all those unintended consequences of trying to connect the system when maybe it should not have actually been connected? I would love to hear your stories and share some more of my own.

I am also keen to think: how could we speed up this journey? It does feel like on many topics, such as the work taxonomy or work breakdown structure, every organization is going through a multi-year journey to define what that means for them. I think there are more stories we can all share with each other on the hacks and practices that have sped that journey up, factoring in these complex systems of people and process.

Thank you. Thanks for the time.