When Should You Hire Project Managers?

Once again, I am leaping off of a substack with which I agree 95% in order to quibble with 5% of it. In this case, this one!

The specific quibble is here, and forgive a large block quote:

“One area where I’ve consistently disagreed with many organizations is project management. Plenty of companies introduce project managers or scrum masters to keep everyone organized and moving in the same direction. I’ve worked with some outstanding people in both roles, but I’ve never been convinced that delivery should be separated from product management. Being a product manager is already a difficult job, but I don’t think that difficulty is a good reason to split accountability across multiple people.

The reality is that product managers are delivery managers whether they want to be or not. They need to know whether engineering is on schedule, whether legal has reviewed the customer agreement, whether marketing is ready for launch, whether customer support has completed training, and whether operations can actually support the product that is about to ship. Even if someone else is responsible for tracking all of those workstreams, the product manager still has to understand them. They still need the information in order to make decisions. Adding another layer between the PM and the rest of the organization often means information arrives later, context gets filtered, and decisions take longer. The PM still owns the outcome, but now someone else owns the status updates.”

Those who have heard me complain about my various incarnations of my various jobs over the last decade will be aware that before this current software engineering phase, I was both a project manager and a product manager (PjM first, PM second.) So I feel fairly qualified to share some unasked-for opinions!

And fractally, I also agree with this take…. To a point. As a PM, you are accountable for the successful delivery of the outcomes you are assigned, and that requires you to both have basic project management skills, and for you to dedicate a portion of your workweek to project management tasks. And in most cases, if a product team is well-staffed and well-scoped, it is a fair expectation that you will be primarily responsible for said project management.

Maybe some places put more of that weight on the Engineering Manager, but I see that as a bit of an anti-pattern for all of the reasons listed above, and for the fact that the EM is also a people manager with people management responsibilities while the PM typically is an IC. So from a pure workload balance perspective I’d rather see the Project Management fall on the IC than risk detracting from the EM’s people management responsibilities.

Also, selfishly for the PM, if you gain your initial Product experience in a place where you aren’t responsible for delivery, that will be a rude awakening if you go somewhere where those skills are required!

But the problem comes from the fact that some projects are harder than others. Some projects are particularly complex, particularly cross-functional, particularly urgent, or particularly important. I do think that most white-collar workers can pick up basic project management skills quickly and without much formal training or experience. And I’ll probably at some point do some post on my project management “philosophy”, such as it is, but TL;DR I do think that successful project management is more about flexibility and detail-oriented…ness and doing what is needed to solve the problems as they arise than it is about formalized and standardized operating procedures and processes. So I am skeptical of “certifications” or “training programs” etc, at least for technical project management at places that operate at the speed consumer or business internet-based software (maybe it’s different for PjMs that like, build aircraft.)

But I do think if you work with a good and experienced PjM, you will see that there are skills and learnings that come with that experience that are non-obvious to someone who hasn’t been doing it full time, and are not a fair expectation for someone who is only doing it as part of their role. I would expect someone who has been a PjM full time for 3 years to be better at project management than someone who was a PM for 10, in the same way I expect the PM to be better at user research and product strategy etc. Those skills come into play when a project gets sufficiently complicated or high-importance/high-visibility. Plus, if a project gets big enough, the actual amount of raw project management time needed to keep it on track can be a full-time job in and of itself!

And so I see PjMs becoming valuable when there are discrete projects that rise to the level where they require more experienced project management skills than is fair to expect of a generalist role like the PM, or where it would require the PM to become effectively a full-time PjM for weeks or months (leading them to both neglect all the other very important parts of their roles in the meantime….. and also most PMs don’t want to be full time PjMs!!!! That’s why they’re PMs instead!!!!!)

And the real killer is cross-functional projects: if this is something that is really important but does not fit the org chart then you’re forced between an awkward choice of:

• Fully distribute ownership of the project across all the relevant teams

• Nominate one team to lead the project, even though they don’t really have ownership over the other teams

• Have some executive that spans all the relevant teams become the day-to-day lead

All of which can work, especially the smaller the company or project is…. but eventually it can reach the point of absurdity (is the CTO now going to lead project status meetings every week?)

Now in contrast, doing things like embedding the PjM or scrum master as a consistent role on an individual product team that also has a PM is likely not very valuable, and like mentioned in the pull quote can lead to weird outcomes from the split responsibility. In the worst case, it makes things slip more because then no one really has responsibility over delivery.

To me then the optimal approach is at small companies, you don’t have Technical PjMs (or at least don’t if you also have PMs.) If as you grow you are finding that things are slipping a lot, especially if that corresponds with cross-functional projects, you should first see if maybe your org is not appropriately designed for the kinds of things you want to be doing and consider a reorg to make these kinds projects single-threaded rather than cross-functional1. That or consider restaffing or retraining PMs and EMs etc in project management.

But once you get to a certain size, it is very likely that there is no org chart that works for everything you need to do. Any design that optimizes for one type of work will hinder another, but both types are necessary. And at that point you probably want to hire PjMs. I would suggest:

1. Staff it as a centralized Project Management Office (PMO), staffed under the CTO or CPO

2. Assign PjMs out to specific projects, and only when it is clear that this is too big/important/urgent/complex for a single team’s PM or EM to manage

3. And you should probably always have too few PjMs rather than have too many

……. spoiler this is basically how it worked when I was a PjM, so I’m probably extremely biased!!

But I think this strikes an appropriate balance, in that:

• You aren’t pulling day-to-day delivery responsibilities away from PMs, helping them stay in the weeds on their direct deliverables (and maintain the delivery muscles needed for the rest of their career)

• But you do have an escape hatch for things that need more

• By making it an independent team it’s easier to keep staffing in line with the actual needs of the business2

• By slightly understaffing, you are keeping pressure on your org chart and not falling into the trap of designing an org in contravention to the actual work you intend to do; if you only have X PjMs, and they can only work on 1-3 projects at a time, then you can only safely do X-3X projects that would need a PjM!

• And as a fun side benefit, you get a PMO team that gets wide experience with the whole Product and Engineering orgs, perhaps even with the whole company, which then further benefits them when working on big cross-functional projects (“Oh you need someone in Y department, yeah I worked with them last year, let me introduce you”)

• And that also will increase the individual PjM’s experiences and skill set by working on a variety of projects with a variety of technical and non-technical teams.

I don’t have enough experience at different sized companies to be able to give a good rule of thumb on like, “only hire after you have a product and engineering org of X people.” And I guess I would shy away from thinking of it that way regardless: you hire PjMs when you have visible problems that PjMs can solve, and for one company that is really well organized that might not be until you have 10 times the employees of a company with a different org chart or different priorities! But, especially the latter two benefits of “team and individuals who get experience with a variety of people and variety of projects” implies a large enough organization that most other people don’t already get that benefit by default. If your team is 40 people, everyone knows anyone anyway.

But anyway, complex; cross-functional; high-visibility; high-urgency. Those should be your clues to consider whether a dedicated execution role like the PjM makes sense.