Host Intro (Gene Kim)

[00:00:12.740] All right, the last speaker today is Jon Smart.

[00:00:19.000] I met Jon in 2016 when he headed up the ways of working at Barclays, a bank founded in the year 1690, which predates the invention of paper cash in Europe. In his role, Jon had an amazing reputation of doing things that were very different than the traditional norms inside of an organization that had one of the most highly evolved bureaucracies on the planet, having had centuries to perfect itself.

[00:00:44.860] I mentioned in my opening remarks that his definition of DevOps as being better value, sooner, safer, and happier is one of my favorites. I'm so delighted that this phrase has been uttered so many times over the years, showing the impact that his work has had on this community. This is one of the reasons why I'm so happy that he's on the program committee. I forgot to mention that Topo Pal as well is on it, as well as Jason Cox.

[00:01:08.940] Over the years I've learned so much from Jon, and I love that he put this into his book, Sooner Safer Happier. He, like so many of us in the community, is thinking about how to create organizational structures that are conducive to, as opposed to corrosive to, the outcomes that we actually want. Here's Jon.

Jon Smart

[00:01:31.110] Thank you. Good afternoon. It's a pleasure to be here. What an amazing two and a half days. Woo. Yeah.

[00:01:41.370] As the final speaker, I would like to say thank you to IT Revolution, to the whole team for making this happen. It's a lot of work, so please show your appreciation for IT Revolution, for the team. Thank you. Backstage.

[00:02:00.940] Okay, so I'm going to talk about organizing for outcomes: squads, tribes, chapters, guilds, domains, crews, fleets, hubs, circles, anything else? Anyone using any other words? Sorry? Pods. Teams? That's a revolutionary idea. Team. My God, that's far too simple. We can't use team.

[00:02:31.280] It seems that every company on the planet is adopting anything other than teams: squads, tribes, chapters, guilds, crews, fleets, hubs, domains, fleets, et cetera. So I'm going to talk on that topic and I'm going to share with you the mistakes that I have made. I'm going to share with you mistakes that other people have made so that hopefully you don't need to make the same mistakes.

[00:02:54.300] Health warning is mistake number one: rigid, one-size-fits-all, forced org design seriously harms you and others around you. I see some knowing nods. There is no playbook or blueprint, and it's organizational evolution in context.

[00:03:11.150] Even the word design doesn't sound right, like org design. We've designed the organization, done right first time. No, doesn't happen. It's evolution. Design is not a phase. Design is continuous. And that applies to how we organize as people. So this is sociotechnical, and this is the socio part of sociotechnical.

[00:03:38.170] The question to ask is, what are you optimizing for today in your organization, if you are optimizing for anything intentionally? Usually organizations are not optimizing for anything intentionally. It's accidental, unless it's cost reduction. Every organization is perfectly designed to get the results it gets. So if you're getting the results that you want and everyone around you is getting the results that you want, congratulations, that's amazing. Please let me know afterwards what your magic sauce is. If you're not getting the results that you want, then hopefully there are some mistakes that I can share with you which hopefully will help.

[00:04:16.060] The next set of questions to ask is, what do you want to optimize for? Do you know what outcomes you want? And are they being measured? When I work with organizations, I ask these questions, and the answer every single time is: don't know, no, and no.

[00:04:35.320] So the pattern here is to focus on the outcomes. What are the outcomes you're going after? It isn't chapters, squads, tribes, guilds, domains, crews, fleets, pods, circles, hubs for the sake of them. No, it's for the outcomes you are going after. The lesson learned, number one, is be very clear what the outcomes are that you are going after.

[00:04:55.930] Now, this will be an amazing surprise to you when I suggest the following set of outcomes: Better, which is quality. Value, which is unique. It's unique to your organization. I find OKRs to be a good way to measure value. Sooner, which is minimizing time to value, minimizing time to learning, because the domain of work is unknowable. Safer, which is continuous compliance, agile not fragile. And Happier, which is happier customers, colleagues, citizens, and climate.

