What's wrong with supply management?
I can't help thinking – what does it really mean to be a Delivery Manager? And why is my experience in this role often at odds with the experiences and expectations of others?
At some point in 2021, I noticed that other Delivery Managers (DMs) were being asked to take on more and more project management responsibilities. At the time, I was working with two great teams that were growing with increased autonomy and a mature product, with some agile fundamentals and investment in a DevOps approach. It upset me when I heard other DMs give their teams fixed scope of work and deadlines. I was even more upset when senior managers scolded the DM for not being able to create a Gantt chart with a complete list of milestones focused on specific features.
I was able to avoid this practice and focused my efforts on creating the right environment for the teams I supported. Not everyone had that luxury.
In June I briefly shared with your thoughts on X (formerly Twitter). “Reading and hearing about the challenges of being a Delivery Manager in the public sector, I realized that the role comes with a lot of responsibility… Unfortunately, this baggage can get in the way of developing potentially high-performing teams.” I use X more often than I write blogs, so I thought I'd share this there to get other people's opinions. This generated positive discussion, but showed that there is no consensus on what supply management is; even in the public sector, where this role is already established.
On the Internet you can find many interesting opinions about Delivery management (“supply management”). Personally, my favorite saying is Jason Knight: “Delivery Manager is reborn when the Project Managers are defeated in the final battle.” Personally, I think Delivery Manager has a lot of problems and ultimately probably isn't always the best for getting things done.
Job titles can be problematic at the best of times, as they create assumptions and reinforce hierarchy. Neither promotes an agile or lean environment, nor does it promote psychological safety. As noted Mark Dalgarno recently, sometimes working without a clear job title can be easier. Parsing the name Delivery Manager helps identify problematic issues associated with this role.
The concept of “Delivery” can be confusing. I personally began to question its use in various contexts. Often the word “Delivery” is used to mean the delivery of “something”. In most organizations, this means completing a project with concrete results. In an agile environment, this can be interpreted as reaching certain milestones towards a goal. However, my experience is that delivering “something” is not always the right solution. Once we recognize a bad idea (or a bad goal), delivery should change direction or even stop. When we realize the shortcomings of an idea (or goal), the delivery must change or be cancelled. In the case of a fixed scope of work, this may mean that nothing was delivered within that scope. As a Delivery Manager, how do you evaluate such situations, especially if your work is measured by results?
To avoid bad ideas, teams often separate the thinking and execution process, as well as design and delivery. The delivery phase is preceded by the research phase. Defining delivery as a separate entity takes us back down the rabbit hole of the “design, build, discard” life cycle. John Cutler recently said: “I see an ad for something called Delivery Management. Who will take care of the software after it is created? The term “delivery” is often used to mean “the implementation of pre-defined ideas”, but if we consider delivery as a goal (or strategy), we can easily slip into “feature factory” mode, delivering a lot of “ideas” that are not useful and ultimately end up abandoned due to lack of further planning.
To find a solution to this “supply” problem, we need to answer two questions: “What to supply?” and “Why deliver this?” For me, both of these questions are answered by one word: value. How we define value is a separate and complex topic, but it is an important clarification for the delivery management part. We must deliver value because it will be valuable. However, this overlaps greatly with other roles in a successful multidisciplinary team. Can a DM really be considered a “value delivery manager”? It's more like product management in general terms.
This leads to another aspect of the role naming problem. Manager Allen Holub has already touched on this topic: “The word “manager” seems more and more to describe two completely incompatible professions. In the waterfall development model, the manager is responsible for completing the work on time and within budget. In the case of Agile, we are most often talking about trainers or coaches, but they are called “managers”. Personally, I believe that using the same term for two different professions is ineffective and misleading. If they don't manage something, then they aren't “managers.” Teams manage their own work. Coaches only help them with this. Call them coaches if that’s what they are.”
Working as a “manager” limited the ability of the teams I directly supported to be autonomous and self-managing. This manifests itself in requests from team members to sign off on leaves or fire someone. Management creates hierarchy, and hierarchy contradicts the principle of equality. Teams cannot function effectively under false, imposed hierarchies. I had to work a lot in teams to suit the management aspect of my role as DM and to be able to manage the environment in which we all worked, as well as the obstacles that inevitably came our way. However, when senior colleagues expected me to represent the team in general meetings or manage the work of engineers, this actively worked against the idea that the team did not need a “manager” from the world of the waterfall management model. We sought to preserve old ways of working while trying to embrace new ways of thinking.
My personal experience has been shaped by trying not to be a team leader. I never envisioned myself as a leader, instead I was there to empower everyone to deliver value and feel valued while doing so. However, I regularly hear DMs state that they are unhappy because “their” engineers are not productive enough, or that they are there to lead the team. The Delivery Manager role creates space for people to perform autocratic functions. Command and control can flourish in teams where the DM thinks like a project manager or is forced into a position where his own job security depends on the delivery of a product or service. The DM should not push anyone, but the job title leaves room for this.
Essentially, Delivery Manager is a problematic position because one person cannot be responsible for delivery. As I said Allen Holub: “I’ve been seeing the name “Agile Delivery Lead” lately. There is no such thing. Delivery is a team effort.” Delivery is a team sport. I regularly hear from senior colleagues, “Well, you’re responsible for delivery,” and I always want to say: “… no, not me, we’re all responsible.” If anyone doubts this, I'd love to see what product or service a room full of DMs can provide on their own. It probably won't be nearly as good as what a multidisciplinary team creates.
However, if you look into the public sector, where many DMs work, you will find short definition. “Delivery Manager is responsible for the delivery of products and services.” Is it any wonder that many expect the DM to manage the team's projects? How many antipatterns does this perpetuate? If you are not directly involved in delivery, why are you here? Also, do we really want to create a culture in the public sector where the DM is responsible for delivering value rather than teams being responsible for it together? This involves a desire for a single point of blame or one person that leaders can use to avoid communicating with the team to achieve results. I don't want to be part of such a culture.
Fortunately, public sector management is becoming increasingly thoughtful and goes beyond mere accountability for results. I wonder what's on the page GOV.UK the word “coach” is used thirteen times. This suggests that the initial understanding of the role is not entirely accurate. Although the word “coach” is not emphasized, perhaps Allen Holub's recommendations should be applied to this role. Should every Delivery team have a coach instead of a manager?
Management by defining the role of each employee in the service team supports this argument. The document states that the DM exists to support the team: creating the environment, removing obstacles, ensuring autonomy, maintaining accessibility.
This is also consistent with the often discussed definition supply management Emily Webber: “A Delivery Manager is a person on a skilled multidisciplinary team who ensures that the team can deliver value. To do this, he creates the right environment for the team to work successfully, helps it organize itself and creates a culture of learning and transparency.” Being a facilitator who helps the team organize itself and gain autonomy doesn't sit well with accountability for results or the idea of management.
More recently, Emily Webber wrote about development plans for multidisciplinary organizations. It has some great ideas on how to prevent roles from becoming separate from each other. This recognizes the value of T-, P- and other roles in which people use a mixed set of skills. (I discuss this topic regularly with Himalom Mandaliawhich led to the recognition”glue work“, where people perform multiple functions to help teams. Emily's post gives a very simple definition of a Delivery Manager: someone who ensures a “consistent, smooth pace of delivery.”
This less specific definition is useful because it does not limit a person to one approach or style, but is much more results-oriented. How we help teams create value is an open question. However, in my experience, running smoothly and consistently requires a team that feels psychologically safe, supported, and equipped to operate successfully. If the Delivery Manager is unable to create such conditions, then they will not be able to achieve the desired result. Moreover, this outcome rarely matches the outcomes that senior managers expect from DMs. How much time is spent looking at plans, reports, logs and statuses, instead of understanding what capabilities the DM has to truly support the team.
To prepare Delivery Managers to deliver a consistent, smooth pace of delivery, many DMs learn and apply specific frameworks and methodologies. Scrum is especially common in the public sector (and, notably, not particularly common in established technology companies). DMs often try to take over the responsibility of the Scrum Master. The Scrum Guide states that the Scrum Master serves as a coach, facilitator, trainer and specialist – in teams and the organization. I remember how Dan Brown told me that there is no reason why the Delivery Manager cannot take over the full responsibility of the Scrum Master. Personally, I found this position incredibly useful. My success as a DM was achieved primarily through my work as a Scrum Master, especially as a coach. But is this really compatible with what older people demand from DMs in most environments? If not, then why do we encourage people to take on responsibilities they are unable to bear?
Delivery Managers seem to be saddled with a role that many people have little understanding and expectations for. One comment Joe Crossica caught my attention: “As a Delivery Manager, I usually work in immature agile environments. I perform the duties of a Scrum Master plus provide line management, provide agile coaching for other managers, do broader process analysis, product support, do a lot of facilitation and protect the team from negative factors. This is the true role of an agile+tech+product polyglot. My goal is to always make myself redundant.” We expect so much from DMs and offer so little support that no one can truly understand what good is. Ultimately, this means that a truly effective team must be able to support itself without a Delivery Manager.
Which leads to the final question: do we even need Delivery Managers? If they create the conditions for so many anti-patterns to emerge, for old ways of working to be reinforced, and for coaching to be done behind the scenes as an incidental addition to the results to be delivered – shouldn't we start with something new? From something that is not burdened by expectations and legacy. A role where one person isn't told they have to deliver the entire product or service? Change will not come easily, but in my opinion, we better be open about our needs. If organizations, including government agencies, need project managers, then hire project managers, and if they need agile coaches, then hire agile coaches!
What's wrong with supply management? It doesn't deliver.
We will continue to understand supply management in open lessons:
