4 ms·

I think I get what you mean now, you're not talking (just) about your typical overgrown software project where somehow 100 people ended up working on it (which

I think I get what you mean now, you're not talking (just) about your typical overgrown software project where somehow 100 people ended up working on it (which always ends a mess, unless you split it into effectively 10 projects), but rather more multi-domain teams that do more than just code that gets reused. That is a much harder problem, I agree. For that one I have no solution since it's not a problem I've tried to solve or seen solved. Perhaps the article sheds some light on this more complex situation but unfortunately it's so drenched in confusing buzzwords that I cannot derive any knowledge from it. Maybe the book is a better source, I'll see if I can get my hands on it.

saberience 4y ago
Yeah, I just realised we might have been arguing based on a misunderstanding of each other's viewpoint! btw, I wouldn't say this book is a silver bullet by any means... it gives some ideas about how you might look at the various situations and think about how they affect comms and collaboration. I've mostly taken insight from the book and the bits they seem to make more sense, adapt them to my own org, and apply that way. I think the best part to take away from the book are the pieces around cognitive load and how it can affect teams adversely if the team has too many "topics" or different major projects, and use that principle to break apart large teams. Then the remaining work is just looking at how those new teams communicate and collaborate in an effective manner.
- DiggyJohnson 4y ago
  Regardless, this was a great conversation to witness and there was value generated by the misunderstanding - if it did occur.