Comment by sirwhinesalot | Hacker News Reader

Comment by sirwhinesalot | Hacker News Reader

Parent Full thread

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.

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.

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.

This is a basic tenet of the book 5 Dysfunctions of a Team

> 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.

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.

Reply on news.ycombinator.com