Jonny Williams works at Red Hat as an agile Delivery Lead, and he joins Tiny DevOps to cut through the confusion surrounding "Delivery Management".

In this episode...

• What is "Delivery Management"?
• The discipline vs the role
• Comparisons to Product Management, Agile, Lean, Scrum, ITIL, and ITSM
• History of Delivery Management
• How does Delivery Management fit into "Agile"?
• Where is Delivery Management most popular?
• How can you start benefiting from the Delivery Management discipline in your organization?
• How to get started as a Delivery Manager
• Who should avoid Delivery Management

Guest
Jonny Williams, Agile Delivery Lead at Red Hat
Web site: https://delivervalue.uk/
LinkedIn: https://www.linkedin.com/in/jonny-williams-83433836/

Resources
Book: Delivery Management: Enabling Teams to Deliver Value

Transcript

Jonathan Hall: Ladies and gentlemen, the Tiny DevOps Guy.

[music]

Jonathan Hall: Hello, everybody. Welcome to another exciting episode of the Tiny DevOps Podcast. I'm your host, Jonathan Hall, and today I am joined by author Jonny Williams, who has just released a new book, we're going to talk all about it. Welcome, Jonny, thanks for coming on. Before we dive into the topic of your book, would you introduce yourself? Tell us a little bit about your background, who you are, what you do, those sorts of things.

Jonny Williams: Yes, absolutely. Thank you so much for having me on, it's really good to be here, really excited to have a conversation about the book as well. My name is Jonny Williams, I currently work as an Agile delivery lead at Red Hat so effectively working with customers to enable their adoption of container platforms and automation tools and effectively move towards that more DevOps-aligned culture. Broadly speaking, it's thinking about people, process, and technology, rather than just focusing on one of those three. It's a really interesting role and I love working with people who've got really deep technical knowledge.

The thing that I enjoy most is bringing some of that culture change alongside people who are really smart and really understand quite complex technologies. My background prior to that has been working in the UK public sector. Working as a civil servant for a number of years in DWP during the course of the pandemic. DWP is our Department for Work and Pensions in the UK and I was working with platform teams in that space. Doing hybrid cloud work, Kubernetes, all that good stuff, but really working in that DevOps domain and exploring agility, and just trying to enable people to do amazing things and make amazing things happen.

Jonathan: When you announced on LinkedIn, what has been now two, three weeks maybe? That your book was out. I didn't even know you were writing a book. I don't know if I should have known that, but we've followed each other for a while on LinkedIn and I saw the book and the title just jumped out at me. The title, spoiler, here we go, is Delivery Management. I'd heard that title, the job title, maybe for the first time a year ago and it's been confusing to me. I imagine it is for other people too and, of course, your book addresses that. I'd like to clear up some of that confusion today if we can and dive into a little bit about some of the things your book talks about. Let's just start with that. What is delivery management?

Jonny: That is the question at the heart of the book. For me, the journey of writing the book really helps evolve my understanding of it because I think it's a question that a lot of people have. I would say, and the way that I've defined it in the book is that it's a discipline and that it's a discipline that focuses around aspects of enablement. That's really the way that I've framed it in the book. Impediment removal, coaching, and facilitation, but I think as a discipline, it's very tightly tied up with a role oftentimes people talk about and that job title of delivery manager.

Myself, whilst I was working in the UK public sector, I wasn't an Agile delivery manager because there's flavors of delivery management that exist in the public sector. Equally, when I was talking with Marty Cagan about the book, he as someone who has written about delivery management nudged in that direction of saying, "Well, actually, there were private sector organizations, and especially large enterprises that had really explored whether that as a role could bring value."

For him, he's framed it previously, which is something I explore in the book and his book inspired as it being something aligned with enabling product teams, which I fully agree with, but almost for him, he sees it as more of an evolution of project management. Personally, I prefer to decouple it from project management because I think actually, there are project managers who will stay in those roles and retain that job title. It's not to say that they can't harness the discipline of delivery management because for me, those three aspects of enablement can be used by almost anyone, from engineering managers to engineers themselves, or whether it's product managers as well.

There's aspects of the discipline that I think people can use. However, I think it is distinct from project management and I think that's really important to call out. In many ways though, it does align very neatly with Agile coaching and Scrum mastery but I think the difference is, first and foremost, it's not aligned, specifically to something like Scrum. Then equally in terms of the Agile coaching domain, I think it involves having a bit more skin in the game. There's a bit of a closer tie to the team and especially in terms of that impediment removing aspects.

I think a lot of the time Agile coaching is more about enablement in the sense that you're teaching other people how to move forward with something or helping them to find solutions. Whereas delivery management does have a bit more of that time where actually you have to proactively do things yourself to really make things work for a team and ensure that they're not being blocked.

Jonathan: Fascinating. I actually think I was introduced to the concept of delivery management by Marty Cagan also, I was reading his book. After reading that I actually went to some of my friends who work as Scrum masters and Agile coaches and I said, "Hey, what do you know about this delivery management concept?" Their reaction was very negative, actually but I'll explain that a little bit more. It was like, "Oh, I think that's an old term or it's like a project management term." They had this idea that it was a straitjacket they have that some organizations make you wear.

The same way that some people look at SAFe or even the Scrum master role. If you don't like Scrum, you look at the Scrum master role that way, right? I get the sense that is the same dichotomy we often have. If you've worked in an organization that does project management really well but in an organization that has done Scrum, very poorly, then you have this negative opinion of Scrum masters and product owners and whatever or you have this warm, fuzzy feeling about product managers and vice versa. It doesn't matter where you land. You think that one way, your way is the warm, fuzzy, nice way and everything else is the straitjackety, nonsense, old-school way.