[00:05:26.290] I'm going to pause there because I can see the phones going up. That's a balanced set of outcomes. I have found it to work in every single context of organized human endeavor: public, private, charity, religion, you name it. The important thing is it's balanced.

[00:05:40.050] I've heard DORA metrics mentioned a number of times. I would suggest that DORA metrics are incomplete. It's a good place to start. There's a lot of benchmarking, which is great, and it tends to be missing value, safer, and happier. So what I would advise is add on value, safer, and happier to DORA metrics.

[00:06:00.540] One other thing I've observed is DORA can be a turnoff to non-technologists. Business leaders are like, "Well, that's just your thing. Those don't apply to me." No, it does apply to you. Plain English, plain language absolutely applies. Nobody wants to deliver worse, slower, unsafe, or unhappier, in terms of incentive of why I should have a conversation with you as a leader in your company, not in technology.

[00:06:32.160] The antipatterns are rigid, one-size-fits-all, forced playbook with no alignment to outcomes. I see this quite a lot in organizations where there is a top-down big-bang cascade of, "Here's the new org design." The second one is reorganization done equals transformation done. "We will be complete on the 30th of June, 2023. We will have done our agile transformation." Then when I speak to people in those areas where they've been "done," what I hear is, "Oh, I've just realized this is just the beginning. Oh, we're just starting now." There's this lightbulb moment of, "Oh, we're just beginning."

[00:07:11.880] Then cost-cutting-led org design, that's another common antipattern. "We're going to let 10,000 people go and everybody else, you are going to be pivoted into domains, crews, fleets, pods, hubs, circles, or whatever." Again, I see some nods. Cost is a great way to kill transformation dead, by the way. If you want to prevent a transformation, mention cost, because then you'll drive up fear.

[00:07:37.740] So how did we get here? 1.9 million years ago we were organized in multidisciplinary teams, aka tribes. We are tribal. This is Homo erectus, a predecessor to ourselves, Homo sapiens. We've evolved in tribes.

[00:08:01.200] Fast forward to 253 years ago, and here we have a full-stack team, domestic cotton ops: you weave it, you wear it. Even 253 years ago, we are still in multidisciplinary teams. This is how cloth was made. The raw cotton, which actually came from the States, would be dropped off at someone's house in northern England, in the case of the UK, and you would have a multidisciplinary team, like a T-shaped or pie-shaped or even comb-shaped team, who could turn the raw cotton. There's about 15 steps to processing cotton. I did a bit of research into how you process cotton. It was quite interesting. Then you end up with cloth. Someone comes and picks the cloth up. Multidisciplinary team.

[00:08:50.260] Then everything changed, and it's no coincidence that this begins with a waterfall. For anyone who hasn't seen me give this talk with this particular slide, take a guess as to what that is. Jail. What else? Mill. Any other guesses? School. So you're all right. It's a mill, but it's also a jail and it's also a school depending on your outlook.

[00:09:26.500] So 252 years ago, 1771, this is Crompton Mills. This is the first factory system at scale. This is the beginning of division of labor. This is the first Industrial Revolution. This is the very, very first time in this building where we have role-based silos. This was the beginning of the pivot. This was a momentous moment in organized human endeavor.

[00:09:49.180] Myself and some friends, we did a gemba walk, a site visit. We got taken around by an expert who told us all about the history. Richard Arkwright was the founder of the first factory system. It was so specialized, the work was so dumbed down, that it became child's play. At its peak there were a thousand people working in this factory. Seventy-five percent of them were children, and that's because they were small so they could fit under the water-powered looms, but also they were cheap as well. It took another 60 years before this industry became regulated in terms of working conditions. In the UK, this is the beginning of labor unions because of the conditions in factories.

[00:10:37.580] The DNA in your organization, you can trace directly back to this factory if you have role-based silos in your company. If you have business, IT, BA, dev, test, product, pricing, marketing in silos with work passing, there's the history. It came from that factory, that very one there. That's where we've come from. Then division of labor continued, and then division of labor continued, and then division of labor continued to today.

