Leader and manager being different person is quite rare. Mostly because it is unstable setup - the leader will be out of touch, the manager will dethrone the leader. Unless the leader has some additional power.
Also, manager that has not have sufficient power over decisions is just secretary.
In a software development context, the functionality should be specified by analysts, not by the manager. The technical architecture should be specified by an architect, not by a manager. The development process should be steered by the conclusions of retrospectives, not by some management vision.
To be honest, the best places I worked at was where the manager was at the service of the team, relying on all the experts. Never the manager that thought he knew better than everyone else.
Analysts are not leaders by literally any reasonable definition. sometimes they don't even add own vision into the mix, but instead have to fill in somebody elses initial vision with details. Specifying technical architecture is being leader to some limited extend. But it is leading one aspect of the development, that all.
> The development process should be steered by the conclusions of retrospectives, not by some management vision.
Retrospectives are actually run by managers and whether they are useful or not depends primary on the person that is running them.
Then there are things like: setting priorities, negotiating with customers, negotiating with other teams or upper management, deciding what will be promised and what wont. How much of the testing will be done, what is the target quality, final decision on whether to hire or fire people.
Final contract is definitely not done by sales. That would be ridiculous as they have literally zero knowledge over how much the thing should cost and when it could be done. Maybe if you have packed done software where you are selling it without making contracts about future features.
The negotiating is done by manager.
> This is indeed done by a manager, but I don't really see how the "leader" fits into this. It's more of a management function
If you cant do this, you cant lead. Because these negotiations are key to both what resources team will get and to what will be expected from the team. Everyone else then need to fit their visions into whatever was agreed on here and in discussions with customes.
> I hope the manager discusses this with the team, and that it's actually the team telling the manager, and not the other way around.
Discussing with others before making decision does not make you not not lead. But, the idea that discussing with others somehow excludes you from leadership position explains why there is tendency to attribute leadership to less powerful positions that indeed discuss with others less.
Not sure where you worked, but in my last 18 years of experience over some 7 companies, if the team is big enough, there is always dedicated PM and dev lead (and test lead etc.).
Sure its doesn't apply to some 2-man projects but anything sufficiently large requires this division. I've seen control freaks trying to hold many seats on their projects but it never ends well (either heading to burnout or just not being able to tackle it all)
> if the team is big enough, there is always dedicated PM and dev lead
The PM there is leader and manager. The dev/test lead are managers of smaller sub-teams or aspects. But, the actual project leadership belongs to the PM, not to test lead.
Also, manager that has not have sufficient power over decisions is just secretary.