That's the vibe I got about delivery management but reading your book, it's completely not that at all. At least the way you portray it. I read that book and I'm like, this is great. I haven't finished the book, by the way, but everything I read, it's like, "This sounds great. This is exactly the work I like to do to help empower people, and work with people, understand their problems, all this stuff. I guess the point I want to make here is, if you have the idea in your head that delivery management is this straitjacket, that some organizations make you wear, maybe try to approach it with a more open mind and shed that preconception.

Jonny: Yes, I could fully support that. I think that was one of the big drivers behind writing the book was effectively, it's something that's really poorly defined. I almost think it's really interesting in comparison with some of the frameworks and structures that exist within things like Scrum and SAFe because oftentimes, I think it's almost easy to disprove. I'd say especially with Scrum, having studied Scrum, and worked in really effective high-performing Scrum teams. The most effective Scrum teams were the ones that were using stuff from Kanban, that were using stuff from extreme programming, they were really applying good DevOps practices as well.

It was not aligned purely to, here's the basics of the Scrum guide, plus all of these things, which really feel a bit more like anti-patterns. For instance, being really tied to a story pointing, for instance, which I know a lot of people nowadays would probably be quite keen to reject. I think delivery management, in many ways, feels similar. It has been for a long time lacking a definition, really. I think that the way it's described in Marty Cagan's writing, I think other people like Emily Webber, for instance, who's very prominent in the UK public sector, the way that they have described it has really helped.

Nevertheless, there are plenty of organizations who are using delivery management as this quite archaic very command and control job title, that is really holding teams back rather than enabling them to move further forwards. For me, one of the key things especially having worked in a number of teams and organizations where delivery management was almost being used by quite senior leaders as a bit of a stick to beat people with and especially, this is something I know that Allen Holub talked about in terms of rejecting that delivery manager job title has been to say, well, someone can't be the lone person who's accountable or responsible for delivery.

I completely agree with that. In many organizations, delivery management is seen as you're the person who's carrying the can, you're the person with delivery and your job title is solely responsible for everything delivery related. All of us who've worked in high-performing teams know that's daft because teams either fail together or they succeed together. They learn together, or they go on and effectively uncover new things and experiment together. It's one of these challenges for I think, a lot of leaders, a lot of organizations to really get their head around the fact that teams have to own stuff together.

Delivery management is not about being the person who carries the can, much as a product manager can't be solely responsible for the lines of code that are created. In fact, is about enablement. It really is about helping teams to achieve more and deliver value collectively, and remove the things that get in their way that block them from actually achieving that outcome.

Jonathan: How old is the title or the practice of delivery management? I only heard about it about a year ago but clearly, it's been around longer than that. Do you have a sense for the history of this role?

Jonny: The most familiar space where I'm really aware of it is in the UK public sector. If anyone hasn't looked at the gov.uk revolution that happened in government digital service in the UK, there's a few governments that have really done innovative things. The government in Estonia who've done a lot of amazing digital work, Ukraine, as well have done some fantastic work in the digital space and I think that's been proven over the last year in very difficult circumstances, but roughly around 10 years ago, the government digital service was created in the UK and this was an initiative to effectively accelerate digital delivery. It's very much badged within that digital framework, which I know many of us working in the tech industry wouldn't necessarily align ourselves even with the badge of tech or digital because really, it's either just product or good engineering but actually, a lot of this space of government digital service embodied good product principles and good engineering principles.

They hired some fantastic people and the delivery manager role rather than maybe the discipline or they think they are quite closely connected in terms of that government context, really began to emerge in the UK public sector with the emergence of government digital service. Prior to that though, there is some talk that delivery management in its more Agile-aligned, I guess is one way of putting it, or Lean an Agile-aligned form was something that existed in Spotify. That's always quite interesting. That was something I researched with the book and wasn't able to find strong proof of what form it had existed in if it ever did exist at Spotify.

It might just be part of the myth of the discipline. Then prior to that as well, I think delivery management by its title feels quite logistical. Actually, that's something with the book where I've had to be quite explicit to say, this is delivery management as a discipline. We're not talking about logistics, we're not talking about service delivery management as well, which is obviously closely aligned with ITIL and ITSM.

In terms of service delivery, that fits with a very traditional IT project management aligns even looping into some of the mythical man-month type stuff where we're talking about where does software go or where does IT go once it's been delivered?

In this modern day and age, I think we all know that software isn't the same as building a house or it's not the same as building a bridge which you just hand over to the people who are going to give it a lick of paint every 5, 10 years. We all know it's continuous. It's organic and it's socio-technical, but in many ways, the history of the job ties into aspects of that as well where you have someone setting these guide rails for people to deliver something, but it's fixed much more like project management for instance.

I think in the modern sense though, and the way that government digital service kicks things off from my experience, personally, and where I learned about stuff and really where the origins of what I believe is this discipline in the modern day and age really is tied into a lot of those ideas about product teams and about enablement as opposed to control.

Jonathan: Your experience naturally starts in the UK because that's where you're from, but even in your book you talk about some of the adoption in the United States. I'm just curious, is there a regionalism to delivery management? Is it stronger? Even like Scrum I think is pretty strong in the Netherlands more than it is maybe in the US so a lot of these things they get popular in certain regions. Is delivery management more popular in certain areas than others?

Jonny: I love that observation so much. I think that's absolutely spot on. I also think it's really fascinating that Scrum has really taken hold of the Netherlands and it's given us a gift of many talented and knowledgeable practitioners and experts from the Netherlands. People like the Liberators for instance, who just do fantastic stuff.

For me, delivery management and the sales of the book have illustrated this to a certain degree. Regionally, I think it's quite popular in the UK but then that has started to spread out globally slightly more. For instance, organizations with roots in Canada and Australia have got more delivery management going on.

I think what's very interesting in the US for instance though, is that stuff like engineering management, which isn't necessarily as prominent in places like the UK and Europe, I think if anything, again, it's very loosely defined. If we were to frame engineering management as a discipline as opposed to a job title, I think in many ways we'd struggle.

I think many organizations though have gone down that pathway. The thing that I find most interesting about delivery management and its regional prominence is probably that the UK public sector has propelled it, but I know when I was speaking to people in regards to some of the beta readers for the book and its evolution, people did call out and say this has existed.

Certainly, this set of disciplines exists in organizations. It's just that a lot of the time it gets bundled in with Agile coaching and Scrum mastery. I think it's useful though to draw that out and distinguish it because of those reasons of-- It's actually healthy for me personally, I think to move Scrum away from being a job title to a Scrum master really being that accountability of a set of things that help because otherwise, Scrum master paints the picture of being an end-all that it'll give you everything that you need to do. Whereas actually there's a lot of gaps and a lot of spaces that exist within that Scrum master accountability.

Similarly, with Agile coaching, I think that again it makes more sense as a discipline as opposed to just being a fixed job title or role. Especially as there is obviously that aspect of the Agile industrial complex of people just getting certificates and really the credentials that someone has need to live up to being able to really help people. I think being badged as the coach or a coach for an organization is quite a high bar really.

I think where delivery management is good and where it can fit in is that it's at more levels than some of those roles and more agnostic and more open-ended, but especially as a discipline. For me, I would really say in places like the US where there are product managers who potentially are having to carry the burden of doing a lot of enablement and coaching work as well as trying to hold all of that information for customers in their heads and support teams, delivery management might be able to help. Whether it's bringing in someone else to support with that or potentially enabling an engineering manager to take on more of that impediment removal and coaching work or even in terms of teams where I think actually, you've got self-organizing teams.

I love this idea quite a lot of self-organizing teams that are purely made up of engineers or researchers where you don't necessarily have someone and very much in that small startup organization space where it really is just a bunch of engineers, but they're thinking, well, there's probably some cultural stuff that we can work on.

Again, it's another space where I think delivery management can help. You don't need to wear the hat of being the "delivery manager" but I think as a discipline if for people who are in these spaces regionally, where they're not necessarily working in teams where there is someone functioning as an enabler proactively, but they think having an enabler in that space might help.

My personal argument is that how could it not help? Actually picking up delivery management regardless of job title is good. I think it fits with that idea of which is true university I think around the world, is that we are starting to realize that job titles can actually hold us back quite a lot.

Arguably it's about the disciplines that we apply more than anything. That's where something like this and hopefully reframing it as a discipline can maybe move people forward a little bit.

Jonathan: I do want to talk more about the title concept a bit in a moment. First, I want to explore a little bit more where this discipline is used. You see it growing in the US and other places I guess. Where does it have the strongest foothold? Is it strongest in certain industries or certain company sizes? Is it small companies, big companies, or is it across the board?

Jonny: I think what's really interesting from my government experience in terms of scale is that it is present throughout the UK government. I've seen it really prominently in that space. That is broadly speaking, as I say, there are a few flavors of delivery management that exist, but really aligning it to the discipline as I've described it, it's prominent throughout very large-scale parts of government.

Department for Work and Pensions for instance, where I worked, if you purely looked at financial transactions, that would be the equivalent of the UK's largest bank. Obviously, as a country with a quite significant large financial services industry, really if you were to frame a part of government as the UK's equivalent of the largest bank it would say a lot the fact that that organization has been able to move towards DevOps and Agility and pick up these accountabilities or discipline aspects of delivery management.

I think scale is an interesting one because actually whether it's an organization who are one team pretty much doing all of the work, I think that delivery management can help because it's not just about coordination between different groups of people, especially in that more startup or scale-up space where I'm seeing a few more delivery managers start to appear and a few more people applying the principles within delivery management to enable that aspect of healthy teams that feel psychologically safe, high trust environments.

That in part is in the sense of actually the senior leadership people, so whether it's the CEO and CTO adopting aspects of this discipline as well. Understanding how to remove impediments, understanding how to apply stuff like team topologies to really think about the organic nature of their organization and how they want it to function. I think in terms globally as well, where it is starting to appear more and especially in private sector I think another reason I wrote about it as a discipline is that there's a lot more people starting to have this delivery lead or Agile delivery lead job title. I think that is relevant to this discipline because for many of those people in a more delivery lead-aligned role, I think it's almost exactly the same.

They are there broadly speaking, to be an enabler, to be a facilitator, a coach, someone who removes impediments. Actually, I think that the prominence of that lead title, which is gradually emerging more and more because I think, and I can relate to this, for a lot of people, it's not necessarily appropriate to give that manager title. I think it's often the issue that product management has as well of product managers often end up being treated as if they're the manager of the team, which they shouldn't be, and it doesn't really help anyone. I think delivery leads is starting to appear in more and more organizations of all different shapes, sizes, scales, and certainly across government organizations in probably places, as I say, like Canada and Australia, certainly in the UK though. It's one of those things, the leading charge off the back of the book really, is that I think if any teams are struggling or certainly organizations thinking, maybe our teams could be achieving more or slightly more effective, I think efficiency is not the right idea. It's more about effectiveness and achieving outcomes. Then again, I would struggle to argue the case that a delivery manager or someone applying delivery management wouldn't help. I think inevitably if you've got someone in that enabling space, whatever their job title might be, how could that not help?

