4 ms·

I've started seeing this pattern as well, and it really has me wondering. If you have a team of relative newbies, they learn from trial-by-fire and grow really

I've started seeing this pattern as well, and it really has me wondering. If you have a team of relative newbies, they learn from trial-by-fire and grow really fast. I guess it's up to you if you have the time/bandwidth/runway for this process. It's really messy, but 1 or 2 years of this gets you a programmer who is able to talk to customers, able to coordinate among their peers, take feedback, self-manage etc. (or the programmer gets frustrated and quits) I'm old, so I think it's better to have a PM doing coordination so the programmers can focus on good, clean, scalable code. But, maybe the definition of 'programmer' is changing. Maybe all the above skills are also required to be a 'programmer' nowadays, and the frustrated ones who quit are something else. Code specialists? I really don't know... I'm heavily biased against it but I'm very interested in what others have experienced with this flat PM-free structure.

jamil7 7y ago
> I'm very interested in what others have experienced with this flat PM-free structure Anecdotally I've experienced it for the most part not working, especially when you have a lot of juniors to coordinate. I have however once in my career been lucky enough to work on an extremely small (4 developers) but also very experienced team that was able to self coordinate and move very quickly without any PM or overly complex structure in place.
lmm 7y ago
One thing that's really come through with Agile is how little value traditional project planning actually brings to real-world software development. You can do any amount of estimation, forecasting, scheduling... but actually the only question that's worth getting a useful answer to is "what should I work on this week?", and the amount of work you have to do to figure that one out is much smaller. What you do need is someone who can understand the priorities that different stakeholders (including engineering) have, weigh those up, and come up with overall priorities for engineering to execute on; that's an extremely valuable role, but probably not to the extent of being a full-time position for someone who contributes nothing else. The other side is that it's very difficult to evaluate a coordinator's performance, as an outstanding team poorly coordinated will look much the same as a poor team outstandingly coordinated. As an engineer, if I see a non-technical PM then there's a significant chance that they're contributing nothing but bullshit, and presumably someone from the business side would be equally skeptical of a PM with no business experience.

jamil7 7y ago

> I'm very interested in what others have experienced with this flat PM-free structure Anecdotally I've experienced it for the most part not working, especially when you have a lot of juniors to coordinate. I have however once in my career been lucky enough to work on an extremely small (4 developers) but also very experienced team that was able to self coordinate and move very quickly without any PM or overly complex structure in place.

lmm 7y ago

One thing that's really come through with Agile is how little value traditional project planning actually brings to real-world software development. You can do any amount of estimation, forecasting, scheduling... but actually the only question that's worth getting a useful answer to is "what should I work on this week?", and the amount of work you have to do to figure that one out is much smaller. What you do need is someone who can understand the priorities that different stakeholders (including engineering) have, weigh those up, and come up with overall priorities for engineering to execute on; that's an extremely valuable role, but probably not to the extent of being a full-time position for someone who contributes nothing else. The other side is that it's very difficult to evaluate a coordinator's performance, as an outstanding team poorly coordinated will look much the same as a poor team outstandingly coordinated. As an engineer, if I see a non-technical PM then there's a significant chance that they're contributing nothing but bullshit, and presumably someone from the business side would be equally skeptical of a PM with no business experience.