The Delivery Manager Role

I have always been interested in taking the holistic view of product teams and understanding and appreciating each and every critical role.  In a recent article I wrote about the dynamics of strong teams versus weak teams, and judging from the response to that article, many of you are interested in this as well.

I focus most of my attention on the product owner/product manager role because I view that role as the lynchpin.  However, of all the roles, I would say that I see the most grief associated with the various guises of project management (project manager, program manager, and/or ScrumMaster).

In my writings, I’ve tried to highlight and encourage the behaviors when this role is performed well, and tried to highlight the problems and behaviors when this role goes wrong.

But I’d have to say that my writings on this topic seem to have had little impact.  While teams that have the right type of person and behaviors seem to truly love their project manager, far too many teams either find no value in their project managers, or worse, view them as a liability rather than an asset.

In some companies, they’ve become so frustrated with their project managers that they’ve gone so far as to dismantle the role completely (usually handing back the project management responsibilities to the product manager).  In small product organizations, this is fine.  However, in larger organizations, the consequences of putting the project management responsibilities on the product manager usually cause even bigger problems.

I see three root causes for the ongoing problems with this role:

1. The first is that the main certifications in this space are still from the old Waterfall era, and what you’re really seeing is a clash of values between Waterfall and Agile.
2. The second is when organizations confuse the Agile coach role with the impediment chasing role.
3. The third is when the project manager is so non-technical that the team views it as more time consuming to explain the impediment than to try to deal with it themselves.

But for whatever reason, before you give up on the value of having someone on the team dedicated to chasing down and removing impediments on behalf of their team, I’d like to give one more try to help you turn things around.

For quite some time, I’ve noticed a few teams using the title “Delivery Manager” for the project management role.  I never thought too much about it, but I’ve come to believe that the project management “brand” is so damaged that a re-branding may be in order.  Of course a re-branding is only helpful if the meaning changes as well.  What I like about the “Delivery Manager” title is that there’s little question about the purpose – getting stuff delivered.  The role is not about discovery, and it’s not about coaching on process; it’s all about getting stuff pushed live.

There is one other aspect to this role that I like.  In many organizations, where there are many users and customers and there are ongoing responsibilities regarding triaging run-time issues with the product, they often have someone with “production support” responsibilities.  Again, if the organization is small this is probably the product manager, but for larger organizations, it can easily consume a good part of a day chasing down production issues.  The Delivery Manager often has these responsibilities as well as the daily impediment chasing.

If your product managers are so busy with impediments or production issues that they can’t get the time doing product discovery to ensure the team has a strong, validated product backlog, then I hope you’ll consider the experiment of trying out a Delivery Manager and see if you can improve your throughput and results.