Jonathan: I don't know what it's like in the UK. I don't know what the general public awareness or feeling is about the government, but as an American, I don't think about government programs and think agility and think efficiency, it's like when I hear about a government program in the US that's efficient and agile, it's like, wow, that's noteworthy. I don't know if it's the same in the UK, but just assuming that some of our listeners have the same concept that I do, that government means slow, bloat, bureaucracy. Can you give us an example of where delivery management has been effective in your experience in the UK government?

Jonny: Yes, that is such a good point and I think that it's something that actually Marty Cagan pointed out and he was like, you probably don't want to be talking about delivery management just in terms of public sector. I completely agreed with that and I was like, yes, this is not specific to public sector stuff. Where it has helped and again, to lean into the Department for Work and Pensions. I think some of the successes that I've seen, whether it be gov.uk, which I would urge people just to look at the story and the history there and some of the great people who've worked in that space and especially the achievements around actually delivering accessible software solutions for citizens. Stuff that is really easy to use beyond just gov.uk, the website, but also stuff like Notify, which is a service that was created by government digital service that basically it's is consumed, it's a component that lots of other parts of government can consume to send out text alerts and stuff like that.

It completely simplified a space that was really hideous and complex. The classic thing of look at an organization, the odds are they'll have 26 different address lookup services or something ridiculous and actually I think looking at simplification and considering stuff like bounded context and these sorts of things are spaces where actually delivering management, again, it helps because it's coaching towards things being more effective and really honing in on what outcomes people are trying to achieve. That space of government digital service is a key one but I think also I always talk about in the Department of Work and Pensions, so we have a thing called Universal Credit, which effectively is like the benefits payment solution and that was a space that was really struggling because it was a very ambitious policy, which was it completely tied into that space of bloated government programs that weren't really going anywhere treading water.

It was this space where they moved away from big bang, let's design some massive plan on a wall and actually shifted much more towards, well, what's the smallest valuable thing that we could deliver? So actually, Universal Credit is an incredibly modular solution, which when we hit the pandemic and we needed to shift the model of benefits payments. Of course, when we talk about benefits claimants, the largest group of people receiving benefits are pensioners in the UK, and oftentimes we look at pensioners as being completely separate and distinct, but actually, these are people still receiving payments on a day-to-day or weekly basis.

We had to change the model almost completely. I say we, UK government and people working, doing incredibly long hours to get this done over the course of the pandemic in the Department of Work and Pensions. It was because of that modular construction, because of the way that it was designed to actually be iterative and incremental that enabled something that normally when we look at government, it is, and I've experienced this firsthand, there's aspects in the book where I talk about large scale transformations that were just destined to die a hideous death whilst wasting loads of taxpayers money because of the fact they were trying to do this big bang insane stuff without really thinking about culture or whether people are ready.

I think instead about the stuff with Universal Credit, for instance, just as one example where to create something is that large and provides that much value to citizens of a country but actually could scale and shift and mold itself rapidly in an emergency. I think that really shows the fact that actually governments can move in a more agile direction.

They can deliver stuff in a more incremental, iterative way and really harness the learnings as well of successful private sector organizations because it's not that the private sector gets everything right. I think we're all eagerly awaiting the outcomes and stuff, like Twitter for instance as well.

I know all of the chaos that's happening there which feels like it could be a bet that turns out in the direction that a lot of people are thinking it won't, but equally feels like it goes against a lot of my beliefs personally at least.

Jonathan: Yes. I'm not placing bets either way on that one.

Jonny: No, I'm keeping my money in my pocket, personally. The money is staying in my hands. I'd rather not. I'd have to have a really good spread bet I think to ensure that I didn't lose out right. I think it's a good example though where actually the core principles really for what I've seen in government, which are probably more important for private sector organizations than for the people that look at government as well and go, bureaucracy and slow delivery effectively and not actually achieving something valuable. The key difference in the stuff that I've seen, which I now champion, this is one of the big things that I do for work, is trying to get people to move away from that. It's definitely an uphill battle, but there are really good people who are trying to learn from industry and actually read books.

That's one of the things that does frustrate me sometimes is when we talk with senior executives and leaders and it's just like, when was the last time you read a book? I think you can tell a lot from people. It doesn't have to be a book, it could be an audiobook or read blog posts or whatever it looks like, or just follow people on LinkedIn, but the less that those people are engaged with ideas, the less likely it is that they'll actually be able to support an organization to perform effectively. Working with people who really champion change is what I love doing and those people do exist even in slightly more hostile environments where the waterfall is still the defined way of doing things.

Jonathan: That's a great segue. You mentioned waterfall. What is the relationship? We've talked touched on this, but I want to make it more clear to the listener. What's the relationship between delivery management and Agile software development? Is it an Agile framework, methodology? Is there overlap? Are there differences? How do you describe that?

Jonny: I don't intrinsically tie it to agility. I think this is something that previous attempts to describe the discipline. I think Emily Webber's description of it previously where she talks, one of the key elements is Agile and Lean practices or ensuring that teams are able to apply Agile and Lean approaches for one thing. I think actually Agile is often something that's, people turn their nose up at it a little bit and I think Lean less so because it's easier for it to be validated in that manufacturing context where really it is proven time and time again.

I would argue that agility isn't Agile, but I think capital A Agile has ended up really limiting the progress in that movement and moving us away from some of the stuff in the manifesto. I had a really good conversation with someone a while back about DevOps really being quite an organic evolution of Agile really it's kind of the same thing but just with slightly more defined cultural aspects really.

