Host Intro (Gene Kim)

The next speaker is Jon Smart, who I met in 2016 when he headed the Ways of Working at Barclays, which is an organization that was founded in the year 1690, which actually predates the invention of paper cash in the West.

Jon cracks me up. In his role, Jon had an amazing reputation for doing things that were very different than the traditional norms inside an organization that had one of the most highly evolved bureaucracies on the planet, having had centuries to perfect itself.

I mentioned in my opening remarks that his definition of DevOps as "Better Value Sooner Safer Happier" is one of my favorites, and I'm so delighted by how many times those phrases and those words have been used on the stage and within this community.

So this is why I am so happy that he's on the programming committee for this conference. I've learned so much from him, and I love that he put his learning into his book, Sooner Safer Happier. Like so many of us in this community, he's thinking about how we can create organizational structures that are conducive to, as opposed to corrosive to, the outcomes that we want. Here's Jon.

Jon Smart

Better, faster, stronger.

Good morning. It's a pleasure to be here, pleasure to be back in person. I'm going to talk about organizing for outcomes. It seems that every organization on the planet is currently on this journey around organizing from role-based silos to multidisciplinary teams and tribes, and not just in IT but across the whole organization.

I'm going to share some lessons learned, mistakes that I've made, and also learnings from a whole bunch of organizations across industry sectors.

A health warning: rigid, one-size-fits-all forced org design seriously harms you and others around you. There is no playbook or blueprint. If you get handed a PowerPoint deck where the logo has been changed, beware.

It's organizational evolution in context. Even the term org design doesn't quite sound right. Design is not a phase; design is continuous. It's about evolution.

The question to ask is: what are you optimizing for today in your organization? Are you consciously optimizing for anything in particular, or is it accidental? There is a quote after W. Edwards Deming: every organization is perfectly designed to get the results it gets. If you're happy with the results you're getting, and everybody is happy, congratulations. Let me know when you're speaking; I'd like to come along and listen. If you're not, I've got some patterns and anti-patterns to share which hopefully will be helpful.

The question to ask is: what do you want to optimize for? Do you know in your organization what outcomes you want to optimize for? Or is it cost, which is what it tends to be quite often? And are they being measured? It's one thing to know them, but are they being measured? Usually, working across industry sectors with multiple large organizations, the answers to those three questions are: we don't know, no, and no. Nine times out of ten.

The pattern here is to focus on outcomes. No surprise, the outcomes I would recommend focusing on are: number one, better, which is quality. Number two, value, which is unique in your organization. It's good to measure it through OKRs; the KR is the definition of value. Sooner, which is time to learning and time to value. Safer, which is minimal viable compliance, right-sizing the control environment, agile not fragile. And happier, which is happier customers, colleagues, citizens, and climate, because improving ways of working is not at any cost to the planet or to society. For me, it's about humane ways of working. That's what gives me purpose: creating more humane ways of working.

The anti-patterns are: rigid, one-size-fits-all forced playbook with no alignment to measurable outcomes at all. Number two: org design equals transformation. We've rolled out the so-called Spotify model and we declare success. Number three: a cost-cutting-led org design, also known as spans and layers 2.0, if any of you have had the pleasure of going through spans and layers exercises in the past.

How did we get here? How did we get to this point? 1.9 million years ago, we were in multidisciplinary teams, also known as tribes. It seems we have about two million years of experience working this way. This is how we've evolved as hunter-gatherers, in multidisciplinary teams.

Fast forward to 252 years ago, 1770, and we're still operating as full-stack teams. Domestic cotton: you weave it, you wear it. We have a multidisciplinary team. It's a craft. There are skills. We're working together. It's domestic.

Then everything changes, and it's no coincidence that this video begins with a waterfall. This is 1771, the beginning of the first Industrial Revolution. This is the actual factory where you can trace your current ways of working at your company back to this factory. This factory is in Derbyshire. These four dodgy-looking chaps did a site visit in March of this year to Cromford Mills. This is the first factory system at scale, and this was the beginning of division of labor.

Previously, it was at home, a multidisciplinary team, for the last two million years. This was the beginning of division of labor for the first time. We had 1,000 people working together in a factory with 15 role specialties, to the point where it went from skilled labor — you needed to know what you were doing to turn raw cotton into cloth — to so specialized that it was now unskilled labor. It actually destroyed the domestic market for producing cloth.

In this factory, this is the origin of our ways of working today. This is the person who was the father of the factory system: Sir Richard Arkwright. It was so unskilled that children could do this work. Seventy-five percent of the 1,000 people working in this factory were children. The reason for that is they were small, so they could fit under the machines, and also they were cheap.

We had a guided tour, someone telling us all about the history. Thank goodness that doesn't still happen today.

That's where we've come from. This was the big tectonic shift. Fast forward to 1905. This is one of the earliest org charts. Clinton Edgar Woods wrote a book called Organizing a Factory, and in that book he describes the brains being at the top. The reason the leadership team are at the top is because they're the brains, basically implying that there are no brains at the bottom. Workers are nothing better than dumb draft animals, according to Frederick Winslow Taylor.

