Re:Developers can't fix bad management (2020)
by JMTQp8lwXL on Thursday June 10, 2021 @09:02AM
(#27460186)
Too much autonomy is too much of a good thing. You end up with 5 "send a email" microservices, multiple design systems, etc. People won't bother to look outside of there team's scope to see if anyone else in the company has solved a similar problem. Or without a culture of external contributions, people will make their own versions of things that are 90% identical to an existing team's service.
[ Parent
| on HN ]
Re:Developers can't fix bad management (2020)
by sidlls on Thursday June 10, 2021 @10:04AM
(#27460902)
This describes the org I’m in right now. The upper management (all former engineers, several ex-FAANG) are not only supportive but have explicitly reaffirmed that duplication of that sort doesn’t matter: every team must be as autonomous as possible even if it leads to a high degree of overlap.
And it’s already biting us. There are at least two issues I’m aware of that are a direct result of this policy which are very bad. When they come to light the company’s reputation (and share price) will very likely be harmed.
Re:Developers can't fix bad management (2020)
by haswell on Thursday June 10, 2021 @08:24PM
(#27467816)
Too much autonomy can be too much of a good thing, but this is not universal, and when it turns out to be a bad thing, that says more about the group who has been given the autonomy than it does about autonomy itself.
A sibling comment talks about trust/skill, and these are factors that are more important than just focusing on autonomy as a stand-alone concept.
Open Source projects show both ends of this spectrum, with absolute autonomy yielding both amazing and mediocre results.