I like talking about DevOps as an approach more than anything else as well but it's fascinating to see as well, DevOps is falling out of favor with some people and now they're talking about platform engineering, and after that there'll be something else as well. It will always churn. There'll be always a new thing emerging, whether it's driven by the big four or whether it's driven by people on the ground, whether it's driven through companies like GitLab for instance when I did their team ops training the other day, which is very similar principles, it's very similar content but with a new badge, with a new title.

For me, I think that delivery management isn't intrinsically about agility or about Lean, in fact I should say Agile and probably lean into big A Agile because it is about agility but probably in the looser sense and true business agility of really delivering value because that's what business agility is all about. I don't think you have to be an Agile and Lean or consider yourself at least to be an Agile and Lean practitioner to harness this.

I think a lot of stuff, I did read a great thing the other day, it might have just been a simple tweet, but someone said, common sense doesn't really exist because common sense is purely objective. It is about your lived reality and your lived experience. I would almost avoid saying that a lot of this stuff in the book feels like common sense because feels like common sense to me because I've seen teams succeed and I've seen teams not succeed. I wouldn't like to say fail, but maybe not do as much as they could have done.

I think a lot of the stuff in the book and in terms of delivery management as a discipline, as soon as it's in motion, it becomes really apparent why this works, why it makes sense to build an environment where people feel like they trust each other, where they feel psychologically safe and that isn't something that is prescriptively tied to Agile or prescriptively tied to Lean or any framework. It is stuff that really that for one example of building a space where people actually feel like themselves, where they feel okay, that is universal or at least it should be and actually I think that means it doesn't just have to be people who are operating in this space where maybe they've certifications and they're Scrum masters or they're working in product teams in certain organizations. I think again, there is a universality to coaching, enablement, facilitation as things that can really support any team to do better work to achieve more and also to do it sustainably. I think that's a key part as well, is it doesn't have to be tied to Agile because of the fact that really any organization should be looking to deliver value in a sustainable fashion and achieve valuable outcomes ultimately because otherwise, the question is why do they exist? If they exist to deliver value, I think delivery management can help.

Jonathan: Does delivery management work for non-software projects or is it specifically a software discipline?

Jonny: That is a really cool question because I have some fantastic examples that I jumped into further whilst I was writing the book. Actually, it gave me a good kick up the backside to not just write about software because platform engineering and working with teams that are doing stuff around OpenShift and Kubernetes is what I'm doing day in and day out at the moment. I'm in my rabbit hole of software and quite complex technical delivery working on some middleware stuff as well at the moment which is deeply technical and quite interesting. I've actually worked with people where delivery management was applied in a way that's really well aligned to the book in a marketing context which is fascinating. I think really looking at marketing as more of a product and shifting away from it being again that almost the traditional way that the business IT paradigm existed and still exists in some organizations.

I think marketing is often looked at that way as well, but really treating a marketing offer as more of a service with intrinsic products within it aligns really nicely with delivery management because I think again, to have someone who's there enabling a team to collaborate, support each other and move towards valuable outcomes that are clearly defined all of that stuff, and especially in marketing context as well, they still have the questions of when will it be done? Bringing some of these principles and practices to that space is really interesting.

The other one as well, which is a good example which I think really feels beyond software but actually is quite closely linked. I talk in the book, I refer back to that classic idea of software eating the world. I think everything pretty much is software nowadays but the few things that sometimes feel like they aren't software, policy was a great example and there's a fantastic guy, he's on Twitter called James Cattle, who does loads of brilliant community work across UK public sector, but shares a lot of really insightful things.

James Cattle actually called someone out a while ago saying, "Don't talk about delivery management as if it's purely for software teams or product teams." I'm working with a policy team at the moment who are doing psychological work. This was his big statement. We are working with psychologists, we're working with user researchers, we're working with people who are defining really detailed and difficult policy and we're doing great delivery management. I thought that was fantastic and I love the fact that you called it out as well in a really blunt way. It could be a team of psychologists, a team of marketers. I think again having that enabling function and discipline in a team is sure to help them.

Jonathan: I think it's pretty clear from the context of what you've been describing the answer to my question, but I want to just make it explicit for anybody listening, the title delivery management almost sounds like it's a last mile job. You do all the design, you do all the building, you do all the testing, and then you deliver. That's not what you're talking about though. You're talking about more of a holistic approach and maybe just address that a little bit and make that clear for anybody listening that this isn't just like a last mile discipline.

Jonny: Yes, definitely. That way of viewing delivery is almost like framing a marathon as being just the moment that you crossed the finish line. I think what's really interesting with the way that we often talk about delivery is that moment where something moves on the Kanban board to done, but actually what about all of the stuff before that? I think just like with a marathon, it isn't even just when you start the race, it's all of the other stuff as well. It's all of your training, it's all of your prep, it's all of the ways the shoes that you're buying to run in. I knew a guy who recently ran a marathon cause he was trying to break his record. He bought a blood sugar monitor that was plugged in. Whether it's the small things or the big things, I would personally look at all of that and say that's still delivery.

Because really delivery isn't about when you move the thing over in the column to done or when it goes into prod. This is something I've talked about quite a few times is, can you really say anything is done if it's not running in prod or if users aren't even touching it. Is anything done until actually it's interacted with? All of the stuff that comes before that moment of someone picking it up and playing with it or pushing buttons or clicking on it. All of the stuff that comes before then in my mind is also delivery.

I think it's a challenge for some people to look at it that way because oftentimes we talk about the user research or the design before we move into a delivery phase. I think all of the things that come before that "delivery phase" are so intrinsically linked to realizing and achieving valuable outcomes that you'd be insane not to join up those dots and ensure that everything that comes before that is supported and actually easy to accomplish as well.

