Jonathan Smart

The talk I'm giving today is about not imposing one way of working on people. It's about giving people a voice, not imposing one set of prescriptive practices. That's the topic of the talk. I'm going to do it in two halves. The first half, I'm going to cover some anti-patterns that I've seen, and the second half, I'm going to suggest an alternative. So it's not just a whinge, it's not just a moan, but it's actually here's a suggestion of something that we've done, that I've done, to try instead.

My name is Jonathan Smart. I, until very recently, have been leading on ways of working at Barclays. Barclays is 80,000 people in 40 countries. As I said, very recently, so this talk I'm giving in a personal capacity. Anything I say is my own personal opinion and is not a reflection of my past employer.

I have about 25 years' experience of agility, of applying Agile ways of working, Agile principles and practices. I started as a developer on the trading floor in investment banking, and in those days you did all the jobs. I was sitting on the trading floor, doing the coding, doing the deployments, getting a call at 3:00 in the morning. For a good amount of time, as I took on more responsibility, I didn't hire any other role than an analyst programmer. So there's a lot of back to the future in this for me, personally.

We're going to have a bit of fun for the first half. We're going to do a bit of role-playing for the anti-patterns. I'm going to transform and I'm going to become Mike, the CEO, specifically Michael Scott. Okay, good. You got that one. Nice. I'm going to become Michael Scott to act out the anti-patterns. Now, doing a computer science degree, I never thought I'd be acting on stage. That's true.

And you are going to be the human resources. You've got a role play as well. You need to be resources. Okay? You need to exhibit some learned helplessness. So you need to just be passive, just sit there and wait to be told what to do. Is that okay? It's easy. It's easy. Yeah. It's very easy.

First of all, a disclaimer. All names, characters, and incidents portrayed in this presentation are fictitious and poorly acted. No identification with actual persons, living or deceased, organizations, places, buildings, or products is intended or should be inferred in the following fictitious and frankly ludicrous scenario. This is because I am an independent, and I just don't want to get into any trouble.

So John is leaving the stage and Mike, the CEO, is about to enter the stage.

Mike, CEO

Hey, resources. Welcome. Welcome to the town hall. Welcome to the ACME Walking Shoes Ultra Mountain, AWSUM Corporation, town hall. Whoo. Okay. See, this is the difference between an American audience and a British audience.

So, super excited. How are you feeling? Whoo. Yeah. Awesome. This is the awesome town hall, and I'm your awesome CEO. Dear awesome resources.

Now, unfortunately, we have had a very bad year. Ever since Yangtze Inc. released the Amazing Walking Shoe, AWS, people don't want the Ultra Mountain shoe anymore. We're not so awesome.

Frankly, you should be disappointed. You've let the company down. You've let your colleagues down. Most importantly, you've let me down.

And when I speak to my team, what I hear is that the office is like The Walking Dead. Everyone's moping around, not happy, not trying hard enough. Now, I wouldn't know because I've never done a Gemba walk. I've never actually been to your workplace. So I wouldn't actually know what's happening. But I think you're not trying hard enough.

So we're going to change. We are going to do a skiing transformation because all companies are currently doing a skiing transformation. Here we are at a SkiOps Enterprise Summit. So we're going to ski because shoes are not quick enough. We're going to ski instead, and this is how you're going to be skiing. Currently, it's the rage. It's very fashionable.

And we're going to adopt the Spitify model because some very expensive consultants have told me that this is the best approach. The Spitify model. We're going to adopt squads. This is the blue squad. In particular, you are going to adopt Nordic skiing. I have decided, with literally no input from any of you whatsoever, that you will adopt Nordic skiing. Just look how efficient they are, and you can tell by their hats which guild they're part of. I just hope they don't meet the green squad.

And because we believe in your personal development, starting on Thursday you will commence two days of mandatory sheep-dip training: Certified Ski Master, so you can tell people what to do, and Certified Piste Owner, so you can tell people what to do. You don't need to do any skiing for these whatsoever, and they're renewable by reading a book, watching a video, or attending a skiing conference.

And I empower you to be empowered. Yes, Carmen? You want a snowmobile? I'm sorry, Mike, that's not possible. We're doing Nordic skiing. This is a Nordic skiing transformation. You're not that empowered, Carmen. No, you have to do Nordic skiing. But you're empowered because you can choose to be either a Certified Ski Master or a Certified Product Owner. The choice is yours. And if any manager comes to me with a list of team names already predetermined, I'm going to tear that up and I'm going to say, no, you are empowered to choose between one of those two roles. You still have to ski.

So on Friday of this week, this is what it will look like in the offices, like zombies. We're going to do a big-bang transformation. So on Monday when you come in, you're going to be in your new roles, having done your training. And on Monday of next week, you're going to be all smiling and laughter, and you will look just like that on the right. We're going to do this at scale. We're going to do it overnight, a big flip. Then you've got 18 months to completely transform the organization.

Any questions? Good, because you've got learned helplessness, so that's good. That's the end of the town hall. Get back to work.

Jonathan Smart

Okay. This is John, not Mike. John is back. How do you feel? Normal. Awesome. Normal. Normal. Awesome. Awesome? Triggered. Triggered. Enraged. Sorry? Enraged. Enraged. Does any of that ring true for any of you? Yeah. Yeah. I'm getting lots of nods and hands going in the air.

Yes, so a whole bunch of anti-patterns there. Unfortunately, quite common in terms of the Agile imposition and inflicting agility upon people. Martin Fowler spoke about this at the Agile Australia Conference. He was writing about it in 2006. So yes, there's a whole bunch of anti-patterns there. Maybe that's not the best approach for ways of working and for flow and improving business outcomes.

The point of this talk is: don't mandate one way of working. We're at the beginner level across the planet on this topic for organizational agility, which, as per Gene Kim's definition of DevOps at the beginning of day one, is all about end-to-end value streams, about products around services, and around delivering better outcomes. Mandating one way of working is not the best approach to do this, and unfortunately lots of organizations are doing just this: the Agile imposition, the Agile industrial complex, forcing ways of working on people, forcing one set of prescriptive practices on organizations. I have a hypothesis that it's probably not the best approach.

Organizations are complex adaptive systems. You are a complex adaptive system. Your team is, your family is, your department is, your company is, your organization. You are complex adaptive systems. So you cannot fit one size fits all. It just is not possible. Complex adaptive systems are emergent. You don't know what the outcome's going to be. A butterfly can flap its wings and there can be a tornado 1,000 miles away. So you just cannot apply a one-size-fits-all solution.

Then the second part of the anti-pattern is mandating. Mandating practices on people is not in line with an Agile mindset. It's not empowering for people, and there's no autonomy in doing that.

Instead, give people a voice. VOICE is an acronym. This is a suggested alternative approach to the imposition of one set of practices across an organization.

The VOICE acronym: V stands for values and principles. First of all, agree what your values and principles are as an organization, and that needs to be unique to your organization. Even if you take, for example, a credit card business like Capital One or American Express or Barclaycard, each of those are completely different and won't necessarily have the same values and principles, don't have the same heritage, don't have the same background, don't have the same people, don't have the same leaders, the same impediments, and so on. So you have to identify what your values and principles are in your context, first of all. And they are context agnostic. Those principles apply across contexts. For example, focus on flow might be one principle. For example, customer obsession, respect for teams, respect for people might be another principle. So agree your principles.

Secondly, focus on the outcomes. We've heard this a few times. It's not DevOps for DevOps' sake, Agile for Agile's sake. It's about business outcomes. And in terms of buy-in, in my previous role, we made the mistake: we were using the A word a lot and the D word and the T word for transformation. Then we flipped the message to outcomes and better value, sooner, safer, happier. Then the resistance just drops away because you're not trying to impose Agile or DevOps or even a transformation on people. The resistance just drops away. Of course I want to help delivering better value sooner, safer, happier.

And also purpose: the reason for change, the why. You've got to have the why there. Why are we doing this? Is it about survival? Is it because there's lots of VC money? Is it the age of digital? Or actually, let's not change at all. Do we even need to change? Maybe you don't need to change.

I is intent-based leadership. I think this is probably one of the biggest gaps at the moment, around leadership. The three most important things on this journey are leadership, leadership, and leadership. Leadership are either going to kill it or make it successful. There needs to be a flip from Taylorist command-and-control ways of working, as we saw with Mike Scott, to empowerment and autonomy, to transformational leadership, to servant leadership, to getting out of the way of people, to commander's intent, which I'm going to talk about in a second.

