4 ms·

You provided a lot of questions and no real answers. I already gave the answer: issue tracker, higher management prioritizes. For absolutely critical must do no

You provided a lot of questions and no real answers. I already gave the answer: issue tracker, higher management prioritizes. For absolutely critical must do now changes, you ask for a direct line of communication, but only in that absolute immediate state where something is on fire. A similar question arises from a team that depends on Qt for their GUI. How does a team solve any issues it might have coming from Qt? If you can answer that question, do the same internally. If you are in a situation that does not work like this, you don't really have 2 teams, you have 1 dysfunctional team and no amount of buzzwords will help you. EDIT: Also I work for a large enterprise company where these issues were identified :). If you have two teams, you have two projects, period, or you have 1 highly dysfunctional team. I've seen all the issues with Team A not being able to deliver because they depend on Team B which has 6 month release schedule. The problem here is one of expectations. Team A should not be expected to deliver things that depend on things Team B has not yet delivered. How stupid is that even? The solution is to not ask for stupid things or realize that you're being stupid and adjust. "Hey higher management, we can't release because these guys have 6 month releases and we need their partial results now". Maybe higher management should listen?

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

saberience 4y ago

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.