For that reason try to structure teams such that every team has everything it needs for its day to day work.
I would extend that to “have as much control as you can over what you do”. I increasingly find that this is key to move fast and produce quality software.
This applies to code and means dependencies should be owned and open to modifications, so the team understands them well and can fix bugs or add features as needed.
This avoids ridiculous situations where bugs are never fixed or shipping very simple features (such as changing a theme for a UI component) is impossible or takes weeks because a framework actively prevents it.
More control and understanding also tends to be better for satisfaction. Of course all this is on a spectrum and should be balanced with other requirements.
I would extend that to “have as much control as you can over what you do”. I increasingly find that this is key to move fast and produce quality software.
This applies to code and means dependencies should be owned and open to modifications, so the team understands them well and can fix bugs or add features as needed.
This avoids ridiculous situations where bugs are never fixed or shipping very simple features (such as changing a theme for a UI component) is impossible or takes weeks because a framework actively prevents it.
More control and understanding also tends to be better for satisfaction. Of course all this is on a spectrum and should be balanced with other requirements.