This was the prevailing mindset. To quote from the book: chart authorities simply and graphically, so that every workman knows to whom he is responsible. There is then no loophole through which a neglectful workman, foreman, or executive can crawl. No longer does he have the excuse that he thought somebody else was going to do it.

This is the mindset, the prevalent mindset of the time for the org chart. Then division of labor continued, and division of labor continued, and division of labor continued. Here we see a chicken farm. Sorry, I mean a cube farm. Do any of you have the misfortune of still working in a cube farm when you're in the office? I'm sorry for you. I have empathy for you. I see some hands going up.

I've had the displeasure of working in a cube farm twice in my career. One was in Midtown New York. All of the offices for the senior leaders were around the outside with the windows, and anyone who wasn't a senior leader was in the cube farm in the middle with no natural daylight. Again, you can trace the DNA back to that factory in Derbyshire. You can trace it back, and that's today.

The current state for many organizations is you have "the business" on the left. There's an inside Deming joke in there: the head of planning, the head of doing, the head of checking, and the head of acting. Then, if you're an old-fashioned company, you have something called business relationship management, just to make sure you're keeping it away from the business. If you're a trendy company, you call it product. Then we have IT if you're an old-fashioned company. If you're a trendy company, you call it engineering.

Guess what? There are brick walls between these job roles. I see this prevalent today. Even when the terms product and engineering are being used, product is still a silo and product is acting as the go-between between engineering and, in quotes, "the business." A bit of advice: don't say "the business"; say "our business."

We still have role-based silos. This does not optimize for outcomes in a context of unique change. This is feast to famine, the pig in the python. It's work waiting. The incentive is: I've done my bit; the hole is on their side of the boat. And it's inhumane. Workers are still cogs in the machine. This is not optimizing for better, value, sooner, safer, and happier.

We've come full circle. Back to the future. We're back to tribes. It seems that what we were doing for 1,899,750 years was quite a good idea. We're back to multidisciplinary teams and tribes. So what patterns might help?

There is a quote here often attributed to Drucker, "culture eats strategy for breakfast." It turns out that Drucker never actually said it. My corollary to that quote is: incentives eat everything continuously.

The topic of ways of working, the topic of DevOps, the topic of transformation, in my experience, comes down to one word: incentives. You can boil it down to incentives. When I say incentives, I mean both incentives and threat, the two sides of incentive. It requires a lot of intentional thought about incentives in your organization.

Neuroscience: work has changed, but our brains haven't. Our brains are wired for survival, for not being eaten by a tiger on the savanna. We seek incentive and we avoid threat. That drives our behavior. Threat is double the strength of incentive. We have loss aversion: it is more painful to lose $100 than it is to win $100.

The pattern here is to be intentional about increasing incentive and minimizing threat. The anti-pattern, and what usually happens in organizations, especially in the topic of org design, is accidentally significantly increasing the threat and misaligning the incentives because we're doing a top-down, big-bang org design rollout of squads, tribes, chapters, and guilds.

A closer look at this: incentives are both implicit and explicit. Implicit incentives are the group social norms, and also for example Westrum cultural typologies: generative, bureaucratic, pathological. You fit in with the leadership style of the team that you're in. Explicit will be the reward system: pay and promotion. Your incentives drive your behaviors. Tell me how I'm incentivized, I'll tell you how I behave. I believe that incentives and behavior drive structure.

Structure will also either accidentally or intentionally have a feedback loop onto the incentives. There are three forms of structure operating in parallel all of the time. Number one: the formal reporting lines. Number two: the actual team structure. If you're in multidisciplinary teams, those multidisciplinary teams typically don't represent the reporting lines that are in your HR system. Number three: the social graph, which is how you get stuff done, who you know to speak to in this department or area to actually get stuff done.

Those three are operating in parallel all of the time. If number one is dysfunctional, number three will come to the fore. The informal network will be more important if the formal network is dysfunctional.

I've seen a scenario in an organization where there was a reorganization into value streams, into multidisciplinary teams and teams of teams. The incentive model was not changed, and it didn't work. People were still incentivized in their role-based silos. I'm seeing some knowing nods in the audience. They were still incentivized in their role-based silos, so the pivot to value streams failed, because people were not incentivized to team-based OKRs, team-based outcomes. They were still incentivized in the role-based silos.

Here's an example of how culture drives structure. This is a company you might be able to imagine. There is one person in the middle making all the decisions. This is company A, updated. This is company B. Again, you might have seen this before; you might imagine what organization this might be, which has since evolved. Interestingly, the way this company has evolved has actually been, I believe, through culture influencing the structure, rather than structure driving the culture.

Here's another example: a very large legal department. Obviously the culture here is to sue your customers. And then here's your organization.

The anti-pattern is org design or evolution without being intentional about the incentives or the threats. That's the anti-pattern every single time. I see org design inflicted without due consideration to aligning incentives or minimizing threat. Usually threat goes off the chart.

Organizing by value and flow: here's a pattern. Organizing by value stream, tribe, crew, fleet, banana, whatever language you want to use. This is a simplified version. We are trying to optimize for the soonest time to value and learning. There are three things you need to have a value stream. You need something of value, i.e. a product, and it's both business and tech products, not just tech products. You have value consumers, with different personas in your value consumers, and you have value producers: long-lived multidisciplinary teams.

If you have those three things, you have a value stream: something of value, someone consuming the thing of value, and somebody producing the thing of value, with a value exchange. The value exchange could be bartering or it could be dollars.

For example, the amazing audio-visual team, Good Company, here. The thing of value here is the lights and the sound. If Good Company were not here providing this value right now, you'd be sitting in darkness and you couldn't hear what I'm saying. It's a good job they're here. The value consumers are all of us, and the value producers are the amazing team sitting front of house and back of house. A value stream will have outcomes. Unless you're not changing, which is very unlikely, you'll have OKRs on your value stream. Dear AV team, perhaps give me a signal if maybe one of your OKRs is to grow the company post-pandemic. Awesome. Thank you, AV team. There's an example of a value stream. Thank you to Good Company.

Value streams are nested. For example, the Cosmopolitan Hotel, this hotel we're sitting in, is a value stream. Within it, we have a nested value stream of residential and events. Within residential, we have stay; we might also have purchase, timeshare, or permanent. Within events, we have concerts and conferences. On this stage in three weeks' time is Billy Idol — not on the DevOps Enterprise Summit stage, but that's an example of a value stream here at the Cosmopolitan.

Then you have a shared service value stream. Typically this is the 80/20 rule: 80% of the value streams in your organization are external consumer-facing. Your shared service value streams are internal and support your external consumer-facing value streams. But you still treat the thing you're providing as a product. You still have product thinking. You still have the voice of the customer. It should not be a case of build it and they will come. Cloud platform is a good example of this, where we'll build it and they will come, maybe.

You need the voice of the customer. I have deliberately used the word product in the value stream. I have deliberately not used the word platform. Quite often you might hear the word platform, but there was a good conversation a few days ago on Twitter where platform is a subtype of product, which I agree with. You still need that product thinking.

Then you have your centers of excellence. This is your old role-based silos. This is your craft, and this typically is still your reporting line, but work doesn't flow through the COE. This is now about pastoral care. This is now about development for the individual and the craft.

The community of practice is voluntary, law of two feet. We might have a community of practice on ways of working, on NoSQL, on big data, on architecture, on sales. Entirely voluntary, entirely law of two feet, anyone's invited. It's shared learning.

Then we have the enabler teams, which are specialist secondary teams. For example, a safety team, written about in the book Sooner Safer Happier: InfoSec, cyber, data privacy. For example, a ways-of-working enablement team. For example, SRE. Those might be examples of specialist secondary enablement teams.

Then you have channels, which serve up the value streams in your organization. These are the candles on the birthday cake: for example web, mobile, store, branch, phone, streaming, whatever it is. An omnichannel interface means you can hop between the channels and programmatically serve up the value streams.

The patterns are: number one, customer journeys span value streams. Don't fall into the trap of thinking that customer journeys are only within a value stream, which is something I come across quite often. You have to be able to span value streams, because I don't want to enter my name and address and credit card details four times to do four transactions with your company. I want to go online once and do four things in one transaction.

It's a value stream network. It's not quite as clean as this picture looks. It's a graph. Ideally your value streams, which include people, are API-enabled. For example, the open banking API standard in financial services. You API-enable your value streams, which are your business value and your people. Then the nirvana state to get to is: your business architecture equals your people architecture equals your technical architecture. If you get those three things in line, magic can happen.

How you get there: a tale of two orgs. This is Acme Corporation, a fictitious company, and an example of what not to do: 12 months in isolation designing the perfect org; a further six months of job insecurity; a big-bang rollout combined with cost-cutting and redundancies; a top-down imposition; org design rollout equals declare success; accidentally increasing incentives and threat; a gold rush for the tribal leader role because power equals status equals pay; lack of consideration of the flow of value and technical architecture; it's waterfall value streamfall. The system of work is still big batch, so we're in value streams but still doing a sequential big-batch process. There is a lack of measurable outcomes on the why for the reorg in the first place, but maybe it was just about cost-cutting.

Then there is the Very Big Corporation of America, an example of good — credit to Monty Python for this organization. The why of change is clearly articulated. There are balanced and measurable outcomes: better, value, sooner, safer, happier. There is incentive across the entire company from the executive committee, so everyone is in line in terms of incentive. There is an intentional approach around incentives and threats. Guiding principles are articulated to guide daily decision-making. Participation is invited. It's a case of start small with S-curve adoption.

There is business and technical architecture taken into account. It's a case of working out loud with transparency and communication and storytelling. The support functions are involved: finance, internal audit, compliance, etc. Ongoing ways-of-working support is provided, with a recognition that changing how you organize is just the beginning of the journey, not the end of the journey.

Here's the help I'm looking for. I would love to hear your learnings on this journey. I'd love to hear what anti-patterns and patterns you're experiencing. Thank you very much.