[bunderbunder]

I work in an team that's organized the way the parent describes, and there's no mediator needed. The engineering managers and product managers have a good working relationship and collaborate closely, so they usually have no problem reaching consensuses that work for everyone. The close collaboration means that each side is aware of (and can usually anticipate) the other side's needs and limitations, but the division of responsibilities ensures that the number of balls getting dropped is minimized.

The relationship most certainly does not need a mediator. Sticking a mediator in there would probably end up destroying the arrangement. If the two camps can't work together without one, a better solution is to figure out who it is that doesn't know how to play well with others and get them replaced.

[exelius]

I'm not saying it can't work that way -- just that it often doesn't if you don't have good people. Also, even if you have good people, when the product group is more or less a single silo and you have a dozen different engineering teams working on various modules of a product, communications get lost and balls get dropped and you need some sort of communication process that ensures at a bare minimum accountability (which usually ends up at Agile).

I know a lot of people would say "Well just hire better people," but that's often not realistic. It takes time to hire people, corporate HR processes are terrible at differentiating good developers from mediocre ones. In the time it takes you to hire people, you still need to ship product.

[bunderbunder]

Hum. Well I would say that if the product group is a monolithic silo interacting with a dozen engineering teams, that does sound like a recipe for trouble. The system I'm thinking of involves having at least one member of the product team for every engineering team.

That actually edges back toward my one serious complaint about Agile development: On the teams I've worked with, there's a bit too much value placed on generalism over specialism in team members' skill sets. Anything that's everybody's responsibility is effectively nobody's responsibility.

[exelius]

Yeah; a lot of the solutions you see pushed here on HN don't really scale past a startup-sized company. A lot of times if you have a very large product, you have multiple engineering teams working on a layered architecture. For example, the product guys will hand off a requirement as a user story that describes "As a customer, I can push the green button and it orders a pizza sent directly to my desk." That user story involves the front-end team (UI mockups, interface implementation, etc.), the back-end team (now has to support storing and retrieving the user's pizza preferences), the billing systems team (now has to ensure the pizza billing process has the proper audit checks, etc. on it), the deployment team (who now has to ensure pizza-order messages are allowed through the firewall to the pizzeria), etc.

It's a bit of a contrived example, but you get the idea. Unless you have a centralized management function, all of this doesn't happen and your glorious pizza button either doesn't work or fails deployment. Usually the onus falls on the product manager to do this, but with so many teams involved it can be a nightmare.

[wpietri]

The problem with the approach you describe is the notion of a "front-end team". In my view, that's not a team.

In the kind of organization I describe, teams have business purposes and are cross functional. So in your example, there'd be a pizza-direct-to-desk team. In that case, you don't need centralized management of everything.

Plenty of organizations work this way. Spotify, which has done a number of talks on their organization, works just fine with cross-functional teams focused on individual purposes. I interviewed some team members at YouTube, and they had a similar structure.