Software development is an iterative design process. In order to achieve true iteration and realize the value of fast feedback, its activities need to be performed with a single team (having a common reporting line) as far as possible. Many internet business and independent software vendors (ISVs) already operate in this way.

Specialization isn’t the problem; organizing along lines of specialization is.

Organizing by activity gets in the way of lowering batch size of work that is handed-off between teams.

activity-oriented teams are prone to optimize for their own activity and not for the bigger picture of delivering useful software.

In large organizations... The lower tier teams (infrastructure/security) treat the higher tier teams as their (internal) customers in a problem-solving (not scope-delivery) manner.

In product-mode, will we end up with new, business-capability aligned silos such as catalog, order management, payment and fulfillment? Perhaps, but they are nowhere as bad as activity-oriented silos. Product-mode teams, being outcome-oriented, may at worst result in silos that still work towards a business outcome.

While on the topic of utilization, it is important to note that optimizing for utilization is detrimental to reducing end-to-end cycle time. You don’t improve the flow of traffic on a highway by improving its utilization (i.e. introducing more vehicles).