4 ms·

Keep your teams to max 10 people (counting the PO). Allow them to self-organize. Treat each other internal team's project the same way you'd treat an untrusted

Keep your teams to max 10 people (counting the PO). Allow them to self-organize. Treat each other internal team's project the same way you'd treat an untrusted open source dependency. Ignore the article above. Thank me later.

Cthulhu_ 4y ago
How would you coordinate work across teams?
- sirwhinesalot 4y ago
  The same way you "coordinate" work across your open source dependencies, you post an issue in their issue tracker. As far as those other teams are concerned, you are their customer, and they need to prioritize their work as usual. If a team is consistently ignoring the issues posted by another and causing issues in the overall project, that's up to higher management to resolve and reprioritize things. Higher-management needs to collaborate and prioritize issues across teams, as their "own" team, since they should have a higher level overview of the project. To make it a bit more concrete, lets say you have 10 teams of 10 people, each managed by a manager. Each of those teams is an independent "project". The 10 managers themselves form a team that has to ensure those independent projects form a coherent whole by organizing amongst themselves and prioritizing tasks across teams accordingly. EDIT: this split can work (albeit poorly) at up to 3 levels deep, so ~1000 employees total on a "big project". If you can't make do with that many, you're screwing up somewhere, but 100 should be enough IMO.
  - djKianoosh 4y ago
    in an organization that large, the 10 managers in your scenario would have to be some of the most selfless and honest humans, all able to communicate freely and openly without envy or ulterior motives.
    - sirwhinesalot 4y ago
      In most companies those 10 managers are not a team, unfortunately. It's more like there's a "top" manager who has 10 separate sub managers of 10 teams. But those sub managers are mostly independent. At least that's how it is in most places, communication between middle managers goes up and down, not sideways. What I'm talking about is different, it's not just 10 managers that "have to talk", it's 10 managers in the same team with the same goal. They just happen to each coordinate another 10 person team. I haven't really seen that done anywhere, but I've seen some chair shuffling that approximated it. Would love to see it taken to the logical conclusion.
      - darkerside 4y ago
        This is a basic tenet of the book 5 Dysfunctions of a Team
  - asplake 4y ago
    > The same way you "coordinate" work across your open source dependencies, you post an issue in their issue tracker Please let’s not confuse the record of a conversation with the conversation itself. I’ve seen tracking tools used in this way and it easily turns dysfunctional.
    - sirwhinesalot 4y ago
      Good point. Though I am suggesting a flip of the typical approach here. Rather than you first having a meeting, and then registering the task in the issue tracker, I'm suggesting the opposite. An issue is posted in the tracker, which may or may not trigger a meeting depending on severity or if more information is needed. The issue tracker is a starting point for discussion, rather than the end.
saberience 4y ago
Written by someone who's never worked for a large enterprise software company. You cannot apply simply blanket rules like this and expect them to fit every situation. Also, allowing all teams to simply "self organize" pre-supposes that these teams will make smart decisions in their organization, something in my experience which is anything but guaranteed. Team A strongly depends on Team B's product to the point where their deliverables are impacted by Team B's, how do we collaborate in this case? Team B depends on Team C's internal platform, how does this teams collaboration differ from Team A and Team B's situation? Team D has a sub-team working on a highly complex sub-system (real-time ledger for example), this sub-team is growing, how should Team D interact and work with this sub-team? Team E needs help from the SRE team with reliability and observability issues, how should these teams best work together and collaborate? My point is, in all these situations, how these teams interact and collaborate will be subtly different based on the situation at hand. A "one size fits all" method of team dynamics simply won't work optimally in every situation. This is what books like Team Topologies are trying to help with.
- sirwhinesalot 4y ago
  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?
xzv 4y ago
Sounds like a recipe for getting a toxic Amazonian culture
- sirwhinesalot 4y ago
  I have no idea what Amazon's software development culture is like, only that they treat their warehouse employees like shit.

Cthulhu_ 4y ago

How would you coordinate work across teams?

sirwhinesalot 4y ago
The same way you "coordinate" work across your open source dependencies, you post an issue in their issue tracker. As far as those other teams are concerned, you are their customer, and they need to prioritize their work as usual. If a team is consistently ignoring the issues posted by another and causing issues in the overall project, that's up to higher management to resolve and reprioritize things. Higher-management needs to collaborate and prioritize issues across teams, as their "own" team, since they should have a higher level overview of the project. To make it a bit more concrete, lets say you have 10 teams of 10 people, each managed by a manager. Each of those teams is an independent "project". The 10 managers themselves form a team that has to ensure those independent projects form a coherent whole by organizing amongst themselves and prioritizing tasks across teams accordingly. EDIT: this split can work (albeit poorly) at up to 3 levels deep, so ~1000 employees total on a "big project". If you can't make do with that many, you're screwing up somewhere, but 100 should be enough IMO.
- djKianoosh 4y ago
  in an organization that large, the 10 managers in your scenario would have to be some of the most selfless and honest humans, all able to communicate freely and openly without envy or ulterior motives.
  - sirwhinesalot 4y ago
    In most companies those 10 managers are not a team, unfortunately. It's more like there's a "top" manager who has 10 separate sub managers of 10 teams. But those sub managers are mostly independent. At least that's how it is in most places, communication between middle managers goes up and down, not sideways. What I'm talking about is different, it's not just 10 managers that "have to talk", it's 10 managers in the same team with the same goal. They just happen to each coordinate another 10 person team. I haven't really seen that done anywhere, but I've seen some chair shuffling that approximated it. Would love to see it taken to the logical conclusion.
    - darkerside 4y ago
      This is a basic tenet of the book 5 Dysfunctions of a Team
- asplake 4y ago
  > The same way you "coordinate" work across your open source dependencies, you post an issue in their issue tracker Please let’s not confuse the record of a conversation with the conversation itself. I’ve seen tracking tools used in this way and it easily turns dysfunctional.
  - sirwhinesalot 4y ago
    Good point. Though I am suggesting a flip of the typical approach here. Rather than you first having a meeting, and then registering the task in the issue tracker, I'm suggesting the opposite. An issue is posted in the tracker, which may or may not trigger a meeting depending on severity or if more information is needed. The issue tracker is a starting point for discussion, rather than the end.

saberience 4y ago

Written by someone who's never worked for a large enterprise software company. You cannot apply simply blanket rules like this and expect them to fit every situation. Also, allowing all teams to simply "self organize" pre-supposes that these teams will make smart decisions in their organization, something in my experience which is anything but guaranteed. Team A strongly depends on Team B's product to the point where their deliverables are impacted by Team B's, how do we collaborate in this case? Team B depends on Team C's internal platform, how does this teams collaboration differ from Team A and Team B's situation? Team D has a sub-team working on a highly complex sub-system (real-time ledger for example), this sub-team is growing, how should Team D interact and work with this sub-team? Team E needs help from the SRE team with reliability and observability issues, how should these teams best work together and collaborate? My point is, in all these situations, how these teams interact and collaborate will be subtly different based on the situation at hand. A "one size fits all" method of team dynamics simply won't work optimally in every situation. This is what books like Team Topologies are trying to help with.

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

xzv 4y ago

Sounds like a recipe for getting a toxic Amazonian culture

sirwhinesalot 4y ago
I have no idea what Amazon's software development culture is like, only that they treat their warehouse employees like shit.