I seen good project management. It is magical. Then the manager left. Everything slowed down to a crawl.
Making sure "the right people are talking", "decisions are made", etc. do sound like things that can be tracked to confirm if a PM is indeed adding value.
At some point in time recurring wins can look like a perpetual machine. The problem is when you get there, people think like, Now that we got what we want why do we need this person?
It's only after the person goes and a few months down the lane you begin to see things falling apart. Of course by then things just become the new normal.
> If you can't quantify the value you're adding to an organization, are you adding any at all?
But there should be something that can be measured, even if it's imprecise, to at least show that something's being done. How do you measure the success criteria for the role of a PM? It's challenging. But it should be done.
There's nothing wrong with that. It's just the nature of such roles.
You still evaluate, you just don't boil it down to one "score".
Similarly a good manager provides auxiliary value; it doesn't directly add value to the organization but if it's not there then the overall value decreases.
Not everything in an organization is immediate positive effect.
One of the teams I oversee now in NA also has a brilliant project manager. Of all my 12 years in the industry I haven't once seen someone pull a team into productivity nirvana like she does. She deeply understands the concept of agile and every sprint she is trying a new idea with her team (process is a feature!).
They do exist, but they are rare.
To do so, they must see themselves as a peer. Anyone with an ego who wants to boss people around will be a terrible PM. A good PM enables their team and is altruistically driven.
Once you work with someone like this, you'll understand how amazing PMs can be.
Besides, there are still politics to shield from, budgets to maintain, stakeholders to brief, paperwork to do - all stuff that putting an engineer on - would be an utter waste.
One of the biggest problems I've seen on agile projects is a lack of analysis. Often "agile" development processes are chosen because people want to avoid analysis. I think the thinking is that if you remove all the documentation and discussion around what you are building, the developers will just "do the right thing" and you'll save a whack of time.
In fact, on the XP teams I've run, I tend to have 2-3 month backlogs of stories. You want to think through what you are building and what the implications are. There are 2 main differences between this and a more analysis-up-front approach. First, your stories are changeable and prone to re-ordering. Second, you defer some decisions until later. There is no phase when the requirements are carved into stone. However, if you get to the beginning of the sprint and you don't know what the acceptance criteria for all of the stories in the sprint are, then you are in big trouble.
Also, I come from the ancient days. I've personally written a 1300 page requirements document. That took 6 months to write. That was largely ignored. When I tell people that I want a couple of months out of "this is what we're doing if nothing changes", these days people think I've got all top heavy on them. Times change...
This is where a good project/product manager comes in handy. You need someone who owns the overall vision of what you are building and has time to think through the implications. You need someone who is constantly grooming the backlog and updating the cards as the vision changes. You need someone who understands the business priorities and knows when and how to reprioritise the backlog. You need someone who is constantly asking the question, "It's fine to do X, but what does that mean for Y", or "What makes you think that this is the solution we need" or "Who is going to be affected when we do X".
Often product/project managers think, "Oh I don't have to know how the product works in detail". This is a huge red flag for me. They often think "Oh the programmers can decide what to do here". Yes, the programmers can, but they already have their plate full with how to do what needs to get done. If you ask them to think through all the details of what and why then they will have less time for how. Similarly, if you have a team of 6-8 developers, then you will have 6-8 opinions about what the best thing to do is. The vision will potentially be weakened and you will often find that the programmers spend half their time arguing about who has the best idea. At best you'll have 1 developer doing the product/project manager's job and the rest will be doing programming jobs.
I could go on forever here. I haven't even touched on dealing with internal politics, reporting, ensuring visibility of problems, coordination with other groups, gathering data, etc, etc, etc. If you don't have someone doing these things then they are often not getting done at all (often to your detriment) or you are wasting your precious programming horse power dealing with the realities of business.
As you can imagine, I over the years I've regularly butted heads with "I don't really want to do anything at all" product/project managers. But if I get someone willing and able, I will absolutely load them down with work that has the potential to make a massive difference to everyone.
First lead developer. To me a lead developer is the person on a team that leads the technical direction of the team. Programming is all about judgement calls and long term success on the technical side depends on getting those judgement calls right more often than wrong. Some lead developers like to make all technical decisions, but this can create a bottle neck and also piss off the rest of the team. For those reasons, I don't like that approach and prefer to have the lead developer act as a technical coach, leading by example. The lead developer should have the final say on technical decisions and should be aware of all of the decisions being made on the team, but they should avoid making decisions if they can. On political matters, they should refrain from being too active, but rather defer to the development/engineering manager if there are any problems. Lead developers should also write a lot of code IMHO.
The sound clip is, though, the lead developer should be a 10x developer by virtue of doubling everybody else's productivity. However they do that is fine.
I tend to use the term "development manager" rather than "engineering manager" for arbitrary reasons, but they mean the same to me. A development manager ideally should make no technical decisions. That should be left to the lead developer. In some organisations, the team is not deep enough to have an effective lead developer, so sometimes the development manager has to take on that role too. In other organisations, there is no development manager and so the lead developer has to take on that role. It's not optimal, but it really depends on the size and depth of the organisation.
A development manager's responsibility is political in nature. First they must evaluate and track the progress of the members of the team (usually working closely with the lead developer to get insight). They will ideally decide on the head count of the team, choose the members of the team, organise hiring if necessary and arranging for movement out of the team (whether that is a transfer or dismissal) if necessary. The development manager is responsible for the conduct of the team. If there are behavior problems, the development manager must find a solution (usually working with the lead developer) to those problems. The development manager is responsible for tracking performance of developers, negotiating raises, managing career progression, finding appropriate training, allocating resources (for example computers, desks, chairs, internet), etc. They are also responsible for ensuring that outside problems are dealt with effectively. A big part of that is making decisions about how to deal with external requests for development, allocating people to deal with problems, etc, etc. They must work with the project manager(s) to track performance and ensure that there are adequate people available to do the work that is necessary. The must work together to track work completion and adjust expectations for delivery dates, etc.
Where the lead developer is looking at the tactical view about how to best accomplish a series of tasks, the development manager is looking at the strategic view of plotting the current location and direction of the team (as well as dealing with the people problems and political fall out from that).
I wrote earlier about what I see the project/product manager doing, so I won't get into it too much, however I'll talk a little bit more about the communication/politics role the product/project manager needs to do. Unless the company is small, there are usually a lot of other departments, many of which dwarf the IT group. These groups include (but are not limited to) marketing, sales, documentation, customer service, etc. In some organisation you even have a separate IT group from development usually called "services" that does custom development for large customers. The project manager has to coordinate all of these groups. This is a big job. They need to listen to all of these groups to gather requirements. They need to coordinate with marketing and sales to keep them synchronised for timing. They have to constantly update everybody as business needs and requirements change. They need to make sure that marketing aren't putting together a campaign for something that you aren't building. They need to stop sales from selling things that you don't have. They need to coordinate the development of documentation. In some industries they need to arrange for and plan certification. I could literally type for pages on this kind of thing. You need at least one person dedicated to this job for each project in most large companies.
The main difference between a project/product manager and a development manager is that one if focused on the project/product and one is focused on the performance of the team. You can merge these roles in a small company, but there are desirable separations of concerns in these roles. Especially (and it's a bit hard to say this politely), there is plenty of latitude for abuse if both of these roles is performed by the same person.
You will notice that I haven't answered your first question. I don't make a distinction between project and product managers. However, many people do. I think the best way to look at the situation, though, is that you almost always need someone who is responsible for the artefact that you are building. They "own" the requirements for that thing. I will say that just like the lead developer position, I prefer a technique where as "owner" you don't actually make all the decisions. Instead you are aware of all the decisions and you make the final decision when there are problems. It's the ownership of the responsibility, really, rather than the ownership of each individual choice. Otherwise you get into the same position of becoming a bottle neck, or pissing off the rest of the team who has to pay for your mistakes, even though they have no say in the matter. It's a hard job, though, because you really have to travel around talking to people all day and make sure that you understand every decision being made.
On the other hand, just like there is a separation of tactical and strategic goals in development, you can do the same in the project management side. So you can have a project/product "owner" and a project/project manager, who may be responsible for the strategic view of how all these tings are fitting together. In a very large company, you almost certainly need this role. Most of my career has been spent in organisations with less than 200 developers and in those organisations, I've never really seen the need. YMMV.
Edited to fit into a reply (apparently I typed too much).