This article was first published on CMSWire on March 28th, 2022.
Project managers. Relationship managers. Brand managers. Their job titles vary from one organization to another, but there’s a large class of professionals out there whose jobs center on the management of work.
They liaise with business units, follow up on requests and reviews, update project management software and attend a whole bunch of meetings. It’s not that they don’t work, but they don’t produce deliverables. They rely on others — let’s call them doers — to get work over the finish line.
That’s not necessarily a problem, except when the number of managers gets out of proportion to the number of doers. When that happens, work slows to a crawl. With so many people pushing work into the system, but not enough people to complete the tasks, nothing ever gets done. Whoever shouts the loudest gets attention, and it seems like you need more managers to shepherd work out the door.
If this sounds familiar, you do NOT need more managers. You need more doers.
But lately I’ve seen more and more marketing teams, and organizations in general, that have over-indexed on management and neglected their doers. Here’s why that’s a problem, and what we can do about it.
You Can’t Be Agile Without Doers
With an excess of managers and a dearth of doers, there’s no way to be Agile. In and of itself, that’s a problem.
Agile has been proven to deliver quality work to customers faster, with less waste and less burnout. It’s the best-in-class way of working for teams of all shapes and sizes.
But Agile ways of working are designed for use by teams of doers. The people doing the work get together and decide how much they can do by when, who’ll be responsible and how they’ll support each other to get it done. They make these choices based on the value they’re expected to provide to customers and the business.
When an Agile team is made up of just a couple of doers and a whole bunch of managers, you end up with lots of people jockeying to get THEIR stuff done. They don’t really care about value, because they’re evaluated on their ability to push their work out the door. Maybe it’s the highest value work for the business, but maybe it’s not. Either way, they want it to get done yesterday.
Doers get stressed, don’t focus on delivering the highest value work, and succumb to the siren song of context switching. In other words, everyone’s working flat out, but nothing’s getting done.
How to Tell If You Have Too Many Managers
Of course, there are lots of reasons that you might have burned out teams but no finished work to show for it. A managerial glut isn’t always the root cause.
So how do you know if this is your issue?
It’s usually quite obvious to our AgileSherpas coaches when they review org charts and start trying to build Agile teams. I’ve seen this happen three times in the past month, so I’ll give a hypothetical example based on reality.
A marketing and communication (MarCom) team of 50 people wanted to transition to 100% Agile (as indicated by best practices and the 2022 State of Agile Marketing Report). We reviewed their current org chart and began trying to put together Agile teams.
Agile marketing team composition is based on the type of work the team does, but for our purposes let’s assume that all their teams needed a writer, a designer, a digital strategist, an email marketer, and a marketing technology specialist to work with their tool stack. Add in a team lead, and we’ve got six people per team.
This particular group is a centralized marketing department that serves seven business units (BUs), which means that ideally, we’d have seven Agile teams so each one could be focused on providing value to their dedicated BU. With 50 people and six people per team, we should be able to get there.
But as soon as we start mapping out the teams, we see that we have 12 project managers and another eight relationship managers.
That means nearly 50% of the MarCom headcount is devoted to figuring out what work needs to be done (relationship managers) and then shepherding it through the system (project managers).
So instead of the seven Agile teams we need, we can really only build four (and that’s assuming we have four of all the necessary skill sets). That means each team is going to be spread thinner, be less focused and struggle more with prioritization.
In this example, it’s clear there are too many managers and not enough doers.
What to Do About Your Doers
If this sounds like you, you’ve got a couple of options open to you.
The first is to build as many Agile teams as your doer headcount will support and measure the difference between those dedicated teams and the more traditional split focus of the non-Agile teams. You’ll see a much greater delivery rate from your Agile teams, which will give you the data you need to make the case to hire more doers.
The second option is to supplement your current doers with third party support, meaning contractors, agencies and/or freelancers. In this case you’ll still be best served by bringing your teams together around value delivery so they can focus on doing the right work for the right people at the right time, but you can be less fixated on having ALL the skills you need “in the building” from day one.
In both cases, you’ve got some hard conversations ahead of you, because you’ve still got too many managers.
Some people can transition into Agile team leads. These people oversee both the Agile process and the work being done, so project managers and/or relationship managers can sometimes be the ideal fit.
Others might have a doer background that they’re willing and able to tap into to join the Agile teams.
But if Agile is your destination, it’s best to accept that some of your managers may not have a place to land there. Upskill, re-skill and repurpose people whenever possible, but approach the process with open eyes.
Managers matter just as much as doers, but we have to get the proportions right if we want to be Agile and effective. Slow delivery of work doesn’t mean you need more people to manage the process; it means you need more people doing the work and an Agile environment to support them.
