3 ms·

And what should a PM do when their engineers are not effective at shipping?

Clubber 5y ago
I really depends on why they're having trouble shipping, so that should be the first task: find out why. The first thing to try most of the time is to create well written tasks that can be completed in less than a couple of days, preferably a day. This is an attempt to solve these issues: - Tasks that are too vague. - Developers that get stuck in the weeds. - Developers that aren't that great. - Identifying where the friction is.
- cudgy 5y ago
  Good point that it depends. What if reason developers aren’t “shipping” is due to project scope and/or lack of resources (e.g. number of developer hours and/or expertise level of developers)? From my experience, this is the most likely issue. Difficult for developers to resolve that by increasing the granularity of tasks.
  - Clubber 5y ago
    >What if reason developers aren’t “shipping” is due to project scope and/or lack of resources (e.g. number of developer hours and/or expertise level of developers)? From my experience, this is the most likely issue. Difficult for developers to resolve that by increasing the granularity of tasks. >due to project scope and/or lack of resources The product scope will at least be clearer with well written tasks. If it's a scope thing, then it will force the biz to be precise in what they want, lowering the back and forth between dev and the pm and biz. If it's a lack of resource thing, the biz needs to learn to prioritize and come to the realization that they want way more than they have the manpower to produce. Once this becomes evident, it will get bounced to a higher level. >number of developer hours and/or expertise level of developers These are two different things. The first is a resource availability problem and was addressed (see above). The second is a resource ability problem. This is where the smaller tasks come in. "Build a queueing system with grids that sort and search" is a lot bigger than "Create these tables," "Create this grid," "Add sorting," "Add searching." It's the divide and conquer strategy. A lower ability developer might get stuck understanding the task as a whole, but if you break it up into bite sized chunks, they might be able to accomplish each individually, or at least show better progress on some of them. You also have to understand, you might have someone who isn't up to the task for a particular subset of skills (say database design, backend design, or UI design, etc). This will at least show you where your devs have holes in their ability/toolset. You can then decide to train them up, or just put a different developer who has that skillset on that particular task, or replace some of them. Say you have one developer that is good at database modeling and backend and one dev that is good at UI. That's easy. Have the first do the backend / db modeling stuff and the second do the UI stuff. This allows devs to do what they are good at and ship times should improve.
- beckingz 5y ago
  Agreed that getting more specific with tasks is helpful. Unfortunately, it's hard to leave the engineering approach for larger projects to the developers when their productivity (and apparent satisfaction) increases significantly with task specificity. Maybe this just indicates an issue with developer experience/seniority.
booleandilemma 5y ago
Make smaller and smaller goals until they can ship.
thenerdhead 5y ago
Plan an intervention with the EM or find another job if they are competent themselves.
KnobbleMcKnees 5y ago
It's possible all the engineers are bad at being engineers. What do you think the other possibilities are?

I really depends on why they're having trouble shipping, so that should be the first task: find out why. The first thing to try most of the time is to create well written tasks that can be completed in less than a couple of days, preferably a day. This is an attempt to solve these issues: - Tasks that are too vague. - Developers that get stuck in the weeds. - Developers that aren't that great. - Identifying where the friction is.

cudgy 5y ago
Good point that it depends. What if reason developers aren’t “shipping” is due to project scope and/or lack of resources (e.g. number of developer hours and/or expertise level of developers)? From my experience, this is the most likely issue. Difficult for developers to resolve that by increasing the granularity of tasks.
- Clubber 5y ago
  >What if reason developers aren’t “shipping” is due to project scope and/or lack of resources (e.g. number of developer hours and/or expertise level of developers)? From my experience, this is the most likely issue. Difficult for developers to resolve that by increasing the granularity of tasks. >due to project scope and/or lack of resources The product scope will at least be clearer with well written tasks. If it's a scope thing, then it will force the biz to be precise in what they want, lowering the back and forth between dev and the pm and biz. If it's a lack of resource thing, the biz needs to learn to prioritize and come to the realization that they want way more than they have the manpower to produce. Once this becomes evident, it will get bounced to a higher level. >number of developer hours and/or expertise level of developers These are two different things. The first is a resource availability problem and was addressed (see above). The second is a resource ability problem. This is where the smaller tasks come in. "Build a queueing system with grids that sort and search" is a lot bigger than "Create these tables," "Create this grid," "Add sorting," "Add searching." It's the divide and conquer strategy. A lower ability developer might get stuck understanding the task as a whole, but if you break it up into bite sized chunks, they might be able to accomplish each individually, or at least show better progress on some of them. You also have to understand, you might have someone who isn't up to the task for a particular subset of skills (say database design, backend design, or UI design, etc). This will at least show you where your devs have holes in their ability/toolset. You can then decide to train them up, or just put a different developer who has that skillset on that particular task, or replace some of them. Say you have one developer that is good at database modeling and backend and one dev that is good at UI. That's easy. Have the first do the backend / db modeling stuff and the second do the UI stuff. This allows devs to do what they are good at and ship times should improve.
beckingz 5y ago
Agreed that getting more specific with tasks is helpful. Unfortunately, it's hard to leave the engineering approach for larger projects to the developers when their productivity (and apparent satisfaction) increases significantly with task specificity. Maybe this just indicates an issue with developer experience/seniority.

booleandilemma 5y ago

Make smaller and smaller goals until they can ship.

thenerdhead 5y ago

Plan an intervention with the EM or find another job if they are competent themselves.

KnobbleMcKnees 5y ago

It's possible all the engineers are bad at being engineers. What do you think the other possibilities are?