Platduct or Prodform? The teams you need to win with Data & AI
Leaders on transformation journeys think deeply about the organisational structures and types of teams that sit in them. Often, much focus is put into classifying teams into mutually exclusive categories, examples of which include project, product, service and platform teams.
Under this paradigm, the classification of a team dictates its operating model and investment profile. Influenced heavily by manufacturing, teams primarily focus on one of a) developing new widgets, b) supporting scaled widget production and making it more efficient, or c) selling widgets. When making investment decisions, funding levels for the latter two functions are commonly determined by applying static multipliers against revenue forecasts in the financial model.
But do these models extend to a digital world where companies are increasingly relying on data-intensive solutions to maintain their competitive edge?
On platform and product operating models
Enter the ‘platform’ and ‘product’: the digital world’s equivalent of production line maintenance / optimisation and new widget development. Now leaders can also spend their time distinguishing platform from product teams.
The quintessential ‘Platform Team’ brings to mind a centralised group sustaining the life of the business. Investments in such capability are governed by classical cost centre based operating expenditure functions (typically multipliers on headcount, and the dreaded “efficiency dividend”); teams beat to long-running BAU rhythms on repeat maintenance tasks enabling reliability, efficiency, stability, optimisation. A classic example in Data is the central data warehouse team supporting a multitude of business users consuming from shared reporting and analytical assets.
On the other hand, accelerated adoption of product delivery frameworks has seen the emergence of modern ‘Product Teams’, high-octane squads tasked with value discovery and creation — fail-fast experiments, iterative feature improvements and incremental value drops. Under this model, investments are guided less by classical operations metrics, and more by risk-to-return appetite. For a hyper-growth company, every cent of revenue is reinvested in new development cycles, as well as pods spun up to support ever-changing customer offerings.
Against such developments it is no surprise global leadership is placing increasing emphasis on bringing a product mindset to data, and paying attention to the age of the Data Product. Definitions for data products abound and are yet to converge (“no way I’d call a piece of Excel analysis a product!”) — but DJ Patil’s summation of a data product as what “facilitates an end goal through the use of data” might indicate there’s more to data team anatomy than Products or Platforms.
Who are your customers?
Conventionally, front- and back-office designations (as their names suggest) were determined based on distance to the paying customer. While a convenient heuristic, there’s perhaps more to consider for organisations seeking to differentiate on customer-centricity. To put customers at the heart of everything is to have everyone connect their work to the end customer — be it through direct interfaces, or work that never actually involves an end-user.
Consider a product search service: a composite of data platform, ML engine and web application ‘platform’ and ‘product’ components. Natural boundaries can be found between platform (platform engineering, ML engineering) and product (design and web development etc.) aspects, but doing the job well calls for hybrid operating structures. Product pods are also platform teams to other customers — like the data engineers consuming ever-changing user-generated data from their applications. Equally, ML engineers must understand the product nature of search insights, and that tracking how customers’ evolve their interactions with the search engine matters for model (and corpus) maintenance.
Teams failing to embrace dual product-platform disciplines rack up huge debt; and true to Boiling Frog Syndrome, the costs are revealed only at moments of reckoning. Like when a new data sharing service is deemed unfeasible when someone, through some eleventh-hour compliance checkbox exercise, realises the platform hadn’t been built for managing PII and consent. Plenty other examples exist of strategic misfires, not due to the quality of data strategy, but by the lack of execution between boundaries. This phenomena is not novel, but does create discomfort as leaders must choose whether or not to acknowledge what it really costs to succeed with data.
Hub or Spoke: how would it look?
While early debates explored centralised vs. distributed data team models, current expert opinion is that it depends on an “organisation’s strategic priorities and its relationship with data”. For any given model, mounting evidence points to the importance of trading off scale, domain expertise and duplication, and the universal need for governance structures fit-for-purpose to business maturity.
This calls for an examination of operating models beyond “org charts and matrices that split and control work”. In Team Topologies, Skelton and Pais explain “org chart thinking” resulting in teams assembled as if they communicate along the perimeters of their org charts — the reality though, is often different. The point of an org structure is to guide the flow of communication by bringing certain teams closer together than others. But org charts don’t communicate, individuals do. Two people might be placed at opposite ends of an org chart, say, an Engineering Manager within Technology, and a Business Development Lead in Sales. But if it so happened they’d been university friends, chances are the Sales and Engineering pods would end up more aligned than one would expect from simply studying the charts.
So the effectiveness of operations within an org chart is tested when you consider how it looks with real people in it.
The Data Mesh paradigm, for instance, has captured the imagination of leaders for its claim to solving scaling issues through autonomous teams owning data as a product. But if you were keen on the Data Mesh as a target state, consider how that looks with your people sitting in that paradigm. Can you see your engineers permanently embedded in a functional pod, like customer support or HR? Or can you see every application team caring about the impacts of their own data schema changes on company-wide reporting? If the answer isn’t “yes” to these questions, don’t despair — these questions provide clarity on the management puzzles in need of solving.
Concluding remarks
While ‘Op Model’ readiness calls for higher-order thinking than Platform vs. Product semantics, these concepts are still useful constructs for organisational design.
Firstly, defining the chain of custody (owners, prioritisation, communication lines etc.) across the end-to-end data solution gives observability to total cost and return. For instance, it reveals that time-boxed investments in platforms are unhelpful; if a decision-support metrics dashboard helps lift target-conversion rates by 3% p/a, the relevance of its input data requires resourcing for a sustained period to maximise return. Yet, realising sustained value requires treating the asset like you would a product — “The Business” handing over ‘IT’ requirements/solutions and expecting to forget about a problem is a recipe for crippling tech debt (and an expensive archeological expedition in two years when someone wants to know how a number was calculated).
Second, platform-to-product complexities give new meaning to the adage of “What gets measured gets done”. Tying investment to outputs is at best, uninformed, but at worst, destructive; instead, leaders should find levers worth measuring. As a counterintuitive example, a team measured on how they identify ML products not worth pursuing (even Google tells us sustaining ML & AI advantage doesn’t come cheap) is far more likely to create value than one measured on (and incentivised by) the sheer number of products launched.
As a final observation, regardless of where on the product-platform operating spectrum your design inclinations lean, all roads do lead to people; after all, culture does eat strategy for breakfast. At some point in our careers we’ve either experienced or heard of the “bad apple”, and research shows that one bad apple spoils the bunch. It stands to reason then, that creating a rising tide of good people lifts all boats. So perhaps what matters most when designing product-platform teams, no matter what we call them, is the behaviours we build. Importantly, that regardless of ‘platform’ or ‘products’ roles there are no first- or second-class citizens — only the right people in the right places to get the (whole) job done.
