To launch your small domain-aligned, self-organised team (aka speed boat) the first things we need are Products over Projects.

Projects are a popular way of funding and organising change. They organise work into temporary teams and are funded with a business case projecting specific benefits. They are staffed from a “pool of talent” whose members are considered fungible within a line of specialisation.

How sad then, to observe organisations performing “Teamicide” on the teams they have spent so much time and money developing.

These teams are sliced up and discarded, not because the type of work the team is capable of is no longer needed, but because the project has simply come to an end.
The project vehicle can be helpful for getting one-off things done when you are in a completely known problem and fully known solution space. However, if we are in a more complex and only partially known problem and explorative solution space, and the business is changing quickly, then wrapping that up in a project vehicle leads you to focus on the wrong things.

An ideal product-mode team is empowered, outcome-oriented, business-capability aligned, long-lived and cross-functional. These ideate-build-run teams are expected to solve problems and improve business outcomes, rather than deliver scope on schedule. The problems that these teams work on are usually long-lived e.g. continuously improve the conversion from cart to checkout (reduce cart abandonment rate). Problems also need to be sufficiently narrowly defined so that individual teams can own them.

These ‘Product’ teams need to own the features of the product but also the raw and processed data.

It’s normal for a Product team to take pride in their features. The paradigm of ‘Product’ teams that I am talking about also take pride in their ‘Data Products’.
So, a common question I’m often asked by CXOs is, “What is a ‘product”’? The answer depends on the context of the organisation since a Product could be a manifestation of a ‘service value stream’ or an ‘operational value stream’ or it could also be a ‘customer journey’. Currently in most organisations teams are organised around skills, applications, or systems, and there could be a many to many relationship with one or more value streams – with huge interdependence.

This is one of the major reasons why they only feel safe creating a ‘Project’ that cuts across multiple silo teams, or they try to boil the ocean by adapting a scaling pattern believing all problems will get resolved.

Step zero is to get the business architects, product management and application architects in ‘one-room’ and map the application, system and operational teams around specific service or operational value streams. You need to identify the dependencies and strangle the monolith with a service orientation approach – a basic micro service architecture. It’s a painful journey, worth starting to launch your ‘speed boats’.

Amazon CTO Werner Vogels, described a similar approach when they adopted ‘Product aligned’ thinking in 2006:

“In the fine-grained services approach that we use at Amazon, services do not only represent a software structure but also the organizational structure. The services have a strong ownership model, which combined with the small team size is intended to make it very easy to innovate. In some sense you can see these services as small startups within the walls of a bigger company. Each of these services require a strong focus on who their customers are, regardless of whether they are internal or external.”

Holley Holland, with its unique blend of TechStartUp experience and Product Engineering skills, combined with business domain SME knowledge and a modern approach to Data strategy, is helping organisations with new ways of working that enables them to deliver outcomes and growth.