John Daniel Fletcher

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

[Startups loose this in scale up when] the leaders instead try to scale by staffing and directing project and feature teams, not realizing they are losing the most important ingredient from their earlier years.

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

The signs of project teams are plain to see: teams of mercenaries (order takers), slow velocity, little to no innovation, ballooning technical debt, no ownership of results, orphaned projects and blame directed everywhere.

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

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.

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.