John Daniel Fletcher

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

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

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

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.

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

The difference between a product and project team is essentially about ownership. The difference between a team taking responsibility for an outcome, versus a team just there to deliver a project (output), and then move on to something else.

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.