> Whether to fix a long-standing, apparently undetected bug is for a Product Manager to decide, not an engineer. If our users have already worked around the problem without telling us, then fixing it on our end may actually cause them problems. At the least, roll-out should be carefully coordinated.)
this is troubling to me. i want to empower my engineers to make big decisions. i understand team size, context matters, but, generally...
but that change happened (in many contexts) a while ago; many devs wanted to upskill into the biz while also exploring other options. progression is important and i see some of this as part of progression.
> Whether to fix a long-standing, apparently undetected bug is for a Product Manager to decide, not an engineer. If our users have already worked around the problem without telling us, then fixing it on our end may actually cause them problems. At the least, roll-out should be carefully coordinated.)
this is troubling to me. i want to empower my engineers to make big decisions. i understand team size, context matters, but, generally...
That's certainly a valid approach. I think it puts the onus on you, though, to ensure that your engineers are qualified to make product decisions.
In effect, they're not just engineers anymore.
but that change happened (in many contexts) a while ago; many devs wanted to upskill into the biz while also exploring other options. progression is important and i see some of this as part of progression.