Then there's coaching and support. Again, because of complex adaptive systems, because there isn't one size fits all, and because it's emergent, people at the beginner level need support from people who have been there and done it and been on the journey. So you have to provide coaching. Impediments are not in the path; impediments are the path. That's where you need the support because it's just about your theory of constraints: identify your biggest impediment to flow, tackle it, move on to the next one. You've got to have that support in the organization to be able to bubble up the impediments. Some of those impediments are firm-wide. Some of those impediments require somebody, which is the role that I was doing previously until very recently, someone across the whole firm to tackle the big, gnarly constraints that need to be tackled. In the absence of that role, there's going to be limited progress.

And then experimentation, because complex adaptive system. Probe, sense, and respond. I've taken this from Cynefin. This is for complex work where the outcome is not knowable. First of all, you probe, you have a hypothesis. Those outcomes are your hypothesis: better value, sooner, safer, happier. We believe that doing this thing will lead to a better outcome sooner. Run some experiments, run a probe, sense, respond.

An important point here is these experiments are not reversible because this is a social science, not natural science. It's a bit like putting milk in coffee. You can't undo it. Natural science experiments are generally reversible, but social science experiments in a complex adaptive system are not reversible. You can do it, but you've changed the system. The system will never forget what you just tried. Whether you succeed or fail, that system will never forget the fact you tried that experiment. So you can only fix forward. You might fail and you need psychological safety and you need intent-based leadership, and then you fix forward on the experiments that you've run.

This is what I am proposing as an approach instead of imposing a set of prescriptive practices. It's harder and it requires more ownership. It's not in the absence of a framework, to be clear. It's not #NoFramework, Topo. It's #AllFrameworks, because in that experimentation, and this is what we did in my previous role, we didn't say to areas or teams what they could or couldn't do or how they should or shouldn't work. Teams were free to adopt any of the scaling frameworks if they wanted to, or none of them, or Scrum or Kanban. They could figure it out for themselves focused on better value, sooner, safer, happier. Even smaller waterfalls, if that works for that particular area.

Then you've got double-loop learning. As you run these experiments, you can then go back to your outcomes and update them because you might have got them wrong, or you might have made such fantastic progress it's time to update them. Have double-loop learning. You've got the first loop in the experimentation and then you've got double-loop learning.

Effectively, this is what we got to in my previous role. This is the approach that we got to. I'm just going to drill in a little bit on each of these now.

Values and principles. To quote Dan North, figure out your principles, apply your unique context, and you will come up with your own set of unique practices. Take your principles and your context, and from that derive your practices. Because if you've got two people who are super-quick turnaround, kind of RAD development, not big corporate IT, their practices are going to be very different, more like end-user developed applications. Maybe some stuff in Excel, some kind of VB, whatever. That's going to have a very different set of practices than if you've got 300 people or 1,000 people working on one massive product. If you've got Salesforce or amazon.com or whatever it is, the practices are going to be completely different. So that's values and principles.

Then having done that, agree your outcomes. As I said, the outcomes for ways of working that we iterated our way towards, and it took us, this was the beginning of year three when we landed on this, is better value, sooner, safer, happier. Again, it's up to each area to figure out how they achieve that.

In our case, how we measure these: better is our incidents in production. These are like the one metric that matters for these. We've got hundreds of metrics underneath that. Value you can't aggregate, so we use OKRs, objectives and key results. The key results are the value. Sometimes you can aggregate them, sometimes you can't. It might be market share, it might be revenue, but it might be diversity or it might be geographical locations. The value is unique. Sooner is lead time, release cadence, flow efficiency. Safer is control compliance, GDPR, information security, all the compliance stuff, so that it's agile, not fragile. And happier: employee net promoter score and also customer net promoter score as well. Happier colleagues and happier customers. That's what we measure in terms of ways-of-working outcomes.

And then intent-based leadership. As I said, this is super important. To quote Peter Drucker, most of what we call management is about making it difficult for people to do their jobs. Certainly, I've experienced that, being on the receiving end of some pretty crazy decisions that have been made centrally without involving anybody.

