What’s wrong with delivery management?
Something has been playing on my mind this year. What does it really mean to be a delivery manager? Equally, why does my experience as a delivery manager seem so incongruous with the experiences and expectations of others?
Earlier in 2021, I had a few weeks where I noticed other delivery managers (DMs) being asked to take on increasing amounts of project management responsibilities. At the time I was working with two fantastic teams finding their feet with increasing autonomy and a maturing product; they had some agile foundations and investment in DevOps approaches. I was saddened when I would hear other DMs defining fixed scope work and delivery dates for their teams. I was even more disheartened when I saw senior managers scold DMs for not being able to produce a Gantt chart full of feature focussed milestones.
I had been able to navigate away from this type of work and was determined to invest the majority of my energy into creating the right environment for the teams I supported instead. Not everyone had this luxury.
I shared my thoughts briefly on Twitter in June. “I’ve read and heard a lot of things [that] highlight how problematic the delivery manager job title can be in gov. It carries a lot of baggage. Sadly that baggage can get in the way of potentially high performing teams.” I’m a much more consistent tweeter than blogger so it felt like the best place to explore how others felt about the topic. It sparked some positive discussion, but more than anything it highlighted that the consensus on exactly what delivery management is really doesn’t exist. This remains true, even within government where it is a relatively well-established role.
There are some top quality hot takes about delivery management across the internet. A personal favourite of mine is from Jason Knight: “Delivery managers are what regenerate when you defeat project managers in the final fight”. My personal hot take is that I think delivery management faces a lot of challenges, and ultimately probably isn’t the right role for the job.
Job titles are problematic at the best of times because they bundle up assumptions without acknowledgement and frequently reinforce hierarchy. Neither of those things is conducive to an agile or lean environment — let alone a psychologically safe one. As Mark Dalgarno said to me a few weeks ago; this type of work is often easier without a job title. Breaking down the delivery manager job title helps to identify where problems with the role start.
“Delivery” as a concept is problematic. So much so that I’ve started to resent its use in many conversations. Delivery is regularly used to infer that a “thing” will be delivered. In a lot of organisations, this means the delivery of a project with tangible outputs. In the context of an agile environment, we can rationalise the “thing” to be the delivery of steps towards a goal. However, in my experience, the delivery of a “thing” can regularly be the wrong course of action. Delivery should change direction, or even stop, as soon as we recognise a bad idea (or a bad goal). In a context with fixed scope, this might mean nothing has been delivered within scope. Or to phrase it in a way that I have heard from senior colleagues in the past “nothing has been delivered”. How do you square that as a DM? Especially if you are measured based upon output.
In order to avoid delivering bad ideas, teams often segregate the thinking from the doing or the design from the delivery. Having a discovery phase before a delivery phase. Defining delivery as its own entity leads us back down the rabbit hole of a design, implement, chuck it over the fence lifecycle. John Cutler recently said, “I’m seeing ads for something called a delivery manager. Who takes care of the software after it is born?”. Delivery is often used to mean “the implementation of pre-defined ideas”, but if we see delivery as the goal (or the strategy) we can easily end up in feature factory mode, delivering many “things” that add zero value to anyone, which end up abandoned because nobody thinks about life after delivery.
One solution to this problem with “delivery” might be to answer two short questions; “Deliver what?” and “Why deliver it?” For me, one word answers both of those questions, value. How we define value is a different and challenging topic, but it is an essential qualifier for the delivery portion of delivery management. We should deliver value because it will be valuable. However, this intersects enormously with other roles in a successful multidisciplinary team. Should the DM really be seen as the “value delivery manager”? That sounds much more like product management in a nutshell.
This leads neatly into the other half of this problematic job title. Manager. Allen Holub has covered this topic previously: “The word “manager” seems, more and more, to describe two utterly incompatible jobs. On the waterfall side, a manager is ‘responsible’ for on-time in-budget delivery of assigned work. On the Agile side, people describe coaches more often than not, but call them “managers.” Personally, I think that using the same word for two incompatible jobs is counterproductive. It just sows confusion. If they’re not managing something, they’re not “managers.” Teams manage their own work. Coaches help them with that. Call them coaches if that’s what they are.”
Being a “manager” has limited the ability for teams I have supported directly to be autonomous and self-managing. This can range from team members asking me to sign off their annual leave to being asked to fire someone. Management creates hierarchy, and hierarchy is the enemy of equality. Teams cannot function in a healthy way with an enforced false hierarchy. I had to work hard within teams to qualify the management aspect of my DM job title to be about managing the environment we all worked in or the blockers that got in our way. However, being expected by senior colleagues to represent the team in townhalls or performance manage engineers actively worked against the idea that the team didn’t need a “manager” from a waterfall world. We have an appetite to retain old ways of working while attempting to apply new ways of thinking.
My personal experience has been shaped by attempting not to be the team manager. I never viewed myself as the leader, instead, I was there to enable everyone to deliver value, and feel valued while doing it. However, I regularly hear DMs declare how unhappy they are that “their” engineers aren’t being productive enough, or that they are there to lead the team. The delivery manager role creates space for people to perform an autocratic function. Command and control can thrive in teams where the DM thinks like a project manager, or is forced into a position where their own safety at work depends upon the delivery of a “thing”. A DM should never be there to crack the whip, but the job title leaves space for that to happen.
Fundamentally delivery manager is a problematic job title because one person alone cannot be responsible for delivery. As Allen Holub says, “I’ve lately seen the title “Agile Delivery Lead.” There is no such [thing]. It’s the entire team’s job to deliver.” Delivery is a team sport. I regularly hear “Well, you are responsible for delivery” from senior colleagues, and I always feel like saying “…no I’m not, we all are”. If anyone ever doubts that, I would love to see what type of product or service a room full of DMs would deliver alone. It probably wouldn’t be anywhere near as good as one delivered by a multi-disciplinary team.
However, looking inside government where many DMs reside, a short definition exists. “A delivery manager is accountable for the delivery of products and services.” Is it any wonder that so many people expect a DM to be project managing a team when this is the introductory guidance for the role? How many antipatterns does this accountability reinforce? If you aren’t delivering a “thing” why are you there? Equally, do we really want to build a culture across government where the DM is accountable for delivering value rather than teams being accountable together? It suggests a desire for a single point of blame, or one person who command and control managers can use to avoid speaking with a team in order to drive results. That’s not the type of culture I want to be part of.
Thankfully, the government guidance goes into more depth and extends beyond this single accountability for delivery. Interestingly the word coach is used thirteen times on that specific GOV.UK page. This suggests that the initial introduction to the role isn’t quite accurate. Although the word coach isn’t emphasised, maybe Allen Holub’s guidance should be applied to the role. Should each team have a delivery coach instead of a manager?
The government guidance for what each role does in a Service Team adds to this argument. The guidance outlines that a DM is there to enable the team; create the environment, remove blockers, generate autonomy, champion accessibility. This also aligns with Emily Webber’s often discussed definition of delivery management: The DM is “the person in a skilled, multidisciplinary team who is concerned with enabling that team to deliver value. They do this by creating the right environment for the team to succeed, helping the team to self organise and creating a culture of learning and transparency.” Being an enabler who supports the team to self organise and generate autonomy doesn’t align well with being accountable for delivery, or with the idea of management.
More recently Emily Webber has written about progression frameworks for multi-disciplinary organisations. This includes some great ideas about ensuring roles don’t become siloed. It makes it possible to acknowledge the value of what is often referred to as t, pi or comb-shaped roles where people leverage a blended skillset. (This is a topic I regularly discuss with Himal Mandalia which has provoked acknowledgement of “glue work” where people perform multiple functions to enable teams). Emily’s post outlines a very simple definition of a delivery manager; someone who enables a “consistent, smooth pace of delivery”. This less specific definition is useful as it doesn’t limit someone to one approach or style but is far more focused on outcomes. How we enable teams to deliver value is open-ended. However, in my experience, smooth and consistent delivery requires a team that feel psychologically safe, supported, and have what they need to be successful. If DMs aren’t able to create these conditions then they won’t achieve the desired outcome. Equally, this outcome rarely aligns with the outcomes senior managers expect of delivery managers. How much time is spent reviewing plans, reports, RAID logs and RAG statuses rather than understanding the capacity a DM has to truly support a team.
In order to prepare delivery managers to enable a consistent, smooth pace of delivery many DMs learn and apply specific frameworks and methodologies. Scrum is especially prevalent across government (and notably not prevalent in prominent technology companies). DMs often attempt to adopt the scrum master accountability. The Scrum Guide suggests that a scrum master serves by coaching, facilitating, teaching, and enabling — across teams and the organisation. I remember Dan Brown telling me there is no reason a delivery manager should not be able to fully embody the scrum master accountability — “do they need to be different?” I personally found adopting this stance incredibly useful. My success as a DM came primarily from working as a scrum master, especially in a coaching capacity. But is this truly compatible with what senior people ask of DMs in most environments? If not, why are we encouraging people to adopt an accountability they aren’t in a position to fulfil?
It seems delivery managers are burdened by a role that is poorly understood by many, and sets the wrong expectations. This comment by Jo Crossick stood out to me: “When I act as [delivery manager], it’s usually in immature agile environments. I do scrum master plus line management, agile coaching for other managers, wider process analysis, support product, a lot of facilitation and a lot of shit-shielding. It’s a real agile+tech+product polyglot role. My aim is always to make myself redundant.” We expect so much of DMs and offer so little support for anyone to truly gain a sense of what good looks like. Ultimately resulting in a role where a truly effective team should be able to sustain themselves without a delivery manager in their ranks.
Which leads to a final question: Should we even have delivery managers? If they create a space for so many anti-patterns to occur, for old ways of working to be reinforced, and for coaching to be conducted under the radar as a coincidental side order to “things” being delivered would we not be better starting with something new? Something without the baggage of expectation and legacy. A role where one person isn’t told they’re “there to deliver” an entire product or service? Change won’t come easily, but in my opinion, we would be better being transparent about what we need. If organisations, including government departments, want project managers then hire project managers, and if they want agile coaches then bring on the agile coaches!
What’s wrong with delivery management? It doesn’t deliver.
Learn more about Delivery Management