Jonathan: I think anybody listening is probably familiar with a lot of the baggage and bad habits that come with terms like DevOps and Agile. You mentioned story points that's taking on that feeling in a lot of corners. The story points are remnant of the past or maybe they're at least not done well, maybe there's a good way to do it but they're not done well. Do you have the same thing in delivery management or is it early for that and if so, can you give examples of some bad habits or cargo culting that might happen around in that discipline?

Jonny: Sooner Safer Happier was a big influence on the book and the stuff that Jon Smart's written about. Thinking about anti-patterns and patterns was something that came to mind quite frequently whilst I was writing the book. I think some of those anti-patterns are when people might feel that they're inhabiting that delivery management space. This is a reason I talked about it as a discipline rather than a job title because I think it's easy for someone to have that job title but actually be working as a project manager. For me, that feels very different. Those are very different things and I know Allan Kelly's book, for instance, Project Myopia where I think he talked about the fact that projects and Agile are intrinsically at odds. It's very difficult to reconcile those things because projects are fixed and limited and about command and project management is very much about top-down stuff.

I think for me, as much as project managers can add a lot of value in organizations, one of the biggest anti-patterns is someone who's wearing that hat of delivery manager, but actually, under the hood, they're working as a project manager. I think the other aspect that comes with that is even if you are attempting to apply the discipline of delivery management regardless of your job title regardless of role, it's misunderstandings around the coaching aspects and coaching can be really difficult. I think it's very tough to be an effective coach whether you are working as a technical coach, someone who's in that directive coaching role.

I talk about the difference a little bit between someone who's like a football coach who's more directive. You help people learn the plays, you help them understand where they need to be stood on the field as opposed to non-directive coaching which involves more like that professional coaching stance of asking open-ended questions, powerful questions that help people uncover stuff for themselves and maximize their potential by seeing the stuff that was in themselves for the whole time.

I think really understanding that coaching function is one of the biggest challenges for effective delivery management. One of the largest sources of anti-patterns that I've seen is where people are dogmatic or almost too directive because I think as soon as you are the person who's saying to the team, you need to do this, you need to do that and especially the biggest thing that I've seen that really I struggle with, which aligns with that point I made around project management, the idea of someone who says that they're applying the discipline of delivery management whilst dishing out tickets and telling people what they're doing for the day, I just think is out and out wrong.

I just don't think that helps a team to really deliver value or achieve the outcomes they're working towards because they're a room full of adults and adults don't need to be given stuff in that way. They're not robots, they're not machines. Moving away from Taylorism and that aspect of some manager stood at the back of the room bossing everyone around, if you're doing anything that looks or feels like that, then you're not doing delivery management.

Jonathan: Let's talk to the listener who thinks that delivery management might be something that they could benefit from. Maybe they're not doing it or maybe they're not doing all of it yet and they think they could benefit. How can they get started in exploring this? Obviously, they can buy your book and we'll provide details on that at the end of the show. Let's say that they're in management and they have the authority to start making some changes along this way. What should they do? How do they get started on this journey?

Jonny: For me personally, I think the best advice I'd give almost with anything, any type of change, is just start small and find the place where you can affect change that's the most minimal, smallest possible thing, the smallest slice of value that you can look at. Thinking about delivery management as a discipline in terms of those three aspects of enablement and coming really back to the heart of delivery management being about enabling other people considering those aspects of impediment removal and coaching and fascilitation, it could just be starting with something really small. I'm big fan of the book The Coaching Habit, and I talk about that briefly in the book. Reframing your management stance away from being a manager, let's say, if that's the role that you're in or something that's maybe a more traditional role where actually you want to move towards being an enabler rather than a director, let's say. I think that moving towards stuff of using powerful questions for instance and applying a listening stance rather than a directive stance. Certainly one of the things, a really tiny thing that I'm a huge fan of is if you're in a room full of people, it's some of that leaders eat last mentality. Rather than saying, here's what I think now, what do you think? It's even that small switch, which aligns really nicely with some of the stuff in the book to saying, "What do you all think first?

Then saying, "Great taking that on board, here's how I think maybe we could apply that." Again, going back out to say, not necessarily to get consensus, but at least to ensure that it's been communicated and that people understand where we are. For me personally, it's the really small things. For instance, with facilitation that ties in directly to what I've just said of just find those ways to give other people a platform and move away from being big boss. I think as well the book Turn the Ship Around shifting towards intent-based leadership where really it's about saying, "What do you want to do? How are you going to achieve this outcome?" Ensuring that people have got a clear vision, a clear direction they're heading in. If you are supporting all of that stuff, then I'd argue you're probably moving in the direction of delivering management already. There's a load of ways you can implement it, even in the smallest spaces of your organization. If you can harness it fully, I think the way it can move teams forward is just dramatic and really powerful.

Jonathan: Now for other listeners, maybe someone listening is-- Maybe they're a Scrum master, an Agile coach, or they have an inclination in that direction. They're thinking, "Hey, this delivery management thing sounds pretty cool. I'd like to learn more about that as a practice and it's a discipline." How do they go about that? Can they get certified somewhere? What kind of training is available? Where do they go?

Jonny: That is a really good question as well. I think obviously, really basic plug, I'd obviously be really keen to point people towards my book and give that a look and have a think. I think the title of the book says it all. It is Delivery Management: Enabling Team to Deliver Value. If that's what people are into, whether as a Scrum master or an Agile coach, then take a look. I would say beyond that, there is some training available from ICAgile, have a delivery management track. I've talked with them, actually had some really interesting conversations because at the moment their track involves their, I believe it's the Agile project and delivery management smaller certification, which is badged as I believe it's ICPAPM. I think there's loads of great content in that, but for me personally, I'm very keen on decoupling delivery management from project management, including Agile project management as well because I think seeing them as distinct and separate is valuable. Especially as for me personally, I think delivery management is better aligned to products and tying in some of the stuff like Mik Kersten's book Project to Product.

