John Daniel Fletcher

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.

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.

More generally, one of the things we learned many years ago is that success does not come from projects, but rather from continuously working and iterating on an area until we achieve the necessary outcomes.

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.

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.

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