[00:11:14.770] I've had the dubious pleasure of working in a chicken farm. Sorry, I mean a cube farm, in the past. Anyone here had the luxury of working in an environment like this? Quite a few hands going up. Where I was working, the managers had offices around the outside where there was natural daylight, and all of the doers had cubes in the middle where there was no natural daylight. They're so high that you can't possibly communicate with anyone. Not great for collaboration, not great for engagement, but still surprisingly recently prevalent.

[00:11:49.920] The current state for many organizations is this. Here on the left we have the business. We have the head of planning, the head of doing, the head of checking, and the head of acting. That's an inside Deming joke. Then we have business relationship management. If you're a trendy company, you will call this product. You act as a go-between between IT and the business. Then you'll have IT technology. If you're a trendy company, this is called engineering.

[00:12:21.540] There are quite a few companies that I'm working with or talking to where it's called engineering and product. But you know what? It's new labels on the same old behavior. Product is a go-between between engineering and "the business," in quotes. There's one organization I was talking to a couple of weeks ago where they also have shadow IT in the business. So you have the business talking to shadow IT, talking to product, talking to engineering. It's kind of new labels on the same old behavior, which, with empathy and a charitable intent, is understandable. It's a journey. So I'm going to share with you some learnings on this journey.

[00:12:59.520] Typically there's a brick wall in between those silos. Typically people are incentivized in their silo. Your objectives, your appraisal, your promotion, your pay is typically done in your role-based silo. So you are incentivized in your silo. The hole is on your side of the boat. I don't care.

[00:13:22.060] In the context of unique change, this is feast to famine. It's work waiting. The incentive is, "I've done my bit. I don't care about your bit." It's inhumane. It's a cog in a machine. That's because it comes from the way we've been working for the last 252 years. It's definitely not optimizing for Better Value Sooner Safer Happier. In fact, throw in a sprinkle of a culture of fear, you couldn't come up with a worse way to organize human endeavor to deliver Better Value Sooner Safer Happier in the context of unique change.

[00:13:58.120] There is a better way. There are better ways. We've come full circle. We're back to tribes. This picture on the right, given the topic of AI, I asked Dream AI to generate an image from text, which was "five people collaborating around a laptop." Clearly it can't count. One, two, three, four, five, six, seven, eight. I count eight people. Obviously this is early days of text to image. I think it's quite realistic though, isn't it? I think it's not bad. There were some worse pictures than that.

[00:14:36.740] So what patterns might help? To quote, to allegedly quote what Drucker allegedly said, but he never actually said it, "Culture eats strategy for breakfast." My corollary to the quote that Drucker never said is: incentives eat everything continuously.

[00:14:49.060] It all comes down to incentives. DevOps, ways of working, Agile, Lean, whatever you want to call it, it all comes down to this. My conclusion is it all comes down to one word, which is incentives. Tell me how I'm incentivized, I'll tell you how I behave. The flip side to the coin of incentives is threat, incentives and threat.

[00:15:10.080] Let's take a closer look at this. Neuroscience: work has changed, but our brains haven't. Our brains are wired for survival, for not being eaten by a tiger on the savannah. So we will do whatever we need to do to survive, within reason. Number one, we seek incentive. Number two, we avoid threat. Our threat response is double the strength. It kicks in twice as quickly and it lasts twice as long as our incentive response. That's the chemicals in our brain. Therefore we have loss aversion. We are more likely to do nothing to avoid failure than to do something.

[00:15:52.400] Quite often in organizations you'll see people who don't change, especially if there's a culture of fear, because it's safer for me to do nothing than to do something and fail. So this is the neuroscience. The success pattern is you have to be intentional about increasing incentive, like what's the selfish gene? What's in it for me? Why should I do this? And you have to minimize threat.

[00:16:19.270] Usually what happens is threat goes up massively because we've got a top-down infliction of a reorg and I've got to reapply for my job and I've got six to nine months of job insecurity. I don't know whether I can be a tribe leader where previously I've been a project manager or something else. Normally we ramp up threat and we don't think about incentives. We leave the incentives exactly as they were before.