Really for me, I think that those long-lived teams, long-lived products, value streams, all of that stuff fits very neatly with delivery management as opposed to with delivering something up to an end date, which is much more closely aligned with project management, both of a traditional flavor or an Agile flavor. I think that that training is really good. There is a load of really interesting content on that. I'd say if people are interested, check out the learning outcomes that are on that track.

Broadly speaking as well, I think some of the facilitation training that's out there as well is a great stepping stone and coaching training is a great stepping stone to help people harness delivery management. The other thing that I'd urge people to do really is just consider those spaces, which I certainly think for Scrum masters especially, but Agile coaches do this as well, is to really reflect on where they have removed impediments, removed blockers and enabled teams to-- It's the stuff as well of don't just manage dependencies, remove them, kill them, cut them off at the neck. It's stuff like that where if you can reflect, I don't think you can ever really get full deep detail training on removing impediments, but what you can do is learn lessons and gradually transition from knowledge to wisdom, embed that stuff in, really reflect on it, really consider what is going to unlock that capability both in you but also in a team.

I talk about the Pareto principle in the book. Impediment removal is almost always going to be the thing that gobbles up 80% of the time, even if it only achieves 20% of the value that can be achieved. Whereas I think the coaching and facilitation aspects end up being a smaller part of the role, but probably the one that unlocks the most value in the long term. Be prepared for really tough impediment removal because it can take months if not years to remove an impediment, but when it's done, it opens up the doors to faster flow of change.

I think especially as well, it's an interesting challenge for people to see between that space of Scrum mastery and Agile coaching where delivering management is an interesting fit is you can inhabit the accountability of a Scrum master still. I was a Scrum master for a number of teams, but that wasn't my job title. I think equally Agile coaching-- I've Agile coached with a number of teams, but again, it doesn't have to be my job title for me to be able to fulfill that capability and take on those accountabilities. Maybe delivering management for an organization would be a really good fit in that setting as well.

Jonathan: Is there anybody who should not consider delivery management either for their company or for themselves? Is it the wrong match for anything?

Jonny: I think one of the spaces where just on the really high-level basic stuff is delivery management probably isn't going to help if what you're looking for is considering logistics or service delivery management, these disciplines that are different. That's a really basic thing. I have looked previously at some of the Google search results of people coming to my website delivervalue.uk, where actually seeing people where keywords are leading them there from Agile pizza delivery and that's a very different kettle of fish that you want your pizza to arrive at your door faster.

That kind of stuff is not really the delivery we're talking about. It's the delivery of value. Organizations where I think delivery management would be a challenge for me, it's where you know that you've got leadership that are not bought into this idea of enabling others and autonomous teams and they can go on that journey and I think they should go on that journey to really support people to get to a point of self-organization. Especially that aspect of, I know Dan Pink talks about it in his book Drive, but autonomy, mastery, and purpose. If you are working in an organization where no one really cares about that because your fulfilment is not important. If you're treated in that Taylorist way or as a boss, if you're listening to this and you think, "I don't need happy employees, I don't need employees that feel okay at work. I believe that I'm going to crack the whip and I'm going to just drive them to do whatever I tell them to do." That classic thing of JFDI just effing do it. If they're not following my orders, then they're dreadful employees and they can be booted out the door. If as a boss that's your mentality, then delivering management probably won't help.

Arguably it might help you to read it because you might start realizing that you're probably holding everyone back and you're actually limiting the value that your organization could achieve. I think there is a really interesting cultural aspect where I think this can set people on the path. I'd almost say read the book because it can set you on the path, but until you're on that path and taken a few steps, you will struggle to apply the discipline because if you're expecting to suddenly drop someone in who can remove impediments and coach and facilitate, but let's say your finance department is interested in nothing but projects and they want to know the start and the end and they want to know exactly how much a piece of software is going to cost them to create over the next three years, there's probably a bit of another journey that needs to be happening there. There's probably more change that needs to happen before you can really start to see the value of delivery management in your organization.

Jonathan: How would you go about recruiting someone to help with delivery management? Do you just put up a job description? We're looking for a delivery manager or is it more nuanced than that? Of course, that would be the easy answer? Oh, we need delivery manager, I'm going to hire a delivery manager and we'll be done. I suspect it's not that easy because it's never that easy. What advice can you offer in that regard? [laughs]

Jonny: I think that's such a fascinating space. I actually saw something very similar in terms of-- It was someone advertising a job for their first person in product manager. In terms of that first person on the ground product manager in an organization, that's a really tough space to operate in. I think if you're going to land in that space, and this tangent does tie into your question, so be rest assured. I think that in terms of that space is like first person on the ground, that can be an absolute nightmare because if you've had it until then CEO operating as product manager, or let's say there's an engineering person, a tech leader, an architect or someone who's functioning as someone quite experienced who's been steering the vision of the product and where it's going and all of a sudden you've got to be dropped in as the first product manager.

You've got to have something about you to be able to do that job. You've got to have something in your head where you can say no to people, where you can challenge, where you can give a shape of what good looks like. The thing with this job that I saw the other day was that it was really junior. I think the salary was something like £40,000. Roughly around $50,000 probably. For the person that they're looking for as their first product manager, they're trying to hire someone on a really junior salary. Now that junior person could come in and absolutely storm it. I can really picture some of the people that I've worked with in the past, some of the people I've coached, who weren't super experienced but they had energy about them and they were really determined to do amazing stuff. Actually, I could see someone like that landing and just being amazing but if they're looking for someone on a junior salary and if they're thinking about what that role should inhabit, then I would imagine that they're probably not looking to be challenged.

They probably just want someone who can do more of the admin. I think the comparison here with delivery management is if what you want is really someone who's doing delivery management, if what you want is someone who is going to enable and coach, if you want someone who is going to challenge and remove impediments and actually cool stuff out, let's say whether it's something like the path to production, if we've got 16 handoffs before something's reaching prod, that needs to change.

If it's not automated at least, that probably needs to change. Even if it is automated, maybe we can improve it. I would say if you're not in that space where really you're going to be comfortable with that, then you're going to find it tough. Bringing in that first person for me, is almost always a question of saying, where are you now? Is this a culture where actually you've had people applying delivery management but now you really want someone who's got that job title and you've got that standout person who's really going to fly the flag for it? In which case, maybe you can get away with bringing in someone who ideally has got solid delivery management experience. Maybe they've worked as a Scrum master, maybe they've got some Agile coaching experience and this is a slightly different job title for them. They could be a good fit, they could do a really good job, but a lot of the time if you really want this to work, thinking about something like starting a community of practice and thinking about, if you were going to kick off a community of practice who really understands the discipline, who would you want as the first person on the ground? Who would you want as a figurehead for that? In my head, I would probably lean into someone with experience, someone with knowledge, someone with a sense of good practice. I often avoid talking about best practice cause I think it's very context-specific but certainly someone who has a feeling for good. I think if you're looking for good, you probably want to have a job description if this is what you're putting out into the world where it says someone who's experienced and someone who doesn't have to be senior. I don't think we have to look at hierarchy in this, but probably someone who really has a feel for high performing teams.

This boils down in some senses to really getting that support. Even if you don't end up hiring a person who's almost like a delivery management coach almost or someone who's a experienced head of delivery or head of delivery management or has been like a lead or principal delivery manager, at least maybe see if you can get some of their time to help with the questions you should ask or put them on the panel for interviewing because I know the big thing that I've seen, and we talked a little bit about some of the anti-patterns that I would try and avoid, if you can have someone on a panel for that first delivery management expert who's joining your organization, they're probably going to be listening out for, these are times when I supported a team or enabled a team or these were times where I worked hard to remove an impediment but also taught the team how to remove it themselves in the future.

Having that support when you interview for people I think is probably one of the best ways that you can get the right fit for your organization however you find that support because the danger is that you get someone who goes, I did this, I did that. They're very much a rockstar and actually what they've done is just boss people around and not left a legacy of people who feel enabled and who feel empowered. They've not built that space of true leadership. What you're really looking for is true leaders who serve and as opposed to getting someone who sounds hot but actually isn't really going to do what you need.

Jonathan: If you enjoy this content but you don't want to wait a week for the next episode, subscribe to my daily mailing list at jhall.io/daily. Well, why don't you tell people how they can find the book where they can buy it?

Jonny: The best place to go is delivervalue.uk and we've got the full set of retailers up there. There's also a couple of blog posts and if anyone's interested in writing a blog post for the website, then do reach out. I'm on LinkedIn quite a lot, which is how I was very fortunate to meet Jonathan. Feel free to engage me there. I'm Jonny Williams and you'll see some stuff about delivery management and the fact that I work at Red Hat. Broadly speaking, delivervalue.uk is the home of the book and is the home as well of some of the t-shirts that I've made just because I had a bit of free time during editing as well. That's where I'd advise people to go. It's available for sale on Amazon, but there's links as well through to the different regional sites and also a few different suppliers.

Jonathan: I got my copy on Kindle. I know it's obviously also available on paperback, I think hardback. Is there an audio version coming out at some point?

Jonny: I think that's one of my jobs over the winter break is to start working on recording an audiobook.

Jonathan: All right. If you're listening to this in the future, it's available in all those different formats. Is there any reason somebody should prefer one format over the other? Are there diagrams or pictures that would make the audiobook harder to read or is it scratch and sniff so you actually want the hard copy so you can do that?

Jonny: This does make me feel like I should have put 3D glasses in and gone really like 1980s of like blue and red 3D diagrams. There are diagrams in the book, so I've done a series of illustrations and for those among you who use Excalidraw or you might have a hint about what tool I use to create those illustrations. I think having a physical copy is nice for those because it's laid out in a way that makes it quite digestible but they're visible on Kindle. I think in terms of audiobook as well, I'm going to make sure that people have either got reference material that they can go to to see all the illustrations or at the least, describe them in the most vivid way. I'm probably not going to deliver them through interpretive dance, but certainly, there'll be some way to ensure that people can see them. Maybe I'll reconsider it. I think an interpretive dance of kinds of [crosstalk] uncertainty could be quite good. [laughs].

Jonathan: Yes, I think I like that [laughs]

Jonny: Cross-Functional team dance could be quite interesting.

Jonathan: Yes, I love it. Great. Jonny, thank you so much for coming on. I've learned quite a bit. I hope the audience has too. I can vouch for the book. It's an entertaining read. It's well written. There's some good anecdotes in there that make it fun. Thanks again for coming on. I look forward to the audiobook and the interpretive dance in the future.

[laughter]

Jonny: Thanks so much for having me. It's been an absolute pleasure and a real privilege to be on the podcast. As an avid listener, there's been some fantastic guests, so it's really good to be part of the halls of history, shall we say.

Jonathan: All right. Happy to hear it. Thanks and until next time, I'm Jonathan. Cheers.

[music]

[00:57:07] [END OF AUDIO]