As I said, leadership team is team number one. What I've learned through making mistakes and through failing is, in the past we started at the team level and we'd gone across teams. We had senior leadership support, but we missed everybody in the middle. That's much harder to recover from than if you involve the people in the middle in the first place. So what I do now is I will start with the most senior leadership team I can possibly start with. You will only be as successful as the most senior leadership team. You might end up creating a little bubble of agility within an organization if you can't get to the top table. Start with them. Start with the mindset around flow and around autonomy. It's a journey. It'll take a long time.

In particular, just visualize the current system of work at a portfolio level using a Kanban board. At a portfolio level, just visualize how much stuff is in the system. That alone is enough for the oh-my-God moments, the light-bulb moments of, I can't believe we've got so much work in the system. Because very few leaders actually know the health of their system of work. Very few leaders actually know a single flow metric for their system of work that they're responsible for. Leaders will know their budget, they'll know the number of human resources they have, and they'll know the milestones. But will they know a flow metric? No. I think that's one of the most important metrics to know.

The other things are constraints. Constraints to maximizing value. How much money do you have? How much time do you have? How many people do you have? But that's not the end goal. So it's super important. You've got to know your flow. You've got to know your flow efficiency. You've got to know your lead time, and you've got to know the health of the system of work if you visualize it.

Typically what I often hear is that leaders and HiPPOs, highest-paid person's opinion, they're the ones who are pushing more work through the system. So it's a case of stop starting, start finishing. But actually what's been happening for the last 20, 30, 50, 100 years, it's been a case of start starting, just keep on starting, and just keep pushing more stuff down the pipe, which I touched on in the DevOps Enterprise Summit talk in London. So you've got to stem the flow at the head of the pipe, and there's multiple portfolio levels, which I spoke about in London.

Start with the leadership team. Then get the next team down. Get one direct report from this leadership team who is willing to be an early adopter, got the right mindset, got the right natural habitat to do some experimentation, willing to experiment, psychological safety. And then the next manager and team down, and just get a vertical slice of the organization all the way down to a team of doers who are actually delivering value. Nail it before you scale it. Start with that vertical slice and then go sideways. That's the approach that I take now.

Psychological safety. I'm sure you've all heard this plenty of times. This is the most important characteristic for high-performing teams. According to the Google survey, Project Aristotle, it doesn't actually matter who's in the team. It is not correlated to performance of the team as to who is in the team. The number one determinant is psychological safety: the ability to say, I don't know; the ability to experiment; the ability to try something and fail and not be ridiculed by your team members, or not be fired or whatever. This is the highest-correlating factor to team performance, psychological safety.

High alignment and high autonomy. Commander's intent. High alignment is the commander's intent is clear. This is the mission. The mission is better value, sooner, safer, happier. The mission is we want to help more people in lower income bands to get onto the housing ladder. That might be another outcome specifically to do with mortgages, for example. Provide that high alignment. What's the North Star? And then high autonomy. Leave the teams to figure it out for themselves. Run experiments, have it as a hypothesis. Have nested cadences for getting that feedback and that experimentation.

The locus of control, by having that high autonomy and having servant leadership and having intent-based leadership, moves from external to internal. When I am free to decide how I'm going to achieve an outcome, I take psychological ownership of that, or we do as a team. I'm now bought into it. Mentally, I am bought into that and I am going to succeed or fail, or learn rather, as I do this. But the locus of control is internal.

If a leader is telling their team, you've got to be a Certified Ski Master or a Certified Piste Owner, you've got to have two-week iterations, they've all got to be synchronized, then the locus of control is external. I'm no longer taking responsibility for the outcome of what happens because, well, I've just been told that we need to do two-week iterations and I need to be a product owner. I don't really know what it means. The locus of control is external.

There's a thing in psychology called agentic state. Has anyone heard of agentic state? Nope. Agentic state is what I've just described. It's where someone in a position of authority tells somebody else exactly what to do. There's a bunch of experiments called the Milgram experiments where a stranger gives an electric shock to another stranger. There's a person in a white coat sitting next to them. They have to answer questions. If they get the answer wrong, they have to give a higher and higher electric shock to the complete stranger. Sixty-five percent of people in these experiments give a lethal-dose electric shock to a complete stranger. Sixty-five percent of people. You can Google it, Milgram experiment.

