Last Tuesday I posted on LinkedIn that project managers don’t exist. Or at least I don’t run into many of them anymore in the tech and digital product development world. I also shared that this baffled me because my friend Chris, who runs a project management training company, told me recently that I had a big blind spot here. He, perhaps obviously, was seeing plenty of project managers coming in for training and certification. My assertion that Project Managers didn’t exist anymore was ridiculous to him. Rightfully so, it turns out. That LinkedIn post ended with a question. If you mapped a standard list of project management responsibilities onto your product team today, who is actually doing that work? 69 comments later (to be fair 28 of them mine, which tells you how much I enjoyed the conversation) I have a better idea of what’s happening here and who’s doing what these days, especially on tech teams.

If there’s one thing I’ve learned over the years when it comes to writing in public it’s that when you start any article with “[this thing] doesn’t exist” people get fired up. No big surprise here then when more than half of the people who commented on that post had a project or program management title along with a PMP or a PRINCE2 certification and/or a headline with the word “delivery” in it. When you tell someone their job isn’t a thing anymore they speak up to defend it. Makes sense. Interestingly, the folks I usually write for, the product managers, designers and engineering leads inside big companies, stayed a relative minority in this conversation.

So who is doing the project management work?

29 people in the thread commented on where the project management typically falls in a tech/product team. I tried to summarize those comments into the four buckets below.

• 13 folks said project managers are alive and well. I was looking for them in the wrong place. As a career-long advocate for cross-functional teams, I assumed they’d be on the product team itself. Nope. It seems, many PjM’s sit outside the tech team, across the marketing, sales, support, legal and client workstreams that need coordination and alignment for anything to actually launch. They cover the work that manages a team to a deadline for a physical product (e.g., a hardware CTO described the day after which changing your mind costs a re-production of the product, a recall of that product or a redeployment of shipments). They also cover regulatory deadlines, where a payment scheme mandate or a compliance date arrives from outside the company and doesn’t move. And they continue to thrive wherever a sponsor still cares how long something will take and what it will cost. Sounded to me, and at least one commenter agreed, is literally everywhere.
• 9 commenters said the project management work is now being done by the product manager. Just because there was no one with the title of PjM, the work didn’t go anywhere. Somebody still has to do it. The product manager became the go-to person for the dates, the dependencies and the status updates. Several people added that the same thing is happening to designers, who are now expected to cover UI, UX, strategy and some development just to stand out at their jobs and in the market. 
• 6 people said the work went to a role with a different name. Program manager, technical program manager, delivery manager, product operations, release train engineer, and “coordinator,” were all titles folks shared that now assume the responsibilities of project management. 
• 1 brave person said nobody should do the project management work anymore. Their argument was that a product-led organization that has achieved a modicum of predictability in their output as well as outcomes, should treat a fixed date as one more variable in prioritization (i.e., it’s not really a fixed date). They added that most organizations never get there and this confirms what I’ve seen in my work as well.

Let’s add it all up. 13 people said that project managers are still here, 9 said the product manager absorbed the job, 6 said it got a new title, and 1 said it should dissolve into the team. My hypothesis prior to publishing that LinkedIn post was the product took care of all of project management’s responsibilities. Turns out, I wasn’t quite right.

Where project management work goes depends on where the deadline comes from

Looking at the results of this, admittedly anecdotal conversation, it seems that where the project management work goes depends on where the team’s deadline comes from. A hardware deadline is physical and has real pain points associated with missing it. A regulatory deadline is external and immovable. A client deadline was written into a contract by someone who expects to know when they’ll have their “thing” in their hands. In all three of those cases some version of a project manager still does that work. Their title might be different but the work is more or less the same.

Most deadlines on a digital product team don’t have that same, fixed nature. More of than not, they are internal, set by a stakeholder who wanted a date on a slide.  And, each time that slide changes, the date changes with it. That’s the world I see most often in my work with product teams. And in that world a role built to manage fixed time and scope initiatives is essentially set up to fail. This is likely why we see fewer project managers in digital product development. The mistake in my original framing was my own arrogance. I was treating “my world” as the whole world. That said, product teams aren’t excused from managing their work towards predictable progress and market success. It’s just a question of whether there’s already somebody on the team doing that work and if there isn’t, inevitably it falls to the product manager to do it.

How to figure out who has to do the project manager’s job on your team

Give this a shot with your whole product team in the room if possible.

1. Write down the standard list of things every initiative needs to keep track of. Make sure to include:
   • Budget
   • Schedule and milestones
   • Scope
   • Cross-team dependencies
   • Risks and issues
   • Status reporting to sponsors
   • Vendor and supplier management
   • Launch coordination with marketing, sales and support
   • Any external deadline (regulatory, contractual, hardware). 

Don’t argue about whether each item counts as “project management.”

2. Next to each item, write the name of the person who actually did it last quarter. Write an actual person’s name. “Nobody” is a legitimate answer, and so is “the product manager, at midnight, the night before the steering committee.”
3. Mark each deadline on the list as real or internal. Real means it comes from outside the team and will not move, even if you ask nicely. Internal means someone in your company chose it and there’s a chance that, if properly convinced, they could choose to move it.
4. Make a decision for each line. Work tied to a real deadline needs an explicit owner. That work then needs to be accounted for in their weekly expectations. In other words, this eats into their capacity. It doesn’t matter whether this person is a program manager, a delivery manager, product ops or the product manager who agrees to drop something else to make room. Someone has to own it. Work tied to an internal deadline is worth a team-wide conversation to understand how real that deadline is and what the risks are of not meeting it. Make sure every line item in your list has a name next to it. That person either needs to manage the team to get that work done or they’re responsible for figuring out, over time, which parts of the plan/roadmap are flexible and which aren’t.

Take the finished tally to whoever runs your product organization, with the hours attached to each activity. In my experience the “who does the project management work” conversation gets a very different reception when it arrives as a list of what a specific product manager did last quarter instead of a complaint about being overloaded. Use the evidence you’ve collected to have an objective conversation on how you and your team are going to handle this work. This way there are clear expectations on what exactly which parts of it the product managers are going to do and, because of the extra workload, what may not get done. 

(If you want the longer argument for why this work is growing everywhere except in tech, we wrote it up on the Sense & Respond Learning blog.)