4 ms·
Except that you're usually building knowledge specific to the organization in which you're working. IMO, you should avoid monopolizing vision and knowledge. I
by pmoleri 7y ago
Except that you're usually building knowledge specific to the organization in which you're working. IMO, you should avoid monopolizing vision and knowledge. I see this as different to the surgical team, where each patient is a different "project".
- asimpletune 7y agoCommunication and knowledge should be considered part of the product. You often times still need these kinds of developers to deliver even this aspect. Basically someone who groks the project so thoroughly that they can synthesize disparate pieces of information into something holistic and absorbable.
- revvx 7y agoBuilding good documentation and sharing knowledge is crucial for such teams to work, according to Brooks. Brooks is all about (good) communication. The "Surgical Team" chapter comes right after the "Communication" chapter in MMM. And I don't think that having other members of the team supporting the vision of the leader is monopolizing the vision... it's just being focused on a single goal.
- Nasrudith 7y agoThere are trade offs to everything - generally I haven't seen the best results from attempts to make people inteechangeable to put it mildly.
- Data_Junkie 7y agoYeah, because at a certain level it's not monopolizing knowledge, it's just not letting people without ability act as though their lack of ability is inconsequential and their agendas matter. In surgery they don't have lack of ability or agendas.