[wpietri]

I think you've mainly missed the point of his article, but let me address the last bit, about non-technical managers.

The way to reconcile his view and yours is to have parallel engineering and product management structures. There are non-technical product managers, but there are no non-technical engineering managers. Every team has engineers and a product manager, but neither reports to the other.

That way you get people dedicated to understanding needs without putting them in charge of things they aren't qualified to understand.

[exelius]

If you have two parallel organizations that interact tightly but have no power over each other, you end up needing a mediator. This usually ends up being project management, or "the process". This is where you get the mixed bag in companies with mediocre talent levels -- usually they don't have anyone who understands the needs of both the engineers and the business. The level of process usually either chokes the engineers' productivity or ends up not giving the business what they need.

Again, it's possible to do, but it takes talent that understand both the business needs and how to manage a development organization (note: this is not the same as knowing how to code.) That's rare to find through a corporate HR process.

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

[wpietri]

I have seen a lot of companies work fine this way, so I disagree.