Why every team needs a Delivery Manager (DM)

July 8, 2019

4 minute read (998 words)

I was explaining to someone the team structure I’m working in at the Department for Education’s DfE Digital and realised not everyone has seen this structure at work and the magic it brings.

Team structures

GDS (government) team structure

In short the team looks something like this:

Product Manager
Delivery Manager
Developer(s)
User Researcher(s)
Content Designer(s)
Interaction Designer(s)

At the top of the whole thing there’s a “Service Owner”.

Involved from the very early stages, but a bit less in the daily grind of building technical solutions, you’ll find a “Service Designer”.

It’s a very flat structure. It’s a group of peers who all bring their own strengths to the team, but with no hard boundaries, we all muck in with everything now and then. I particularly like helping with user research as it keeps me connected with the users. I’m constantly feeling guilty for not attending enough user research!

This structure is modelled on the structure of a team at the Government Digital Service (GDS)

Aside: Product who?

You may also not be familiar with Product Manager (I’ve not seen it as much in private industry), so as an aside let me explain:

~~The Product Manager is more widely known in industry as Product Owner~~ (well that’s what I though, actually it turns out product owner and product manager are not quite the same). This is someone who figures out the balance of features in a service and the software that supports it, based on all the various constraints and inputs (e.g. user need, security, stability, internal need). One output of this role is prioritization of work.

Private company team structure

The kind of structure I’ve more commonly see in the private sector is something like this:

Project Manager
Business Analyst (BA)
SCRUM Master (in title if not in deed)
Developer(s)
Testers(s) / QA (Quality Assurance)

Which is better?

I’ve seen good and not so good people in all of the roles, and number of roles varies with team size.

I think the GDS-style team structure is superior when it comes to shipping user-value as a development team.

DM for the win

The role I want to focus on here (though they are all awesome) is Delivery Manager as it’s the most uncommon in my experience.

I’ve personally never seen delivery management called out as a specific named role outside of my work for “Digital” teams in UK Government. I hope this role becomes more common everywhere.

So what does a Delivery Manager actually do?

Greasing the enterprise wheels

In any organisation beyond about 20 people the bureaucracy starts to sneak in, layers of rules are added as a business tries to avoid repeating previous mistakes, and as you hit enterprise scale it’s positively stifling, to the point that people issues and an inability to even open Microsoft Word (TM) (R) ((c) 1908) on a work computer without signing 3 forms in blood, become nearly impossible. The thing is, a dev team is usually building something that hasn’t been built before, maybe as part of a major change to how the organisation functions.

Web development is more than just taking your sales brochures and putting them online, if that was all we wanted I’d give you a copy of WordPress and find something else to build.

Sometimes you can hide the team away in a skunkworks project, but that can’t last forever and eventually the old meets the new, and suddenly the whole project is at risk of being rejected by the legacy organisation. The productivity can be sucked out of a development team for good, they can end up unable to deliver anything.

This is where a Delivery Manager role is golden; they deal with making sure the organisation’s goals to have this new service / system / product / software are able to be progressed, conversations & endless meetings had, finance obtained, hardware procured, forms filled, security audits managed sensibly, pile-on demands defended … the list is endless. By having this role the team can focus on building and shipping, comfortable that they won’t be sidetracked or blocked.

I still like the way the wonderful Mark ‘Stanners’ Stanley put it back in 2012. I think this cuts to best thing about it:

The delivery manager is there to remove any and all things that are hindering or ‘blocking’ them, so the team can deliver the product.

~ Mark Stanley - https://gds.blog.gov.uk/2012/12/12/a-day-in-the-life-of-a-delivery-manager/

The approach is not new, back in the year 2000 Joel Spolsky wrote:

Compare this to Microsoft, where things are done at the lowest level, and most managers act like their most important job is to run around the room, moving the furniture out of the way, so people can concentrate on their work.

~ Joel Spolsky - https://www.joelonsoftware.com/2000/03/19/two-stories/

Running great delivery teams

You’ll also find the Delivery Manager doing inward-looking work similar to the role of “SCRUM Master”. This includes setting up the right agile environment (which may SCRUM, Kanban, or something else), tackling any dysfunction and poor team performance that has built up, keeping in touch with all the team to make sure they are happy and productive, running team retrospective sessions, and sometimes hiring-and-firing to get the best team in place.

Is it good for devs?

As a developer on an Agile team working inside a government team (not for the first time), I am eternally grateful for all the things I don’t have to worry about because we have a DM. It’s not that I’m not capable, I’ll happily turn my hand to the biggest problem of the day for a team at any time, but the code won’t write itself and that’s what I was hired to be a pro at. Having a DM lets me focus more creating software that actually does a job for our users, and makes sure we can do what’s needed to make great systems even if that reaches beyond the team’s original boundaries.

Tim Abell