[00:16:48.880] Antipattern, feel free to take a photo: we accidentally increase threat and we leave incentives misaligned. And we wonder why squads, tribes, chapters, guilds, crews, fleets, pods, domains, circles, hubs don't work. There are two organizations I'm aware of in the last few months who have gone backwards because they didn't realign the incentives. The incentivization was still in the role-based silo. It wasn't in the multidisciplinary team.

[00:17:21.870] Incentives are both implicit and explicit. My implicit incentives, my intrinsic incentives, are to fit in with the cultural norm, to fit in with the peer group, but also to fit in with my leader, the person who's completing my performance appraisal. The Westrum cultural typology applies here: generative, bureaucratic, pathological. Leaders hire and promote in the image of themselves, so you tend to get the same type of culture happening in an organization. Explicit is pay and promotion, for example. Incentives drive behavior. Tell me how I'm incentivized, I'll tell you how I behave.

[00:18:01.340] Incentives and behavior inform structure. They drive structure. Three types of structure. Number one is formal, which is reporting lines in the HR system. Number two is the actual team structure, so this is your multidisciplinary team where you might have lots of different reporting lines. The third is the social graph of how you actually get stuff done in the company. If you've been at a company for 15, 20, 25 years, you know who to talk to to actually get stuff done. If you've just joined as a youngster, as a young rebel in the organization, you need to figure out who to speak to to get stuff done.

[00:18:48.260] That may or may not lead to a change in incentives. Key point here is changing the org structure doesn't by itself necessarily correlate to a change in incentives. If the incentives are still in your role-based silo, you can see that it won't necessarily improve the outcomes, which is why we have to keep an eye on the outcomes and we have to think about the incentives.

[00:19:09.000] Here's an example. This is Company A. This is an example of how the incentives and the behavior, i.e. the culture, drives the structure and the structure reinforces the culture. This is a single point of contact, this org chart diagram. This is someone who likes to make all the decisions: highest paid person's opinion. This one is multiple competing fiefdoms. I have worked in an organization which was deliberately designed to work this way with a view that whoever survives it, it kind of drives the survival of the fittest, which is a bit ruthless. Then Company C is this. Company C likes to sue their customers, has a large legal department. And this is your organization.

[00:20:08.120] The antipattern is org design or evolution without being intentional about incentives and without minimizing threats. That's the antipattern. Think about the incentives.

[00:20:20.250] So, organizing by value and flow. Here is a view of a pattern. This is organizing by value stream, tribe, crew, fleet, hub, domain, circle, whatever word you want to use in your organization. I'm going to use the term value stream. I like the term value stream. A value stream is a long-lived team of teams aligned to a bounded context of value with value consumers. The reason for this is to optimize for the soonest time to learning, because the domain of work is unknowable. So we have to minimize time to learning.

[00:20:58.520] There are three things you need at a minimum: the thing of value, and this is a business thing of value, which may or may not involve technology, or it could just be technology; value consumers; and value producers. If you have those three things, you have a value stream. It has to be of value to both the consumers and the producers. It's very unlikely that you'll have a thing of value that your company is providing, your organization is providing, that doesn't have a roadmap, because that means you're standing still. You've provided it and you're not standing still, because the rest of the world is moving forwards, which means you're going backwards. So it's very unlikely that you don't have a roadmap and you don't have some goals that you want to achieve with your thing of value. That's where the OKRs come in and the strategy.

[00:21:41.740] This is a simplified diagram. You will have some customer journeys. You will have some data. You will also have events, and ideally an API on here as well. Sociotechnical: people architecture, business architecture, technical architecture.

[00:22:00.060] The pattern that I have found to work is three leadership roles. Again, back to the socio part of sociotechnical: the value outcome lead, which is the why and the what; the team outcome lead or the value-stream outcome lead, which is the how looking inwardly; and the architecture outcome lead, which is technical architecture and data architecture, which is the how for the value stream within that bounded context of value. Those three roles as equals, not master-servant, not altogether order-taker. Then you've got the right level of tension between what are we doing, why are we doing it, how are we doing it ways-of-working, and how are we doing it technically? So that's a simplified diagram.

[00:22:40.910] Value streams are nested. Here we have Hotel Aurora. Within Hotel Aurora, we have a residential value stream. We have an events value stream. Within residential, we have stay. We have the executive product on the top floors with the lounge with a nice view, and then we have all of the other floors. In events, we have weddings and we have conferences. We have some products. We have some multidisciplinary teams. Then we have a shared service value stream. This, for example, is catering, procurement, laundry, cleaning, HR, legal, finance, security. This could also be IT infrastructure, networks, desktops, cloud provisioning, CI/CD pipelines, the paved path, et cetera, and they support the customer-facing value streams.

[00:23:25.970] We have our COEs, our centers of excellence. These are the chapters. This is the old role-based silo. Very important learning: the work no longer flows from your role-based silo. The work flows in the value stream. You are united to a common objective, a common goal. It all goes wrong if your work is coming through your role-based silo.

[00:23:52.650] Then you have your CoPs, your communities of practice, voluntary law of two feet. For example, we were running an architecture community of practice. Only 65% of the attendees were architects. That's the value in the community of practice. You get all these other people coming to learn about architecture in an architecture CoP. Then you have your enablement teams, which are your specialist secondary teams. For example, a safety team, InfoSec, cyber, data, privacy, fraud, anti-money laundering, compliance, for example. Your ways-of-working enablement team helping you with ways of working across the company.

[00:24:28.890] Then you'll have your channels on the top: web, mobile, store, branch, voice, ideally omnichannel. That is serving up the customer-facing value streams, and you can start your customer journey in one channel and finish it in another channel. This is sharing an emerging pattern that I'm seeing.

[00:24:51.330] Some of the learnings, some of the patterns: use whatever language works for you. Beware, it will stick. There was one company I was talking to which had landed on the word tribe, but found out it was a bit too tribal and didn't want to carry on using the word tribe, but it was kind of too late, so they couldn't undo it.

[00:25:11.170] The next one is use the same word at every level. Very important, because it won't be symmetrical. Don't call it apple, orange, banana, grape, because then even if you're in a small area, you artificially inflate four levels. If you're in a very big area, you break the Dunbar number. You have more than 150 people at a certain level. So just call it banana, banana, banana, banana or value stream, value stream, value stream, value stream. That's another learning.

[00:25:40.190] Don't only manage dependencies. Break them. I made this mistake back in the past. We pivoted to value streams. We were managing the hell out of dependencies, but we weren't breaking them. End of year one: how stupid have we been? We put all of our effort into breaking the dependencies. There's a lot to be said on how you do that. There's hundreds of ways to break dependencies, both socio and technical.

[00:26:03.720] Start with value and funding. Start with value streams first, then map products. A learning here: when organizations do product-to-product pivot but don't think about the value streams in the company, it is hard to retrofit your products to value streams. It is much easier to figure out what the flows of value are in your company, what are the things your company is selling, and from that figure out what your products are. You will have duplication. You will have overlap. You might need to create a temporary shared service value stream where you have a monolithic ball of mud that does 15 things, and then over the next five years you break it down and put it in the constituent value streams where it should live.

[00:26:49.440] Customer journeys span value streams. Watch out for everything being a customer journey. A customer journey isn't only a value stream. Business architecture equals people architecture equals technical architecture. That's when the magic happens. That's an extension of Conway's Law, the extension being the business architecture point.

[00:27:06.140] Finally, start small. Learn by doing. Iterate. It won't be right first time. My lesson learned is we spent too long trying to design the perfect set of value streams up front, and they were wrong anyway. So when we did it time two, three, four, five, and six, we just started quickly and told everyone we're going to get it wrong.

[00:27:23.600] Here's the help I'm looking for. What are your learnings on this journey? For those of you that have been on this journey, what are your learnings? What antipatterns and patterns are you experiencing? Thank you very much.