Originally posted at https://timwise.co.uk/2019/07/08/why-every-team-needs-a-delivery-manager/
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.
In short the team looks something like this:
- Product Manager
- Delivery Manager
- User Researcher(s)
- Content Designer(s)
- Interaction Designer(s)
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 and I’m constantly feeling guilty for not doing enough of that!
This structure is modelled on the structure of a team at the Government Digital Service(GDS)
The kind of structure I’ve more commonly see in the private sector is something like this:
- Project Manager
- Business Analyist (BA)
- SCRUM Master (in title if not in deed)
- Testers(s) / QA (Quality Assurance)
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.
The Product Manager is more widely known in industry as Product Owner. 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.
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.
In any organisation beyond about 20 people the bureaucracy starts to sneek 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 askunkworks project, but that can’t last forever and eventually the old meets the new and sparks fly. 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.
The approach is not new, Joel wrote this in 2000:
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/
but I’ve personally never seen it called out as a specific role like this outside of my work for “Digital” teams in UK Government. I hope this becomes more common everywhere.
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. I like the way the wonderful Mark ‘Stanners’ Stanley put it many years ago that I still think 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.
Soft skills are as critical as technical skills for a software engineer. No one works in isolation. Each person has to deal with teammates, colleagues, managers, etc. Therefore team interpersonal skills are essential too. Soft skills include things like good communication, honesty, teamwork, integrity, organization, empathy, etc.