In this session, Jonny Williams, author of "Delivery Management: Enabling Teams to Deliver Value", dives into the discipline of Delivery Management and its importance in enabling teams to achieve valuable outcomes. He examines the approaches, practices, and techniques that you can apply to become an effective team enabler. Jonny also shares insights on how to experiment with new ways of working, support high-performing teams, and address common challenges faced by organisations looking to adopt Cloud Native approaches.
Your speaker
Jonny Williams is an Agile Delivery Lead at Red Hat. Prior to this he was Head of Delivery at Homes England. He also provides coaching at DeliverValue.uk
Having enabled teams to deliver value for over ten years, he now supports organisations to uncover effective modern approaches to work.
Jonny is an experienced community leader in the public sector, having coached and enabled teams and individuals to maximise their potential while working for the UK Government as a civil servant, and in the higher education sector.
His experience as a Delivery Manager enabled him to explore the disciplines of Agile Coaching and Scrum Mastery. This led to Jonny being one of less than one thousand people from around the world certified as Professional Scrum Master III in May 2021.
Your host
Jamie Dobson is co-founder and CEO of Container Solutions, a professional services company that specialises in Cloud Native transformation. With clients like Shell, Adidas, and other large enterprises, CS helps organisations navigate not only technology solutions but also adapt their internal culture and set business strategy. A veteran software engineer, he specialises in leadership and organisational strategy, and is a frequent presenter at conferences. He is also the co-writer of the O’Reilly book Cloud Native Transformation: Practical Patterns for Innovation (currently available for FREE).
Full transcript
Skip the gossip and go straight to Jonny’s talk.
Jamie Dobson: The participants are flooding in, and somebody's joined us from a boardroom. I don't know who those people are, but welcome.
Participants: It might be us. Yeah. Sorry, we joined as whole team here.
Jamie Dobson: Oh, that's okay. Welcome. Are you new to these webinars?
Participants: Yes. We got a recommendation today, so that's why we're just trying this out.
Jamie Dobson: Yeah, good, who recommended you, you might want to speak to them later? Welcome. We've never had this before, and we've been doing this for a very long time. I didn't mean to put you on the spot in your first webinar, but I was thinking, "Hey, is that a boardroom down there?" So welcome.
Okay, so to everybody, and at least there's one team that is new to WTF, my name's Jamie Dobson. I am the Founder and the Chief Executive of Container Solutions. I don't have a very good job, it's very stressful, very difficult.
However, one of the favourite things I get to do is present at this webinar and at different conferences, and I get to speak about the things that I'm really passionate about. I am joined today by my colleagues from Container Solutions, another Jamie. He's not the main Jamie, he's the secondary Jamie at Container Solutions because I'm the first one. Joined by Jamie, by Carla, by Julian. And our special guest today is Johnny Williams. Hi, Johnny. You want to say hello?
Jonny Williams: Hello, indeed, if I can find the mute button. Good to be here. Looking forward to talking about delivery management.
Jamie Dobson: Brilliant. We can't wait. We've had quite a lot of people subscribe to this, Johnny, which makes me think it's going to be a bit of a knockout, really. Okay, so for those of you who are new, we don't go straight into the main event, but we do some announcements, and we also have a session about industry gossip. I think we first did this a year ago. It was an experiment because we are quite an experimental company. It really worked. So people quite liked listening to the gossip or what we think of our industry gossip. So Julian's going to be helping me with that today.
Before we get cracking with that, a little bit of housekeeping. We do have a code of conduct which we do strictly enforce. One of my colleagues now is going to drop it down to the chatbox. You can take it with you if you are running a conference or an online event and you would like to use the code of conduct or tweak it for your own purposes. I will summarise it briefly. Be good to each other. Don't be rotten. But if you want more details, you read the code of conduct itself.
We are recording this webinar. If you have real objections to this, let us know and we can pixelate you out. Alternatively, you might want to turn your camera off. If for some reason you really don't want to be present on a video recording, which we will later put onto YouTube, I'm afraid we're going to have to ask you politely to leave, but then you can watch the video at a later date. We just wanted to make you aware of that. Now, there's always one thing I forget on housekeeping, Carla, what have I forgotten?
Carla Gaggini: I've also just activated the transcript so people can actually follow the subtitles of the talk.
Jamie Dobson: Yes, okay, this is good. So yes, that's right. Where possible, we turn the transcript on. And at our live events, where possible, we bring professionals in to help us make our conferences and our webinars more accessible. That means I have to speak clearly, because when it's automatic transcription, my Yorkshire accent destroys the software that runs this. So if there are any mistakes in the transcript, it's probably because of the way I speak, so my forgiveness to those people.
Okay, fine. Next up is our announcement. The big announcement is this one. What the F is SRE. Next week we are running this conference in London, it's the fourth and the 5th of May. I'm doing the keynote, I'm looking forward to that. It's going to be a keynote about artificial intelligence, but it's about the lessons we've learned historically and what they might teach us about the mistakes we're currently making with AI. I've never looked into this topic before, so it's been really, really exciting and a bit stressful process for me, but I've enjoyed creating this talk. I think, Johnny, are you speaking too next week?
Jonny Williams: Unfortunately I can't make it, but a few of my colleagues from Red Hat will be there talking about some really interesting stuff to do with platform as a product.
Jamie Dobson: Very cool, I look forward to that. Actually, I don't know if anybody can share the schedule right now in the chat. I honestly think the agenda is one of the best agendas we've ever, ever put together, so I'm really proud about that. I think it's testament to the community that we've built around WTF that so many brilliant speakers want to come.
Couple of things, if you've been recently made redundant, obviously we're very sorry for that. It is not nice out there right now. All kinds of cutbacks, difficult economic conditions, high cost of living for many people, many people who are worse off than the type of people who work in technology. We do have free tickets for anybody who has been recently affected by changes in the economy. Let us know in a direct message or send an email to events@containersolutions.com and we will sort you a ticket out if possible, if we've got enough left, but I think there probably will be.
We also have a last minute two for one offer on tickets for the same reasons. Because basically nobody's spending money right now on conferences. So if you work at a place or if you're freelancer and you want to grab a ticket and bring a friend, then that offers open as well. Anything else about the conference next week, Carla or Jamie?
It's in London. I don't think we've got any weird mask restrictions or anything like that.
Carla Gaggini: We are recommending people to be careful if they are feeling not well, obviously, to either wear a mask or-
Jamie Dobson: That's true. That's a very polite way of saying do not turn up to that fucking conference if you've got COVID, okay? We'll give you your money back. Just don't turn up or give me it.
Carla Gaggini: Okay, fine.
Jamie Dobson: So please be sensible, travel safely, and keep safe. Right now... Oh, I wrote a book that was good. It's not as good as Johnny's book, although it is far superior as a book at sending people to sleep. So if you're struggling from insomnia, what you got to do is open up the Cloud Native Transformations book and read a few of the patterns, oof, you'll be gone like that. However, that being said, it is very popular with people who are moving to the cloud because it's very practical. It's not a book you read cover to cover. It's a reference book full of patterns.
Last week at KubeCon, and I was very grateful for this, a team from ING Bank in the Netherlands gave a great talk about how they moved to the cloud, how they took care of security, et cetera, et cetera. They said something along the lines of, "We use lots of patterns from this book," but they wish that have had the book when they started the process a few years ago. So it really does get used heavily in industry. I'm very proud of that. If you want to grab a free copy because we can't sell it anymore, basically. No, seriously, if you want to get a free copy, go to the website right now and you can download a copy. Alternatively, you can buy a copy from Amazon. I think it's about 30 or 40 quid.
Of course, you can sign up to our newsletter by scanning the QR code or clicking on this link later when you get the deck. The newsletter has always been quite regular. We are actually taking a small pause in the next month or two as we figure out what to do with the newsletter. It's not about Container Solutions, it's pure content. We are wondering, "Should it be more about us? What direction should it take?" And as a newsletter, it's very labour-intensive, as are all the events that we do. We just want to take stock of where we are, what people like, what people want from us moving forward. And then as we get closer to the summer, fingers crossed, we pull the trigger and WTF starts to go back into print again. Anything else on the newsletter, Carla?
We know it's popular, we know people love it, so it's not going away. But we as a company just need to figure out what we're doing next with it. Basically, it's way more successful than we imagined, so now we have to figure out what the evolution of WTF looks like. On that happy note, I'm going to bring in... Oh no, the slides didn't update. Wait a minute, I'm just going to come out full screen because some vandal destroyed my slides by using weird fonts. I quickly put the gossip slides back together and now I'm very, very happy to invite my favourite Swiss colleague, Julian... He's the only Swiss person in the company, so he's both my favourite and least favourite Swiss colleague... to come in and tell us what's happening. Julian?
The gossip
Julien Sudan: Great. Thanks a lot, Jamie. Today, I will talk about Elastic first, about Elastic, which contributes now ECS to OTel. What I mean by this, I don't know if you've ever heard of ECS. It's elastic common schema, and it's actually something that Elastic has been open-sourcing to simplify the way you can use different measures that you would have from your infrastructure. If you've ever tried to do deep observability or security, you know that that's always an issue, to parse logs, to know what goes where, which values goes where. To try to centralise all this and make sense of all this, it's quite hard. So Elastic, the company provided the ECS as a way to do that. It was well-received, but there was a problem, there was OpenTelemetry on the other side, which was very successful. It's very nice that now Elastic is going with OpenTelemetry to actually have something that is unified and avoid to have two separate things competing with each other. So this is very nice for observability and security in the tech world.
As a second gossip, ChatGPT unreliable output. I don't know if you've heard of ChatGPT, I guess so if you've not been under a rock for the past three weeks. Something that we're beginning to see is that while we all begin to trust it more and more, we still need to be very careful because it can also give unreliable output. Not so long ago there was a person, for example, a law professor, received a text message from someone asking if he actually had ever sexually harassed someone. It turned out it was a complete hallucination from ChatGPT when asked a question about this topic. So we can imagine that it can have dramatic consequences.
Jamie Dobson: I mean, I've never heard of that, a computer program given unreliable output. Well, I never.
Julien Sudan: Who would've thought of it?
Jamie Dobson: By the way, don't trust artificial intelligence. Are you all mad? Seriously, don't trust computers, they're going to kill us all. At KubeCon last week there was one of those dogs from that robot company. What's name of that company? Is it Boston Dynamics?
Julien Sudan: It's Boston Dynamics, yeah.
Jamie Dobson: And the dogs jumping around like a real dog and everybody's going, "Oh, look at this dog. Look at this dog." Seriously, they're going to put a gun on it and it's going to chase people around cities.
Julien Sudan: They already put a gun on it-
Jamie Dobson: Oh, there you go. There you go.
Julien Sudan: ... the companies who did that.
Jamie Dobson: So you cannot trust artificial intelligences. Please don't be foolish. But that's shocking. I feel sorry for the law professor. That sucks. That's a hell of an accusation.
Julien Sudan: Yeah, yeah, exactly. So this was about that. You will find a link about a video from also LiveOverflow because this can happen in a way that was not made by anyone. But LiveOverflow, who's a very famous cybersecurity specialist, showed that you can actually prompt, bamboozle it to manage to manipulate the output. That's also something about trust in outputs of AI. And then a similar topic, but there's a new TED Talk from the OpenAI co-founder, Greg Brockman. It's fantastic, go watch it. He's talking about ChatGPT, where it came from and especially where it's going. He's showing all the plugin stuff that's going to come out very soon, which will allow to integrate different things together, so for example, create tweets automatically depending on some stuff, or browse the internet to have references also and everything with a lot of sourcing in the output. This is really nice and it's a very exciting talk. There's a very nice interview afterwards that is also worth checking.
Jamie Dobson: I was reading a book called The Chip, and I wanted to know where a specific page number was, so I asked ChatGPT because I thought, "I wonder if it knows where this passage is in this book because I can't remember." And it took me ages. I kept asking it questions and it kept giving me reasonable answers. But then all of a sudden I was thinking, "I don't think it knows what it's talking about." So I said to it, "Have you actually read this book?" And it said "no". I was like, "Maybe you should have said that at the beginning of this conversation." That being said, that being said, I follow Kent Beck on Twitter. He was a extreme programmer. I was once upon a time an extreme programmer, and he said 90% of his skills have just been made redundant. But the other 10%, the judgement part of his mind where he could assess what good code and bad code look like all of a sudden is much more valuable.
Now, I haven't programmed Java for a very long time, but yesterday I couldn't help it, I was up early and I told ChatGPT, "These are the design principles that I want you to use." And I asked it to calculate or working with it, I built a interactive league table for football and rugby scores. I did it in about 20 minutes. And then it used getter, and I said, "What are you using getters for? I just told you in the beginning, 'Don't expose data.'?" And it said, "Oh sorry, my bad. Yeah, you're right, that's not a good design principle." And I was thinking, "How stupid are you?"
But then I realised, "How bad am I, how impatient am I as a teacher?" But then I remembered they're not real people, they're computer programs. That thing last week at KubeCon was not a real dog. Anyway, so it is phenomenal. It is really phenomenal. I was very dismissive for the last few weeks until I started writing my talk for next week. Actually, it's very interesting because the telegraph and the telephone and the computer all had human supervisors until the day they didn't. And right now AI has got human supervisors. Pretty soon we are going to be in the way.
So it's all very exciting stuff. I'm going to watch that Ted Talk, Julian, and I think that gossip has been fantastic today. So thank you.
Julien Sudan: Thank you.
Jamie Dobson: On that note, I will now turn it down, the volume on my chatter. I will not interrupt Johnny like I interrupted Julian, but I will hand over now to the main event. I'd like everybody to join me in giving a warm welcome to Johnny Williams who's written an awesome book about delivery management. I never told him this actually, but we're using a lot of the principles. I basically convinced him to give this talk so that we could get a bit of free teaching. We use this book internally, it's awesome. Johnny, welcome.
WTF is delivery management?
Jonny Williams: Amazing. Thank you so much. And very interesting gossip as well. Very good to hear. I'm going to just hop across and start sharing my screen if it wants to cooperate. Give me a shout if you can or can't see the screen. All good. Amazing.
So we're here today to talk about the very interesting topic of what is delivery management. I think the obvious answer is obviously it's a book. I think we can probably wrap up there. If you've got any questions, let me know, and I'll see you next time. But no, in all seriousness, what is delivery management other than a book? There's a load of different perspectives that exist out there around delivery management. As a title around a discipline, it is something that people have very mixed feelings about. But I'm hopefully here today to convince you a little bit that delivery management could be a good fit for your organisation and actually will be valuable even if you don't love the words that are involved in naming the discipline.
Delivery management is more than a book, and the book itself has plenty of different ideas in it as well that point to what the fuck is delivery management. My definition of delivery management started with gov.uk. So I was a bit of a fanboy with gov.uk when all of the stuff around the government digital service in the UK was emerging and all of the services that the UK government owned and operated were being acknowledged as being a bit rubbish and there was this massive shift to try and say things could be better. Part of this shift involved looking at the disciplines and the different responsibilities that lived within teams. And one of those things was the role of a delivery manager.
Now, when I talk about delivery management, it's much more aligned with the idea of a set of responsibilities or accountabilities within a discipline, it isn't purely a role. But I think this idea of what is a delivery manager really started with gov.uk, for me personally at least. It's something that had existed out in the wild, but it was where I first learned about it. And so, gov.uk talks about a number of different facets when it comes to delivery management and the disciplines and factors that are involved. So whether it's agile and lean practices or financial management or making a process work and certainly team dynamics and collaboration, there's a number of things that this gov.uk definition calls attention to. But for me that didn't really cut through to the heart of what delivery management really involves.
For reference, I was working for a couple of years at the Department of Work and Pensions as a delivery manager. I was working in the platform space actually looking at cloud adoption and thinking about Kubernetes and working with teams that were looking at platforms whilst also as a sideline and due to a little thing called COVID-19, working to support other government services. I was very fortunate to work on quite an impactful service during the course of the pandemic called "Tell Us Once". That service enables people to effectively report a death in their family one time and it spreads the message out to local authorities, to different parts of government, and saves people in the worst part of their life having to basically go through the rigmarole of loads of government bureaucracy. So I was supporting the platforms and the cloud aspect of that service.
Thinking about this definition on gov.uk doesn't really cut through to many of the positives that I experienced working in that delivery management space. So I looked a little bit further when I was thinking about what is delivery management. I got super curious, was trying to find all sorts of definitions, and realistically there is not much out there. There's a good few things about the government context, but there aren't that many people that have really talked about delivery management all that much.
One of the key people that I turned my attention to was Emily Webber. Emily was the Head of Agile Delivery at GDS, Government Digital Service, so as you can imagine, really core to that key definition that exists online that gov.uk have produced. Emily talks about delivery management from a really positive angle, which you can probably see the connection through to my book for anyone who's read it, this idea of enabling a team to deliver value, but also thinking about the environment, self-organization, and culture, especially that culture of learning and transparency. So all of those things really stood out to me when I was thinking about Emily's definition from her pretty seminal blog post that she wrote a good few years ago now. This is something of a reference point that many of us working in government have referred back to.
But you might also know that I currently work for a company called Red Hat. At Red Hat, I work with customers to help them adopt technology, change their ways of working, and think about the approach they're using to actually use this really awesome tech. But I'm very much minded towards the idea that we think about people, process, and then technology. Doing things in that order for a key reason. There's some really good stuff that Emily's highlighted in her blog post here, but I was thinking, "Well, there's a little bit more to this as well. There's something that must relate as well to what that value looks like or thinking about actually how this relates to product teams."
So the next person I turned to was Marty Cagan. You might have come across Marty Cagan if you are interested in product management or product delivery. Marty is part of Silicon Valley Product Group. He's got experience of working with massive companies like eBay. But his book "Inspried", was really actually inspirational, no pun intended, for when I was thinking about delivery management as well, because I was tying a lot of my experience and ideas about delivery management not just to the public sector definition, but also to what this might mean in a product context.
Marty talks about this idea that a delivery manager is there to help get things done. There's some alignment here that you can probably see in terms of project management or program management, but we'll get onto that a little bit further in a minute or two. But for me personally, this idea that delivery manager's there to help get things done was really important.
Marty talks a lot about this idea of helping teams to remove impediments, and I think that was a really key theme that I really latched onto and thought, "Well, you know what? Actually, in terms of helping teams deliver value, there's something there, getting the blockers out the way, making sure that we can actually be effective, get stuff done basically."
Boiling it all down and looking past this high level gov definition for me, it all really ties into team enablement. The other stuff is more of the details that, yes, you might have to encounter, but a lot of those things like financial management or making a process work really tie into that idea of removing impediments or actually enabling the team to be effective and building out that culture where the team can have the impact that they want to have. In my mind, team enablement is probably the best way of boiling all of this stuff down and making it simple, especially when we're trying to answer that question, what is delivery management?
In the book I talk about these three aspects of enablement, and this is kind of the expansion on team enablement. When I'm thinking about what it means to be an enabler, for me that involves being an impediment remover, being a facilitator, being a coach. Now, this can take different forms. There is no singular definition of what it means to be that impediment remover, be that facilitator, be that coach. But these three aspects of enablement I think are the core of delivery management. So you can really think about delivery management through these three different lenses all focused in by being an enabler.
Now, what do we mean when we talk about these three different aspects of enablement? Well, removing impediments for me is just making sure that teams can actually crack on. Much like what Marty talks about in his book, is ensuring that actually they're not going to be blocked, they can focus on delivering value, they can be effective most importantly. And effectiveness is a really key word in terms of the approach that we're looking at here. We're not thinking about efficiency, we're thinking about effectiveness, and those impediments can limit effectiveness and limit value delivery.
In terms of facilitation, when I think about facilitation, it isn't just about post-it notes and putting stuff up on whiteboards, which I love doing, but it is more about making decisions and defining a course of action where people can actually align around the steps they want to take and agree on what they're going to do to make value a reality. So spending time with groups of people, getting people to the point where they actually know what they're going to do next, and ensuring that they can really focus on what's going to be valuable.
And then the final ingredient, coaching. For me, this is all about supporting other people to maximise their potential. That definition aligns a little bit with the idea of life coaching or professional coaching, but when we think about coaching in the delivery management context, we're not really trying to do that. We're not trying to help people with their personal life problems. It's all about that context of the team and thinking about how to help them be more effective from that enablement standpoint. But we still want to help them maximise their potential, and we still want to help them find ways to basically fulfil that potential by self-organising. So if everyone is being fully directed or being told exactly what to do, they're probably not going to fulfil the potential that they have.
Of course, there's significant overlap between all of these different ideas as well. So you might remove impediments by coaching people, or you might coach people in the context of facilitation, that when you're running a workshop you help to expose new ideas that they might want to learn more about or help them to uncover their own potential of how they can solve a problem without your intervention, effectively. So for me, there is definite overlap, which is why that diagram of the three different aspects does cut across. It isn't something where they're completely siloed disciplines, it's a bit more like this visual here.
I think equally it's worth acknowledging that when it comes to removing impediments, facilitation, and coaching, all of them can help build each other in the right direction as well. When we talk about removing impediments, if you are always the person in a team that is removing impediments for others, you're probably not being very effective as a coach. Arguably, the main impediment to remove in a team is a team's lack of ability to remove impediments. Once you get them over that hurdle, you can probably zone in a little bit more on helping them to maximize their potential in other areas. That for me is what delivery management looks like at a high level, but it goes a little bit further. This is one of the reasons I want to tap into this idea of delivery management being essentially project management.
I personally think there's a fair bit of difference, and I think it would be very simple to say, "We take these three aspects of enablement and bolt it onto project management, but in my experience, it does not look like that. There is significant difference in my experience between project management and delivery management. Although there's going to be some overlap in terms of the tools or maybe aspects of the things that they do day to day, I think there is significant enough difference that we should call attention to it. And arguably, bit of a tip, if you are looking to talk to someone who's worked in that delivery management space, you probably don't want to just call them a project manager because sometimes it doesn't land all that well.
In all seriousness though, it's not something which should be a real issue because the real thing is about the discipline as opposed to the job title. Project management as a discipline still has value, it's just that it might not be the predominant approach that we take if we also want to apply delivery management.
Realistically, project management kind of answers this question instead, what isn't delivery management? It's not really project management, it's something distinct, it's something different.
I refer back quite frequently to Allan Kelly. I actually had a brief chat with Allan Kelly on LinkedIn where he said thank you for boosting sales of his book because he'd seen Project Myopia get a bit of a boost recently. That's partly, I hope, because I keep talking about it. So if I have helped out Allan Kelly's book sales, then I'll be very happy. It's a book I refer to frequently where Allan talks about why agile models and project models don't sit together all that well.
Now, delivery management isn't explicitly an agile discipline, although it does focus in on those ideas around incremental and iterative work. And we're thinking about self-organising teams, so there's going to be something in there that aligns very closely with agile and lean approaches. However, Allan Kelly's talking about projects and thinking about why projects don't quite fit with these ways of working is really important to help understand where these distinctions live. So thinking about that question, what isn't delivery management, well, projects constrain the work in order to control it, and I think that is something that delivery management does not do. We're not looking to constrain people. We're not looking to control people. The reason for this is because of the fact that work and people are complex. So if we're working in this emergent fashion where we're trying to uncover new ideas and drive innovation, we don't want to constrain the ideas that people might have. We don't want to limit them. That's one of the key reasons why we try and work in a way which is open to flexible and adaptable approaches as opposed to creating that big Gantt chart or roadmap of doom with fixed milestones that actually mean we have to deliver something even if it's not going to end up being valuable. Value is the key focus, and that's one of the most important reasons why we're not going to try and constrain and control the work.
Really, when we think about the toolbox that we might use within the delivery management space, we're thinking about aspects of project management that could be valuable, but we're not trying to be project managers. So we might think about risk and create something like a RAID log, but we're not going to tell the team how to work. We're not going to give them deadlines that they have to operate to, and we're not going to limit something or disguise a blocker or a problem just because it doesn't fit within the paradigm of project management that people might think about. Instead, we're going to work in an open way that is going to be better aligned with those three aspects of enablement, facilitation, coaching, and removing impediments.
For me personally, command and control delivery management is worthless. It does not fit the intent behind delivery management. If we're working in this command and control way where we're being dictatorial or we're trying to define timelines for people, it just doesn't make sense. How can we facilitate? How can we coach? How can we truly remove impediments if we are controlling and constraining the work? If anything as well, it's worth considering the fact that actually this kind of command and control delivery management is worth less as well. If we've hired people to be enablers, then why would we try and push them to deliver in a way that's aligned with command and control?
You're not getting value for money if you're using people in this way. You're also not going to get value for money out of teams. If you're trying to constrain ideas, if you're trying to limit innovation, then what's the point in having a really smart bunch of people in the room? So delivery management should actually open up the conversation, enable experimentation, and support that self-organisation that really helps value to emerge. For me, this all filters into the idea of enabling teams rather than controlling teams. It's a very simple principle. When we think about delivery management, it's all about enablement. It's not about management in that traditional sense. When we talk about delivery management, the managing part is more about the context that we manage or the circumstances that we manage or the impediments that we try and manage. It isn't about being a traditional manager. It's not about being that people manager, let's say.
A similar discipline might be product management. When we talk about product management, it's relating to the product, we're not thinking about managing the people. When we're talking about teams, this is a really key question that I get asked quite frequently, so what types of teams are we really thinking about here because there's plenty of different teams out there? Are we talking about a finance team, HR team, football team, rugby team, a team that might be on Jamie's chart that he's designed with ChatGPT? Who knows?
Well, for me, I like to come back to the Werner Vogels thinking about build it, run it teams. This is something that really feeds into this idea of cloud native development or thinking about DevOps and really these effective teams that own what they're working on. I like this idea because Werner actually calls out the fact that the teams became more effective and the quality of the products improved. As soon as they were responsible for running what they built, they actually increased the effectiveness of what they were doing. This is something that I call out because I think realistically when we're talking about teams, we want them to be building and running and solving their own problems, being these long-lived, cross-functional, properly-sized, highly-aligned, empowered teams.
When I say enabling teams, all that stuff in the middle, they're filling up the sandwich, it goes without saying, but a lot of the time in organisations we have to make this explicit. We want long-lived teams so that they can own the things that they build, so that they can fix the problems when something arises rather than trying to chuck it over the wall to someone else. We want them to be cross-functional so you've not got these functional silos of a dev team working on something, handing it off to a build team, handing it off to someone who's deploying it, and then handing over to a test function or however the organisation's working. We want all of that good stuff in one team so they can collaborate and actually ensure the solution is going to be valuable.
Properly sized, because if anyone has ever worked in a team of 50 people, you realise it's very hard to get stuff done effectively because you're reliant on other people, dependencies are higher, you can't communicate effectively. So sizing a team properly. And then alignment and empowerment are really key things. I'm a firm believer that you can't empower others, but you can make them feel empowered. I think that alignment is really key as well so they've got a vision they can work towards. I think this is the kind of team that we're talking about, where they've got ownership around a vision, where they've got direction that they're working towards, where they know what they're aiming to do and the outcomes they're trying to achieve. All of this aligns around value, and that's the key thing. What's the point in having a team if they're not doing something valuable?
We've answered another question but maybe not answered what is delivery management. That whole definition there really nails to me what a product team is. When we think about product teams, it's a really key idea, even if we're thinking about platforms as well, I like to advocate this idea of platform as a product and therefore your platform team should be a product team as well. But you should know based on that short definition what a product team is, but maybe you're still a little bit loose on what a delivery management definition should be.
Value is a word that I keep coming back to. And if we're trying to answer the question, what is delivery management, then value is probably the key concept that we have to focus in on.
I really like this idea from the book Sooner Safer Happier. Sooner Safer Happier is a fantastic read. It's something I reference quite a lot in my own book. But this model that Jonathan Smart's put together of having a value outcome lead, a team outcome lead, and an architecture outcome lead all supporting the team as enablers aligns really nicely with the idea of delivery management, and it's something I come back to. So if we're focused on value, then we want to have these enablers that support the team to function in that way, where they are highly aligned, where they've got high psychological safety, and where they've got that vision that they're working towards. Your value outcome lead might be someone like a product manager, architecture outcome lead might be someone like a tech lead or an architect, and your team outcome lead for me could be someone like an agile coach, could be someone like a scrum master, but really, it could be that person who's a delivery manager, someone applying delivery management who can work in that capacity to help the team get to the point where their system of work enables value delivery.
Team outcome enablement is probably the other way that we should describe delivery management. We're helping the teams get to the point of valuable outcomes. Now, I would also really like this model out of Sooner Safer Happier where we think about how these different teams can collaborate and how that stacks up as well. Because value isn't something that happens in isolation in our organisations, it is something that requires us to have an understanding of value streams or at the very least these end-to-end customer journeys. All of this stuff is likely to live on top of platforms or to use other tooling that exists elsewhere. But it should be the sum total of the vision and values that we're trying to build together to deliver something that's actually useful. And for me, this idea of having these different enablers really functions across organisations.
The team is the hub, the team is the vehicle of value delivery. But then when you scale it up and think about teams collaborating together as part of value streams or within different domains, it's all of that cumulative effort that really leads to valuable outcomes. So this model from Sooner Safer Happier is a really good way of thinking about delivery via value streams or thinking about those long-lived products with long-lived teams that are collaborating to make sure that good stuff is happening in the organisation.
Valuable outcomes are the entire purpose behind delivery management, and arguably should be the entire purpose behind the teams that you are in or the teams that you're trying to stand up. If they're not achieving valuable outcomes, there's no point. And that aligns with the idea that command and control delivery management isn't effective because it can constrain value. It aligns with the idea that trucking stuff over the fence between delivery or development and operations just doesn't make sense because, again, you're constraining long-lived value. Realistically, if you're not focused on value, you're probably not applying delivery management in the right way.
So throwing around a lot of words, and I still feel like maybe you might be a bit confused about what exactly is delivery management. We've got products and teams and delivery and enablement and outcomes and value, but what is delivery management? If we boil it all down, it comes back to these three aspects of enablement once again. If we think about all of these concepts of helping teams, that's directly aligned with coaching. If we think about value, we really want to ensure that we facilitate the conversations that help people focus on how they're going to get there. And if we think about all of those aspects boiled together, we need to make sure that teams aren't going to be blocked on the pathway to delivery. It's all about the toolbox that you actually pull in to make those aspects of enablement a reality and ensure that those product teams function effectively within the value streams and that you're applying the right practices to ensure that actually you're helping people get to the point of value delivery.
For me, one of the things in my toolbox that I go back to really frequently is this place called the Open Practice Library. The Open Practice Library is a really good resource to use. It contains lots of different tools that you can apply focused on discovery options, delivery, and foundation. And this is a really key point when I talk about the Open Practice Library because this has got delivery on it identified as part of a process. So when we think about delivery management, are we thinking about this part of the Mobius Loop? Are we thinking about a phase that comes after discovery? Well, I would argue no, it's really important that we tack on the word value in front of delivery management, because when we think about delivery management, it's all about value delivery, it's not about delivery as a phase or an aspect of what we're doing. It's the whole thing. It's more holistic.
But the Open Practice Library is one of those foundational things that I have in my toolbox because it's got all of these different resources for things that I can bring to teams, bring to customers, bring to the leaders that I work with. For me personally, I'm very fortunate to work with a lot of very interesting people, including chief technology officers or chief product officers. And actually having these tools in the toolbox enables me to be more effective when I try and apply the discipline of delivery management, especially when it comes to facilitation. So three examples from the Open Practice Library I just wanted to call out: Start At The End, which is one of the most effective goal-setting tools that I've ever used; Retrospectives, which I think provide the beating heart of any effective team and enable them to continuously improve; and also using that Double Diamond from design thinking. Having that tool that enables you to take ideas apart, then bring them back together, and then plan out that next course of action.
So having tools like this in your toolbox is one of the most important aspects of being effective when you're trying to use delivery management. Delivery management isn't just sitting back and observing, it's also bringing these things to the team and making sure that they can be more effective. There's also a whole host of resources, plug my own book on this list, but these are some of the books that I would say influence the discipline of delivery management most closely. So thinking about books like Marty Cagan's Inspired that help you understand what good product working looks like, thinking about agile coaching, but also books like Turn the Ship Around! that really help us understand what good, true leadership that functions as a servant leader could look like, creating that culture of leaders where everyone can be a leader, everyone can step up.
All of these books are reference points that I've used to try and inform my perspective on delivery management and especially think about the ways of working that are really going to help a team to deliver value and be most effective. We're kind of looking at that big cocktail of lots of different ideas that inform the approaches that you want to bring to a team, not only that toolbox of different practices, but also the concepts and ideas that could help a team to ensure they're being effective and staying focused on value delivery.
I was very fortunate in the process of writing and publishing my book to get a quote from Jim Whitehurst, who is the former CEO of Red Hat and also former president of IBM. Jim summarized what I was trying to talk about in my book better than I had done throughout the entire process of writing. He really focused in on the fact that great leadership isn't about command and control, it's about creating the context for people to do their best work. For me, this is what delivery management is all about. So although I covered this topic a bit in my book... I say a bit, it was the core focus of the entire book... realistically, this is what delivery management as a discipline is focused in on. It's about creating a context for people to do their best work. And people that apply delivery management effectively are being those leaders that ensure that people can make those ideas a reality. They're being leaders who ensure that other people can do great things, and that that magic of being in a really high performing team becomes a reality.
I know that's something that I experienced working in DWP, working at Homes England, working in higher education, and now working in Red Hat. It's all about that magic of people collaborating to make amazing things happen and get stuff done. I don't know for any of you, but certainly for myself, finding any way that I could to help people get to that point was one of the most important things, and that is what delivery management is all about.
So moving on to another question that is tied into what is delivery management, well, who is a delivery manager? I did rack my brain a bit about this whilst I was pulling together this presentation. There's not really an answer. There's not a clear simple answer. Maybe we could say, "Don't ask me," but I think again, it comes back to these three aspects of enablement. Anyone who's being that impediment remover, being a facilitator, being a coach, well, you could call yourself a delivery manager if you really want to. I'm not sure it really matters that much. You don't need to be a delivery manager to apply delivery management. If your job title is agile coach, if your job title is engineering manager, if your job title is project manager, you could still apply delivery management. I would hope that it would make sure that you could be more effective, that you could do your job in a better way, and that you could enable the people around you to do what they're trying to do and deliver value. You don't need to be a delivery manager to apply delivery management.
For me personally, disciplines are 10 times more important than roles. Roles that we carry around are just those name badges or the things that we whack up on LinkedIn. They're useful for orienting in an organisation, but they are nowhere near as important as the disciplines that we apply. With disciplines comes mindset, comes approach, comes ways of working. So the disciplines that we use are much more important than the roles that we carry around with us.
If you are trying to start using delivery management, and if you're trying to think about who that person might be in the organisation who is going to be able to apply the discipline, you might actually start thinking, "Well, should we be looking for a team outcome lead?" If the job title doesn't matter that much, if the role doesn't matter that much, maybe what we want is a team outcome lead, someone who's going to enable valuable outcomes. Well, if you reach out and say, "We're looking for a team outcome lead," you'll probably hear crickets. And equally, if you position it as looking for a value delivery enabler, again, people might not quite catch on. You'll probably hear crickets.
For me, the job title of delivery manager isn't the worst thing. It's not perfect, doesn't always do the job, and people don't always love it, but if you are trying to start applying this discipline, then it might not be the worst thing to seek a delivery manager so long as you're explicit about that person being there to enable valuable outcomes and really following along with this idea of the three aspects of enablement. Because the worst thing that you could do is be looking for someone who's going to enable valuable outcomes, put out a job advert looking for a delivery manager, and you end up with someone who's actually going to take that more traditional command and control approach. So it's more about describing the discipline, the way that you want it to be applied, and then probably using the job title as a bit of a hook as opposed to leading with the job title and presuming that everyone will know that what you want is that team enabler.
For me, if you describe it in the right way, if you're looking at the focus on the disciplines, and if you're talking about valuable outcome enablement as opposed to being purely focused on delivery, especially around timelines or efficiency or anything that's going to block potentially the focus on value delivery, you're going to be successful. And that is the key thing that you need if you want to start using delivery management in the organisation, is finding the right person who can apply the discipline fully as opposed to finding the person with the right job title. Job title is just there to help you. It's not going to be the thing that solves all your problems.
The key thing here is that you should understand before you enable, both in terms of trying to apply delivery management in the organisation, but also for you as potentially an individual. So if you want to start using delivery management, then I think it's really important that you understand context, that you understand what it is you're trying to do and why. Context matters more than almost anything else when it comes to delivery management.
I've seen delivery management and these three aspects of enablement being applied in lots of different environments. I've worked with software teams where delivery management really helped out. I've worked with content teams where delivery management helped out. I've even seen behavioural science teams, maybe not ones with all this lab equipment, but I've certainly seen behavioural science teams working with delivery managers to make amazing stuff happen. The truth is that you can apply these three aspects of enablement in almost any context. It's all about the way that you apply them though and ensuring that you understand what things might work and what things won't work.
There's no point rocking up to a content team and trying to talk about all of the different test-driven development tools that you might recommend, but you might be able to recommend some approaches around kanban or thinking about how visualising the work and applying systems thinking could help them to remove impediments. Equally, if you're thinking about that behavioural science team, then you might not want to harp on too much about some of the coaching approaches aligned too closely with agile if actually what they're doing is really deep research. But it's not to say that you can't coach them in other ways of working that might help them out and actually get you to the point of being that trusted advisor where you are able to enable them.
When we think about scaling this approach out, so I'm talking about different teams here that could be using delivery management and benefiting from that tree and verity model that is talked about in Sooner Safer Happier, where you have three types of enablement that might help out a team, the real key thing is to experiment before you scale.
Now, scaling is a bit of a dirty word in our world, but when you think about the word of scaling, it's really focused on ensuring that you can do the same thing and repeat it and get to the point where something is useful across an organisation. This is very true when we think about cloud adoption and where we think about teams that are trying to move to different ways of working that are aligned with contemporary technologies. Really, it's important that you find out what works for you, what works in the right context, and understand that context so fully that you can try new things and experiment without worrying that you're over-committing or getting too deep into something.
I like this idea of deploying delivery management or applying these three aspects of enablement with one team first and then building out from there. To build on this model in Sooner Safer Happier with the value streams and thinking about how value stacks up and can accumulate something really powerful that actually is the results of an entire organisation. If you want to start using delivery management, find that one team with the enthusiasts who actually think they could benefit from enablement, who are getting blocked, who can see that they've got impediments and they need some facilitation, they need some coaching. That's the place to try it with. That's the place to figure out whether this discipline could actually be valuable for them.
Once you've tried it there, then the most important thing is to just keep experimenting. Don't have to over-commit, and it can look different with these different teams, but across value streams, you can have someone who's actually working in that kind of lead delivery management capacity where they think about enablement for the entire value stream. Or you can boil it down to specific products and have people acting as enablers for the product itself. But even if it's just one team that has got someone using delivery management or applying the ideas that I've talked about in my book, hopefully that one team will benefit and it might just start a fire that then spreads across an entire organisation to ensure that everyone can be more effective and that everyone can deliver value more effectively.
For me, in summary, that's delivery management. It's all about applying those three aspects of enablement, making sure that people are focused around value, creating this alignment around a vision and ideas to ensure that people can be as effective as possible and that people can achieve valuable outcomes. I do always like to end as well on a bit of a thank you to anyone who has already bought the book. I just want to say a massive thanks for all of the support that you've shown because it's enabled me to have this awesome platform to share new ideas with lots of different people. The thing that I never expected as well when talking or thinking about delivery management was that it would actually gain so much attention. So not only have you given me a really amazing platform to talk about awesome ideas and hopefully enabled teams to deliver value, but it has also enabled me to get a silly amount of Amazon accolades, which has just been ridiculous. So huge thank you to everyone who supported the book.
But hopefully you feel like you've got a clearer picture of what delivery management is now and how you can use it. Whether you are a delivery manager or whether you are anyone else in the organisation, from CTO all the way through to admin assistant, I hope that you'll find some value in delivery management.
If you want to learn more, then I've got a landing page, delivervalue.uk/engage, where you can reach out, talk to me. Or if you just want to find out more about the book, then delivervalue.uk is the place for that equally as well. Got a bunch of t-shirts up there, fairly vintage styles, cracking jokes about what good delivery might look like for you. I'll wrap up that and stop sharing my screen. I look forward to answering questions about delivery management and what that might mean in your context. Cool. Let's see if I can-
Jamie Dobson: Thank you very much for that, Johnny. You can post your questions in the chat, however, we've already got a few questions coming in which I can get to straight away. Okay, you're going to love this one, "What tools do you recommend for delivery plans, e.g. Jira plugins, et cetera, et cetera?" That's from Tommy.
Jonny Williams: I'm a huge fan of probabilistic forecasting. So thinking about something like Jira for instance, if you've got access to plugins, then anything that's going to let you look at throughput or help think about actually how much stuff you're getting done, that's usually more important than being too focused on stuff like velocity. So using data to inform your forecast is something that I'm a huge fan of.
The other thing as well is now-next-later roadmaps. So Janna Bastow is the key person who championed that and came up with the idea of now-next-later roadmaps. There's also a really good blog post by Jonathan Smart all about how we plan out work and move away from milestones in that fixed scope approach to working. Using something like a now-next-later roadmap just helps to avoid that early over-commitment and really position stuff in a way where it's clear that we're doing the most valuable thing now and then everything past that point could change, but we have our intentions aligned with the vision and aligned with what we want to do.
Yeah, for me, really simply, use data to indicate how much stuff you're actually getting done and then try and plan stuff out without over-committing because the risk there is that you end up delivering something that might not be valuable.
Jamie Dobson: Is it fair to say that mindsets need to come before the tools? This is not a tool thing, is it, Johnny?
Jonny Williams: Yeah, spot on. I think that's a great point, Jamie, because the risk is that otherwise you're still in that feature factory mindset or the build trap. There's a great book by Melissa Perry called The Build Trap, which really focuses in on this idea that you can end up just churning stuff out and being fixated on delivering ever-increasing scope. But if you're not actually getting to the point of something valuable, there's no point. I think as you say, Jamie, that mindset where you're really focused on do the most valuable thing first and then find what's going to be the next course of action is the best way to approach it.
Jamie Dobson: Very good. I don't know if Tom is in the call, but I hope that answered your question. Maybe if you are, you can let us know in the chat. Here's one from Laura, "In terms of ensuring your team is delivering value, how do you as a delivery manager work alongside a product manager?"
Jonny Williams: For me, that relationship is really key. I've come back to that model, the tree and verity of teams where you've got that value outcome lead, you've got the team outcome lead, and you've got a technical outcome lead in a lot of teams.
Personally, I think that kind of partnership of thinking about the different roles of enablers is really key. One of the things I like to do, something I've posted about in fact today on LinkedIn, was thinking about creating a team canvas or thinking about the responsibilities that might exist in the team to make sure you're not going to be overlapping too strongly because you don't want to be treading on each other's toes. You don't want to be in a position where the stuff that you're doing is going to block someone else. I think agreeing what everyone's going to do in the team is a really good thing.
Obviously you want that collaboration, you want some healthy overlap, but you don't want to actually get in the way. But I think the key distinction really is that delivery management is more about the enablement of the team, including a product manager, where a product manager might be more focused on the vision, the direction, and the value. How are we going to go after value, and how can we maximise that value as well? From a delivery management standpoint, it's really just ensuring that the team can be as effective as possible, which then genuinely tends to fuel the kind of work that a product manager's doing. It normally should put us in a position where actually product manager can be 10 times more effective because the team is performing in a healthy way and they're not burning out and they know that they've got the right level of work in progress.
Jamie Dobson: Brilliant. Brilliant. I hope that answers the question there. "How do you encourage, Johnny, the team to constantly look at code and processes through the lens of optimising for cloud native rather than the hybrid solutions we currently have in place?" That's from Dawn.
Jonny Williams: It is a really interesting question thinking about that shift in ways of working and thinking about the approach and what we're doing.
For me, stuff like retrospectives is really key. I think there's a danger with retrospectives that they become too focused on a template that you're using and having funny illustrations, all that kind of stuff. But really, that is the domain of continuous improvement more than anything else, is be brutally honest, be completely open, and just really zone in on the idea that we should be looking at what we're doing in the most ruthless way in a lot of contexts.
I think posing those questions and using powerful questions is one of the most effective things you can do to ensure that a team is adopting these new approaches and actually reflecting on what their goals are, because there's a risk, especially when you're trying to go cloud native, that you don't actually implement the changes. I think actually using stuff like retrospectives and being really focused in on, are we doing the right thing, are we moving towards our goals, that's how you can ensure that there are those reviews happening.
I also advise trying to coach in practices like extreme programming, thinking about stuff like test-driven development, pair programming, and just making sure that you've got that kind of collaborative work that actually is effective for the team to ensure that you've not just got people working in functional silos. That mitigates the impact that you can have as you move towards cloud technologies or containers or whatever it might be that's going to enable that kind of effective delivery.
Jamie Dobson: I hate retrospective... not retrospectives in general, but I was very lucky to meet Norm Kerth who wrote the original book on software retrospectives and created the retrospective plan directive. So many of us, it's just a habit, chuck in a retro, let's do a debrief. But it's not real failure analysis. The thing is, if you look at a team and simply ask, "Has this team changed direction in the last 12 months? So for all the retrospectives they've done, have we changed?" If you haven't changed direction, it's probably because you haven't learned. I would say it's better to just not do the retro again, get an hour back or just go to the pub because you'll accidentally spit something out that you'll learn from. It's really interesting because there's all these best practices, but as soon as they become best practices, they go from being something useful to something ceremonial, and even the best of us can't avoid that. Anyway, sorry, I'm just chucking in my...
Jonny Williams: It's a really good point because I think that idea that our work is inherently complex, so as soon as we've moved towards the idea that we can apply best practices, we're ignoring that complexity. We have to do what works for us. I think there's nothing wrong with a good pub retro and think that's part of the thing, is if you're doing a retro and not changing something, you're probably not actually doing a retro, you're just, I don't know... Not sure it's got any point really.
Jamie Dobson: Well, no, and Ian, my colleague, he's a sadomasochist actually, but he's just put in the chatbox, "Retros need to be painful." Actually painful when we're doing with him. That's true. There's probably an element of truth in that. I think the other thing is in tech we're all quite nice and we're all very much into creating inclusive spaces and psychologically safe spaces, but sometimes then we tread on eggshells or we go around in circles. Psychological safety does not mean you don't tackle things head on.
Jonny Williams: Absolutely.
Jamie Dobson: I also think there's a poor understanding of what does psychological safety look like. If we knew what it looked like, our retros would be better, but we only think we know what it looks like.
Jonny Williams: Yeah, definitely.
Jamie Dobson: Right. Then let's see if there's another question. Oh, this is quite a good one actually. This is from Hannah, "In an ideal world, what's in and what's out of scope for a delivery manager? And more importantly, how do you manage those expectations for teams?"
Jonny Williams: The fundamental question for me, I really like this question because there's a bunch of stuff like that gov definition which feels like, "Oh, should I really be doing this?" For me, the most fundamental question is, is it blocking the team? That is usually what decides what's in and out of scope in terms of delivery management.
So if the team is blocked, then we really need to think about how can we remove that impediment, how can we move past it? And therefore, there is probably something that I'm going to need to do when I'm working within that delivery management context, whether that is helping someone in the team see that they can help the problem, or whether that is me actually removing the block of myself and then hopefully bringing back what I've learned and showing it with the team so we don't find that blocker again.
So I look at stuff like financial management or some of the commercial stuff that I end up picking up, they're impediments and they're impediments to value, which is why they need to be removed. The other stuff is completely in scope. I think one of the challenges is that those three aspects of enablement for me are at the core of what is in scope when you're thinking about delivery management, but it's applying them in the right way. So don't overstep the boundary. You don't have to facilitate every conversation. You don't have to coach every single person individually in the team, and certainly don't have to try and become their therapist because that is not what you're there to do. Really boiling it down, the scope is being those three aspects of enablement, living it without overstepping the boundary.
That all comes back to what good facilitation looks like most of the time. What does the team actually need? So start with the question, what's the team actually need? and that'll probably define what is going to be in scope for you to do. A lot of the time though, one thing I will say is that many challenges around delivering management exist beyond the team. So in order for the teams to be effective, you need to think about the entire system of work, apply good systems thinking, and think about the interactions that they're having with other people in the organisation, whether that be teams, whether that be managers. That's kind of where a lot of the headaches are going to emerge from. So don't solely look insular, don't solely look inside the team, look beyond the team as well, because that's going to be the stuff that usually unlocks most of the team's capability and helps them really be effective.
Jamie Dobson: I've got a question that may or may not be related to my day job running a consultancy. What happens if you bring in a delivery manager practising? Because I met a person yesterday, a very nice person who scaled an awesome professional service company, and their engineering managers, their line managers used to help run projects, but then they were like, "Right, we've got to bring in delivery management." But when they did, the old leaders of the project actually felt pushed out, elbowed out, and there was a bit of a power struggle. Have you ever witnessed that, Johnny?
Jonny Williams: Yeah, definitely. I think it's really interesting if you do try and... When organisations just inject something like that, it's really challenging and can be very confrontational. It's one of the reasons, whenever I land with the new team, I always try and take the backseat. I'm not there to rock up and be like, "Right, what am I going to change? What's broken? How are we going to fix all of the stuff that has been a headache?" Because half the time a team doesn't want that. I think that's the same with organisational change, that if you're going to try and deploy a new discipline or you're going to try and deploy a new role, you need to ensure that that starts with the backseat and starts with small scale experimentation.
For me, equally, it's this aspect of how de-risk some of these decisions. When it comes to something like starting out with delivery management, try it once, see how it works, see what the headaches are, and then build out from there. Don't grow wholesale with change, because if there's anything that kills change, it's that wholesale, we're going to do everything all at once. But with big agile transformations, I've been involved in enough of those to see all of the things that cause them to fail. Most of the time it's trying to do it all in one big bang. It just does not work. It's a very old way of thinking about change as well.
Jamie Dobson: So we are bringing in a delivery management practice. Now we're all super excited because we're... Just full transparency now, I mean, we're not recording this right? So full transparency. So we're scaling, Johnny, so we are now 110 people and we're hitting all those traditional bumps. Recently, John joined as our VP of Engineering and Kate joined as our COO. And as soon as they arrived, they both said straight away, "We need delivery managers." So we're now building that capability up. I actually just went onto the job site so I could share the link, but the job's been closed, which makes me think we've probably got enough candidates. So fingers crossed, we're going to have a delivery... The difference is there's been no power struggle at Container Solutions because it's a really difficult job. We're crying out for professionals to come in and help us out and help us deliver better value and service to our customers.
Jonny Williams: Amazing.
Jamie Dobson: We already deliver very, very good.
Jonny Williams: Of course. Of course.
Jamie Dobson: Of course.
Jonny Williams: It's just an accelerator. It's a multiplier.
Jamie Dobson: This is next level stuff. Right, we've got a question. I think this is from our VP of Engineering, John, "With GIT analysis tools like Pluralsight Flow and Haystack becoming more popular, is delivery management becoming a more technical as a discipline?"
Jonny Williams: That is a really fascinating question. I often like to lean into this idea that delivery management by default is technical anyway, but might not always be technological. That distinction between technical and technological is quite an important one because some of the technical stuff that I do, for instance, like Monte Carlo simulations or some of the things that I've done around even formulating a workshop, you have to understand the dynamics between people and you have to understand how certain tools and techniques that you might bring to the table are going to impact others. Equally, a lot of the reading that we do is related to behavioural psychology or understanding stuff like Conway's Law and having that concept around sociotechnical, architecture, or sociotechnical practices. So there's a high degree of, I think, technical awareness that has to exist.
If you are applying systems thinking, even something like Team Topologies for instance, means you need to know enough about technical stuff that you can apply these ideas effectively. Where it starts leaning more into a technological discipline and expands upon those technical ideas, I think there is an exposure to this stuff, which in some ways, harking back to the gossip around ChatGPT, it's almost like there's an abstraction of some of these things, which makes the technical side of the work easier to consume. But therefore the theoretical understanding that you need to have has to be richer and deeper so you can really make the most of it.
When you're looking at these analysis tools, for instance, when you're getting an awareness of what's actually happening in the code, what the tools are doing, I think this aligns with the movement towards socio technical roles and socio technical knowledge, where the two are intrinsically linked. We can't simply look at the tech and think it won't work without the people, but you can't look at the people and think they can deliver value without having a good understanding of the tech.
In terms of is delivery management becoming a more technical discipline, I think that any effective person who's trying to apply delivery management should really be embracing the technological awareness that they need it. It's a really valuable thing to deepen that knowledge, even from a theoretical standpoint. You don't have to be hands on keyboard, but get a sense. So I've been reading Clean Agile and Clean Architecture, because for me personally, the more that I understand architecture, the more effective I can be at calling out stuff like Conway's Law where the way that the teams are structured has an impact on the system that we build. So personally, I would always advocate even at a really theoretical level, have a deeper understanding of the tech. When you're thinking about code analysis tools or you're thinking about stuff like Git analysis, which is a great example, it all comes back to interaction patterns. It all comes back to how people work, because the code really mirrors the people and the people end up mirroring the code.
Hopefully that answers that, John. But it's a really interesting question. I think more of this stuff will become abstracted, but it means the bit that isn't abstracted, you need to understand in even greater depth so you can make the best of the stuff that is abstracted.
Jamie Dobson: I hate it when people somehow think management is not a technical discipline. It's like being a dentist or an accountant, there are things you can learn and you can apply and you can improve. There's not nothing magical. Now, I think we're coming close to the end of time, so I think we've got time for one more question. Does that work for you? I'll just check with Carla and Jamie. Thumbs up on one more question.
Carla Gaggini: Yes.
Jamie Dobson: Okay, Johnny, you okay to go for one more question?
Jonny Williams: Yeah, yeah, absolutely.
Jamie Dobson: Right. Oh, here we go. "Is PMO dead? And if it's not dead, where do they sit in the value, tech, team triumvirate?" If I've said that word right.
Jonny Williams: Yeah, yeah. Nailed it. There is a really good video titled "The PMO is Dead, Long Live the PMO". Once again, he's got a good few call-outs. I hope I get some sort of commission off John Smart at some point, but Jonathan Smart has recorded that video. The idea in that that I really relate to is this idea of having value enablement teams instead. So pivoting that kind of idea of a PMO, which traditionally has been very oriented around more command and control capability, being around that discipline of we are going to be the people who set standards, tell you what you're doing, and position you in the places so that you can actually operate.
Shifting that towards being more explicitly around enablement I think is really important and actually a good use of that PMO capability. If you've got these people whose PMO skillset is around coordination, supporting the people that work in an organisation to know what they're doing and have that visibility, I think that actually you're really well-placed to pivot towards value enablement, which really is about a larger scale discipline of removing impediments, making sure that people know what's going on, helping with visualisation. And especially in a remote world when we're thinking about engineers spread out across the entire world, trying to deliver value on these products that are most times complex, you can't do the stuff that we used to do in person around like walk the walls or look at a kanban board and some team's space or whiteboard, however they were structured. A PMO actually, if they change function slightly, could be the really instrumental people who remove that burden from a team of making sure that people know what's happening, that people know what's going on. Whether that is creating something or cultivating a virtual MIRO space that enables people to walk the walls or whether it's being the people that go along to sprint reviews and capturing the information that exists in that format and making sure that other people can access it, I think there is a role for those people.
And much like I say in the book about project management, these disciplines still have value. It's just that they might not be the right disciplines for the kind of self-organising, empowered teams that we really want to see so that they can own and run product. But they might fit in somewhere else. I think each organisation is unique and has to make those decisions, but there's usually a place.
Jamie Dobson: Very good. On that note, it's time to wrap up this webinar. I actually thought a lot of the questions were really very sensible today. Sometimes we get some bonkers and then I have to decide, am I asking them or am I not asking them? Thank you very much. Let's just wrap up with a few more announcements and a few thank-yous.
First of all, I see my colleague Maggie's on this call. Maggie, I've booked my flights to Canada. So if anybody is in Canada and wants to meet me, I'm going to be there in the week of the eighth, hanging out in Toronto Monday, Tuesday, and then Montreal, Wednesday, Thursday. There was a group earlier who dialled in from a board meeting or boardroom together. I hope they had a good experience. I didn't mean to pick on them in the beginning, but we hope you've enjoyed this and any of the people who are struggling with cloud native or delivery management... Hello, thank you for putting your camera back on... we hope you've enjoyed it. Please send us some feedback. We do listen to all feedback and we're always looking to improve.
Container Solutions are awesome at what we do. We're brilliant engineers. We're the best in the business when it comes to getting stuff to the cloud and helping customers learn. If you need any help, give us a call. There's a very good chance you'll meet our new delivery manager on the pre-sales call.
Don't forget the conference next week, right? WTF is a community, right? It's really more about helping the community. It doesn't really work too well as a sales tool. But if you're interested in all of the work we've been doing, come to the conference, keep your eye out for the next webinar, there's lots of stuff coming up. Subscribe to the newsletter. There's not going to be one next month, but something will come back later. And on that note then, it's the thank-yous. Thank you to all of you for attending and asking sensible questions. And for those of you who switched your videos on, that was very nice. Thank you to my team from Container Solutions, which is Jamie, Carla, and Theresa. But Theresa's not here today, I don't think. She's usually our...
Carla Gaggini: She's hiding somewhere.
Jamie Dobson: She's hiding...
Carla Gaggini: There she is. There she is.
Jamie Dobson: Hey, Theresa. So thank you to the events team, Carla, Jamie, and Theresa. Thank you to me for awesome facilitation. Round of applause. But the biggest round of applause is for Johnny for coming kicking with ass this talk and really entertaining us. So thank you, Johnny. Good story-.
Jonny Williams: Thank you, everyone
Carla Gaggini: From us, Johnny, thank you.
Jonny Williams: Thank you all.
Jamie Dobson: We will see you all at the next webinars. We wish you happy Thursdays and happy Fridays tomorrow. Take care of each other, it's a very strange time in the economy right now, and we'll see you next time. Bye.
Carla Gaggini: Thank you all.
Previous article
