Are you managed by project manager?

[29_29]

I've noticed a trend in tech where the Project Manager's role keeps expanding. It feels like its reached a tipping point where they are actually calling shots technical. They are making decisions an Engineering manager should otherwise make. Have you noticed this trend? How do you manage your project manager? What does this role do at your company? Should we get rid of this role?

[pxc]

My PM basically just helps my team to present our progress to higher management and outside teams. So she schedules meetings, solicits my input on status reports, asks for rough time estimates, checks in when she thinks I've forgotten to mark a task as completed or should split out a ticket, etc. She attends all of our stand-ups, so she always knows what I'm working on, and on my small team that means that we get to make very light use of Jira and communicate most day-to-day progress in threaded, private group chats. She's not technical in terms of training or background, but she often asks good questions to make sure she understands the technical basics of architectural and strategic decisions.

At my job, the PMs seem to do a lot of bookkeeping, cat herding, and politicking that are not generally easy or pleasant for me. I'm glad they're around to take care of that stuff.

I'll add as well that my engineering manager doesn't often have to 'call shots', either— thinking through a problem together, arguing, making requests of one another, etc., is usually enough to settle things.

[jph]

You're asking a good question. Here's what I see in practice: project management is getting bigger and faster, driven by more stakeholders having more access to work-in-progress.

For example, my client's CEO is checking the project board daily, and asking the project manager "Can we ship feature X this week?". The project board is well-maintained and well-detailed, such that the CEO can actually see and understand dependencies, resources, and timelines, and the PM can actually move tasks and have it stick. This is for a company where everyone's on board with rapid changes and continuous delivery i.e. not waterfall, not scrum, not sprints.

This way of working can be excellent for higher-velocity higher-trust agile teams. The engineering manager and team can feed the board with options including cost/time/resource tradeoffs, and can have ongoing high-touch communications with the PM, then the CEO & PM are empowered to pick-and-choose features as they wish.

However, this way of working can be terrible for slower-velocity lower-trust teams. When an engineering manager and team aren't feeding the board with enough detail about tradeoffs, or when there's insufficient communications among the PM and others, then the CEO & PM won't have enough information to lead, and the outcome can feel like the PM is trying to do the job of the engineering manager and messing about with the engineering work.

The best approach IMHO is lots of communication about the company's goals, such as for the ways of working, the roles and responsibilities, and the projects and plans.