3 ms·

I provided a lot of questions which you couldn't answer effectively, that's exactly my point ;) Your "just let teams self-organize" is frankly too simplistic t

I provided a lot of questions which you couldn't answer effectively, that's exactly my point ;) Your "just let teams self-organize" is frankly too simplistic to cover the real-world complex environment of different team structures and roles. How a data platform team works with stream-aligned teams is highly different from say how an enabling team, like a centrally reporting SRE team, works with stream-aligned teams. Or how a complex subsystem team (complex ml model) works with one specific team vs a team building something like "batch processing cluster self-serve/as-a-service" which can be used self serve via many teams. Every situation requires different levels of communication, forms of communication, e.g. do you occasionally embed engineers in another team? Do you do some comms "in person"/sync versus all comms are async via Github Issues etc. Does the other team bring people to your standups or other similar meetings. I would 100% that for certain combinations of teams, having people from one team embed in another team is massively, massively helpful, in other situations it sucks! For some teams, only relying on an API and async updates surrounding that API (requests to the api) is all the collaboration that is needed. My point is that there is no "one size fits all situations" model here. And as someone with a lot of real-world experience in building teams and now running large Engineering orgs myself, I've seen this done well and badly many times.

sirwhinesalot 4y ago
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.

sirwhinesalot 4y ago

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.