Because it's someone in a white coat in a position of authority, and because the locus of control is external, it's agentic state. It explains a bunch of other stuff as well, which I won't go into. If in an organization you have a leader who is completely dictatorial, autocratic, telling people exactly how to work, people will do it. They will do it no matter what the outcome, no matter if you fly the plane into the ground and the company doesn't survive: well, the leader said, the boss said, so I'm doing it. So super dangerous. Intent-based leadership is important.

To quote Adrian Cockcroft, currently at AWS, he was at a CIO summit and some of the other CIOs said to him, we can't find the talent. He said he looked at them, he looked at what companies they were working for, and he said, we hired them from you and got out of their way.

And then coaching and support, because, like I said, it's a complex adaptive system. Shu Ha Ri: beginner, intermediate, and expert. And when you're at the Shu level, there's a typo there that should say Shu. When you're at the beginner level, you want prescription. You want to be told what to do. A bit like a martial arts dojo, a bit like dojos, DevOps dojos. You want to be told what to do.

So the trick there is to be able to have prescription, to tell people what to do, without telling people too much what to do and still having them feel in control. It really is coaching. It really is a case of asking questions and trying to reflect back to that team as to how do they think they could improve, and then sometimes nudging them in the right direction.

If you're learning to fly a plane, drive a car, or play a musical instrument, you have an instructor. The instructor sits next to you while you do it. If you learn to ski, you have an instructor who skis in front of you, skis next to you, then skis behind you when you're learning to ski. So it should be no different for this.

Fractal COEs. In my previous role, we had centers of enablement. I was running the one which was across the firm, and then for each business area we had a center of enablement. The number of people we had were always in single digits in each of these teams, and they were there in a coaching and support manner. We have a network of change agents, and they are there to support the people who are trying to improve. That is a pattern that we had some success with.

Guardrails. You've got to have guardrails, especially if you're a regulated company, and there isn't a single company that isn't a regulated company. So it's autonomy within guardrails. In my previous role, I was owning the guardrails. I was the one that said the MVC, minimal viable compliance, which is that awesome acronym, which I think is going to stick. We defined the MVC, we defined the minimal viable compliance, and then you can experiment within those guardrails.

And then the Toyota Coaching Kata. I have found that this is a great approach for middle management. Give middle management an explicit role, which is the Toyota Coaching Kata. A middle manager is coached by their boss as to how their team is doing based on the Toyota Improvement Kata. You've got a number of improvements you're working on. The person that you report to is coaching that person and a few others on how they're doing on that, and then that middle manager is coaching their team. Again, it's a coaching relationship, so it's asking questions. Dear team, how are you doing on fixing this? It's not prescriptive, but it's like, and how can I help? A bit like an Andon cord pull, servant leadership. By doing this, it gives leaders at all levels an explicit responsibility for improvement.

And then finally, experimentation. Visualize, stabilize, optimize. Again, to quote Dan North, visualize the work in the system first of all, which is a shock when you see it. Secondly, stabilize the work, stem the bleeding, start to apply work-in-progress limits. By applying WIP limits, even if they're super high values to begin with, you're turning the system into a pull-based system. Then it is a case of stop starting, start finishing. You cannot pull another piece of work until you've created a slot, until you've freed up a space, even if you've got super high WIP limits to start with.

And then optimize. As the tide goes down, you start to see the rocks that were submerged and the shopping trolleys and the bicycles that were submerged, and then you start to clear them. Theory of constraints. You identify your biggest impediment, you clear it, and then you can reduce your WIP limits again, and you just keep on doing that. Before you realize it, your flow efficiency has gone from 10%, which is the average for large companies, to 20% or 30% or 40%, which is a two times, three times, four times improvement on throughput. It's actually not that difficult.

Probe, sense, and respond. Run experiments, have hypotheses, have nested cadences: annual cadence, quarterly cadence, monthly cadence, weekly cadence, daily cadence, hourly cadence. Like I said, I spoke about this in London in June.

To get started, number one, start with a leadership team. Number two, do a vertical slice. Number three, with everybody in that vertical slice, with an engagement model involving everybody, work on VOICE. Work on your values, your principles, and your outcomes. Don't just have the leadership team do that in isolation. Number four, start small with an end-to-end view of the work. Start with one or two teams, but look at the whole value stream. Don't just look at IT in isolation. And then number five, fan out sideways.

That's my advice for getting started. In summary, give people a voice. Thank you.