Looking at teams as specialized control and optimization algorithms — which you should — the main weakness in the way they are usually structured is that they are poorly aligned with the causal structure of most things you actually want to optimize.
As a toy example, let’s say you have an optional paid AI feature in a free-to-use system and your main business metric is total revenue (it’s never this simple, of course). There are a number of plausible causal factors impacting on it, say
- User base composition.
- UI behavior associated with feature access.
- Aspects of AI performance.
- Pricing.
(By the way, teasing out causal impact is a much much much harder problem than just doing dashboards and finding correlation patterns. It’s the difference between a run-of-the-mill biology research paper and a multi-billion dollar compound.)
Most organizations try to optimize these impacts in isolation: you have people from a team working on pricing, your backend engineers tweaking performance, AI people doing their own thing, marketing people maximizing engagement metrics. This makes historical sense, but it’s a very inefficient way to optimize any nonlinear system: you might need to coordinate your UI and user acquisition strategies, optimal pricing might depend on AI behavior, etc.
Even more seriously, teams have other goals at the same time (e.g. keeping the system working, or getting the UI to work with voice control, or whatever); best case, you have talented and hardworking people trying to simultaneously optimize poorly or entirely unmapped systems on which they have a very weak causal impact that depends on the work of other teams they have very indirect relationships with.
It’s no surprise that deliberate improvements to top metrics happen rarely and haphazardly instead of the continuous improvement you’d expect from all the data and computational power we have: our computational architectures, which is to say our org charts, are entirely dissociated from the structure of the problem we’re trying to solve.
A computationally efficient team, just like any other algorithmic solver in a well-factored problem, matches the structure of the subproblem. To optimize revenue in the toy example you need in the same team and working together — that is, over a shared computational model of the system —
- Somebody in marketing with direct influence on the user base composition.
- Somebody in UI with direct influence on feature access.
- Somebody with direct influence on the AI.
- Somebody with power over pricing.
- An analyst/modeler/AI architect (the different names are historical artifacts) to help put together a single model of your feature revenue, help the team optimize the variables they influence, and keep an eye on whether you need to bring other people into the team, release some resources because they no longer have marginal causal impact, or dissolve the team entirely and rebuild your causal model.
This, in fact, is how key teams in most high-performance organizations are structured. It’s not the default organizational structure because it’s computationally hard to figure out what the right structure is for a given moment in a given company — easier to put all the engineers together, all the sales people together, etc, and manage each group with homogeneous metrics.
We now have the technology and algorithmic tools to do this as a matter of course, or at least for the key metrics on which businesses succeed or fail. Most people think of an AI architect as somebody who helps design AIs, but organizations are hybrid composite intelligences: as the meme goes, they have always been. The AI architecture is the organizational structure, but it’s also true the other way around, and you can’t leverage the full power of computational intelligence until you have aligned both.