Three layers of products. Two very different levels of investment.
“The biggest organizations in the world are pivoting to a product-centric operating model,” opens Charles Betz, Principal Analyst at Forrester, on a recent webinar. But with product structures emerging as the primary operating model, new challenges are emerging in technical product management.
While newly-formed product teams are persistent, heterogenous, outcome-oriented, and customer-focused, for the most part, they still haven’t solved the question of autonomy. Product teams have a lot of dependencies on platform teams, which in turn impede their flow.
How do you transform an infrastructure functional team into a platform team?
Watch the full webinar
“The pace of innovation is very much determined by the organization design and how we structure this matrix of roles and responsibilities,” says Dr. Mik Kersten, Tasktop CEO and best-selling author of Project to Product, who co-hosts the webinar.
Mik describes the three layers of products in every organization:
- Business-facing products
- Platform products, which business-facing products build on through APIs, services, etc.
- Productivity products, which developers rely on to do their work efficiently, e.g., toolchains and pipelines
In the shift to product, Mik has observed a lot of investment going into the product structure of the top layer, but far less into the layers below. Leaders appear to lack the right tools to comprehend and determine how those teams should be structured, staffed, or matrixed.
Matrixes are here to stay. So how do you design them correctly?
In a world of diverse skills working together towards shared outcomes, Mik and Charles agree that matrix management will always be required.
Feature teams have found a model that works. The “two in a box” model is commonly used for business-facing products, whereby two (or more) leaders representing two (or more) pyramids — typically Product and Engineering — co-manage a cross-functional team. Line reporting remains by pyramid. Hence, the matrix.
But as the shift to product progresses, the build-and-run feature teams begin to impinge on the traditional Infrastructure & Operations (I&O) organization, which forces the creation of IT and Cloud automation platforms. Unfortunately, the “two in a box” management model is not a natural fit for a team of infrastructure engineers that emerged from the same functional silo.
Shifting from project to product? Take the maturity assessment
Measuring the right organizational construct: value streams
There isn’t a one-size-fits-all approach (yet) to this conundrum. The best advice is to apply lean thinking and an agile approach to find the right solution.
A unified set of metrics that measures the right organizational constructs can provide the leading indicators to whether the organizational design of platform teams is working. Are speed and velocity improving? Are cognitive loads manageable? Are team members able to focus on more than just tickets? Is employee engagement high?
These principles, which are also core to Team Topologies, help determine whether you have settled on the right matrix. These feedback loops cannot be within silos, rather come from end-to-end processes. Hence, value streams are the correct organizational construct for this measurement.
“Empower platform teams to be customer-centric with goals and metrics that measure outcomes. Allow them to demonstrate the improvements and celebrate those wins,” says Mik.
“Get yourself a [tool like] Tasktop, because that’s one of the ways you can show that you’re actually managing to the hotspots and the blockages, and that’s part of being a product-centric platform team,” summarizes Betz.
Watch on-demand: How to Secure Investment and Hang on to Top Talent in Platform Delivery Teams
