4 ms·

I can think of a few kinds of manager who ought to be culled (mostly upper), but somebody who can give me crystal clear requirements with clear priorities is of

I can think of a few kinds of manager who ought to be culled (mostly upper), but somebody who can give me crystal clear requirements with clear priorities is of immense value to me as a software developer. It takes a massive weight off my shoulders. The alternative is fielding a stream of requests from different people with different agendas and trying to figure out both what their deal is, what the hell it is they are actually after (because most people can't explain their requirements coherently and have to have it teased out) and using subtle social cues to figure out how important their requirement really is so it can be prioritized. I've noticed that PMs who can't do this are pretty common though. It's a job that seems to be filled frequently by unqualified people.

Myrmornis 9y ago
Don’t you find that formulating requirements optimally often benefits hugely from, or requires, technical understanding of what might be possible, and that this understanding is usually absent, by definition, in a PM?
- crdoconnor 9y ago
  It depends on the product, but probably not. If it's a very technical product where the customer is also technical then yes. If it's a user-centric product then I'd much rather they just had domain experience (and maybe UX skills). The best PM I ever had was non technical, had no UX but had significant domain knowledge, and was pretty clear on the limits of his knowledge. The worst PMs I've worked with are the ones that had a little bit of technical knowledge - just enough to be dangerous - and tried to direct the team to implement a half-baked solution where, more often than not, the actual problem they were trying to solve was shrouded in mystery.
  - Myrmornis 9y ago
    Yes, it's that last scenario that I particularly have in mind. PMs are typically led to believe that they should acquire some technical understanding and furthermore that they will be better respected if they do. This leads, as you say, to poorly designed solutions. I'm not personally convinced that requirements-gathering is an inappropriate activity for an IC engineer.
- dragonwriter 9y ago
  Formulating/eliciting requirements is aided by technical knowledge not so much in understanding the potential solution space (though that has some value) as in knowing what questions implementers are likely to need to have answered, so that you can both provide a good starting point (it's still going to be iterative) and avoid doing unnecessary work or overspecifying in a way which constrains implementation inappropriately. But if you have non-differentiated team roles, developers should be doing that, not the PM, and if you differentiate roles, analysts and not the PM should be doing it. Product (or project, either way) Management is a distinct skillet from business/system/domain analysis, and your PM has no more business doing the analysts work than coding. The PM has an oversight role and might ask questions to refine the analytical work product just as they might on a demo of a software product, but they aren't the person who should primarily doing the work.

Myrmornis 9y ago

Don’t you find that formulating requirements optimally often benefits hugely from, or requires, technical understanding of what might be possible, and that this understanding is usually absent, by definition, in a PM?

crdoconnor 9y ago
It depends on the product, but probably not. If it's a very technical product where the customer is also technical then yes. If it's a user-centric product then I'd much rather they just had domain experience (and maybe UX skills). The best PM I ever had was non technical, had no UX but had significant domain knowledge, and was pretty clear on the limits of his knowledge. The worst PMs I've worked with are the ones that had a little bit of technical knowledge - just enough to be dangerous - and tried to direct the team to implement a half-baked solution where, more often than not, the actual problem they were trying to solve was shrouded in mystery.
- Myrmornis 9y ago
  Yes, it's that last scenario that I particularly have in mind. PMs are typically led to believe that they should acquire some technical understanding and furthermore that they will be better respected if they do. This leads, as you say, to poorly designed solutions. I'm not personally convinced that requirements-gathering is an inappropriate activity for an IC engineer.
dragonwriter 9y ago
Formulating/eliciting requirements is aided by technical knowledge not so much in understanding the potential solution space (though that has some value) as in knowing what questions implementers are likely to need to have answered, so that you can both provide a good starting point (it's still going to be iterative) and avoid doing unnecessary work or overspecifying in a way which constrains implementation inappropriately. But if you have non-differentiated team roles, developers should be doing that, not the PM, and if you differentiate roles, analysts and not the PM should be doing it. Product (or project, either way) Management is a distinct skillet from business/system/domain analysis, and your PM has no more business doing the analysts work than coding. The PM has an oversight role and might ask questions to refine the analytical work product just as they might on a demo of a software product, but they aren't the person who should primarily doing the work.