← Home

Omnidisciplinary Teams Ready for the AI Age

9 April 2026

teamsculture

Omnidisciplinary Teams Ready for the AI Age

All That Glitters isn’t Gold

For the better part of the last decade, the gold standard for digital delivery has been the multidisciplinary team.

The logic is sound and well-proven - teams built with multiple specialties, perspectives, and cognitive diversity1 consistently outperform homogenous groups2. Modern software delivery is fundamentally a team sport, and bringing different disciplines closer together has represented a massive step forward across many digital industries.

However, as the span of digital professions has expanded over the past several years, I’ve been increasingly observing frictions within teams caused by a growing trend. The boundaries around our specialties are becoming tighter, more rigid, and increasingly fragmented.

Take the design profession for example. Where once we had “Designers” we now have several sub-disciplines: Service Design, Interaction Design, Content Design etc.

On paper, having this level of deep, focused expertise makes perfect sense. In fact, deep specialization is vital - it prevents catastrophic security breaches and massive usability failures. With more specialised skillsets, we rightly expect higher-quality outputs from individual practitioners.

In practice, however, these tight boundaries are sparking some incredibly awkward ways-of-working conversations within teams and organisations. The enemy here isn't specialization itself; the enemy is isolation and the hand-off friction that comes with it. This fragmentation increases the number of integration points within a team and rapidly becomes a barrier to flow. I’m sure you’ve encountered a similar situation where two practitioners spend their energy trying to solve the problem of “exactly when and how does my work become your work”.

We have hit a point of diminishing returns on how far isolated specialisation can push us. To thrive in the complex problem spaces of today, we need to evolve past the traditional multidisciplinary model. Crucially, the rapid rise of generative AI is the catalyst making this evolution ever more cost-effective right now, giving practitioners the tools to seamlessly bridge the gaps between their specialisms. Much like how the marketing sector evolved past multichannel marketing, we must start building omnidisciplinary teams to be prepared for the coming AI Age.

The Trap of Hyper-Specialisation

In my eyes, the entire point of organising practitioners into delivery teams is to optimise for working in complex problem domains. We team up to share cognitive load and leverage diversity of thought.

Matthew Skelton and Manuel Pais argue in their foundational book Team Topologies3 that expecting everyone to know a bit of everything leads to cognitive overload and burnout. This view is in line with the cross-team collaboration model proposed by the book, but I believe that this doesn’t strictly hold true inside a team - the specific problem domain owned by the team acts as a well-defined bounded context to restrict that cognitive load, and the close bonds of trust ideally shared by team members causes a resilient mesh of shared knowledge4 to naturally form as a network effect byproduct. In other words, not every team member needs to know everything, but collectively everyone does know everything with some redundancy.

Yet as we hyper-specialise, I keep observing the exact opposite. Individual practitioners retreating into deeply siloed working patterns hidden within their delivery teams.

Why does this happen? In my humble opinion, silos are the natural byproduct of collaboration becoming too difficult. Humans are biologically hardwired to be tribal pack animals, and a silo is effectively a tribe of one.

As roles become narrower, the strict RACI matrices we use to define them can inadvertently create walls. Practitioners begin to feel a distinct, underlying anxiety to justify their existence and protect their space within the team. The tighter the niche, the worse the imposter syndrome we all naturally experience becomes, and the greater the anxiety fueling the need to prove your belonging within the wider group.

To frame this another way, think about the everyday realities of delivery. I struggle to clearly articulate the precise way a user researcher and a business analyst are supposed to collaborate on a granular level. What happens when they inevitably disagree? Imagine a half-written ticket sitting in Jira that both practitioners have an equal, valid claim to. Whose specialist expertise is the "correct" one to trust? Does it come down to who has more seniority on the project, in the organisation, or in the industry?

This friction leads to defensive gatekeeping. Instead of a shared effort to deliver value, we end up with a collection of specialists operating independently and simply handing work off to the next silo. The result is a triple threat of negative outcomes:

  • Worse outcomes for the team: Collaboration drops, and the end-user experience becomes fragmented.
  • Higher anxiety for practitioners: Team members spend emotional energy guarding their territory rather than feeling secure in their contributions.
  • Increased resourcing complexity: Landing staff on a hyper-specialized team is a difficult endeavour as it’s increasingly unclear which staff members and job roles are actually required, often leading to bloated teams and financial pressures.

We are collectively spending too much energy defining where one job role ends and another begins. It’s time to rethink the boundaries of our roles entirely.

Omnidisciplinary Teams

So how do we fix this?

Allow me to introduce the omnidisciplinary team, the new gold standard of delivery excellence.

To be absolutely clear, this is not about throwing out your organisation's capability frameworks or abolishing official HR titles. Within an omnidisciplinary team, the goal is instead to introduce a collaborative layer that sits gracefully on top of those existing structures.

Your official job title might dictate your pay band, line management, and career progression, but your daily remit within the delivery team is to solve the problem domain collectively. Instead of strict RACI matrices separating us, we shift toward a shared list of team "responsibilities."

In practice, this means:

  • Team-first specialisation: Practitioners first focus on specialising in the problem domain of the team, then on their individual areas of interest.
  • Artefacts are co-owned: A developer might draft initial acceptance criteria, while a business analyst might tweak UI copy in the design files, and a delivery manager might submit a simple pull request change to the codebase.
  • Bottlenecks are cleared by the collective: If testing is backed up, or user research synthesis is dragging, the entire team swarms around the problem to unblock flow and elevate the constraint, rather than waiting on the designated specialist.
  • Hand-offs are reduced: Flow of work completed is increased, feedback loops are tightened, leading to better outcomes for the team.

Want a fantastic example of an omnidisciplinary team? Watch any of the Ted Lasso5 episodes that talk about Total Football6, a system where any player on the pitch can seamlessly take over the role of any other player. This crucially excludes the goalkeeper, who (unless in exceptional circumstances) still owns the defence of the goal as a dedicated specialist.

Now, bear in mind that under the hood, your team is still full of diverse specialties. People will always be naturally better suited to (and prefer) certain tasks. But crucially, they are not coupled to them. For example, I am a Lead Software Engineer, which means I’ve been around enough digital practitioners for long enough that I can comfortably pick up the simpler parts of their jobs when needed. I certainly don’t have the required expertise to be a Lead User Researcher, but I absolutely have the skills to assist our team’s researcher in taking notes, sorting through transcripts, and unblocking their flow.

An overlapping knowledge mesh within a team makes a team resilient and effective. In a mixed-seniority omnidisciplinary team, every sufficiently-experienced practitioner should be thought of as the most junior grade (or higher, if warranted) of every other profession.

From Gatekeepers to Mentors

When practitioners stop trying to protect their hyper-specific niche, a profound cultural shift happens: they start actively mentoring their teammates.

Instead of holding onto a silo, every member of the team gets a chance to play the role of teacher. This taps directly into the Protege Effect7 - which states that the best way to learn about a topic is to teach it to others. This foundational concept truly shines in high-stakes environments when considered alongside Psychological Safety8. Actively mentoring your peers is a deeply empathetic act that builds this safety

Paradoxically, giving away your knowledge makes you feel more secure. I've always wondered why imposter syndrome and anxiety are so common for so many in our industry. One approach I've found that helps me is replacing anxious behaviour patterns with empathetic ones. Mentoring your peers is a deeply empathetic act! Teaching triggers positive neurological responses (hello, serotonin) and helps combat the anxiety that siloed specialisation creates.

This shared knowledge approach incurs a number of concrete practical advantages for the team:

  • Resilience against personnel change: It protects the team from disasters, such as when a key team member holding a silo of knowledge leaves the company.
  • Optimising for team flow: It makes it more efficient to ask quick questions, even if it distracts someone for a few minutes, in order to optimise for the flow of the team as a whole.
  • Increased psychological safety: It increases the strength of relationships between members of your team through shared vulnerability. This is key to increasing the level of resilience to stress that individuals within your team have.

Beyond resilience and speed, it also creates much stronger end-user experiences. With fewer hand-offs and a shared focus on the entire problem domain, the end product is naturally more cohesive - much like how omnichannel marketing originally evolved to provide hyper-personalized experiences across boundaries.

The AI Catalyst: Why this is Critical Now

This shift toward omnidisciplinary teams is highly beneficial today, but as we push further into the AI age, I believe it will become absolutely critical. I predict that we’ll all begin to observe significant performance differences between traditional T-shaped910 multidisciplinary teams and W-shaped11 truly omnidisciplinary teams as AI becomes an even greater enabler for digital delivery.

Today, AI tools are drastically reducing the cost and time required to pick up new skills and get productive. Recent empirical studies from Harvard12, MIT13, and Microsoft14 consistently demonstrate that generative AI disproportionately accelerates the performance of non-experts. Generative AI acting as a co-pilot means the barrier to entry for a software engineer to write competent copy, or for a designer to scaffold a basic frontend, has never been lower.

However, we must address the difficult realities of enterprise-grade delivery for both public and private sector organisations. An AI-generated UI scaffold built by a backend engineer is a massive WCAG15 accessibility lawsuit waiting to happen if left unchecked. This dynamic perfectly illustrates the “Jagged Technological Frontier”16, which formally states that generative AI is brilliant inside the frontier but hallucinates disastrously just outside it, making crucial quality guardrails and oversight of senior domain experts mandatory.

While AI allows practitioners to easily cross-skill and unblock a team's flow, the ultimate accountability for the quality, accessibility, and security of a discipline's output still relies on the domain expert. AI acts as a set of training wheels to accelerate execution, not a replacement for professional accountability.

To put it another way, AI-enabled cross-disciplinary working within teams is safe in exactly the same way that junior practitioners working within teams are safe: through the oversight of experienced, senior practitioners and relevant specialists for critical areas of risk. Because of this dynamic, some industry voices are already predicting the rise of teams staffed almost exclusively by versatile “product specialists” using AI tools to rapidly build and iterate.

In these future teams, specialists with deep knowledge won't just be there to churn through day-to-day delivery work. Instead they will act as enablers and as a safety net, providing an AI-enabled platform for the generalists to succeed, ensuring strict compliance, and capturing those "black swan"17 unknown-unknown edge cases that only true experts have the experience to spot and surface.

Practical Tips for Adoption

But what about the real world? It’s all well and good to evangelise a theoretical approach to teamwork, but how would you go about applying this to a real project you’re working on?

Tread Lightly

Many of us tightly couple feelings of pride and self-worth to our job roles - omnidisciplinary working naturally challenges those well-established boundaries. Compounded by the initial investment in cross-skilling required, this transition can be easily perceived as both radical and wasteful, leading to greater resistance to adoption.

The single most crucial bit of advice I can impart here is to tread lightly. Implement change slowly and allow the natural curiosity of practitioners to be the driving force for transformation wherever possible - not mandate from above.

Implement Cross-Disciplinary Pairing

One fantastic method for building shared knowledge is paired or mob “programming” (even if the task at hand isn’t writing code). The naive view is that grouping up practitioners is less efficient because fewer tickets are being worked on simultaneously. However, pairing is incredibly efficient for learning. Modern delivery teams are often bottlenecked by the speed at which practitioners can learn. Even though you're doubling up staff, you're halving the time you're collectively learning, plus you learn about multiple topics in parallel.

In an omnidisciplinary team, this means stepping outside your discipline. Pair a software engineer with a user researcher to help take notes and sort transcripts, or have a business analyst sit with a designer to write acceptance criteria directly into the design files. By collaboratively working on day-to-day problems with others and regularly swapping who “drives” the session, you enable this learning.

Champion the “Naive” Question

To make this work, members of a high-performing team must get comfortable with the idea of asking "naive" questions and interrupting colleagues to unblock work. It is far more efficient to ask a quick question, even if it distracts someone for a few minutes, than to remain blocked on your tasks while trying to figure it out alone.

I often hear the classic, "I know this might be a naive question, but...". On the surface, it feels like a selfish interruption, but time and time again I've found that if you're thinking about a "naive" question, someone else is as well! These questions aren't selfish; they protect those who might otherwise be quiet in a group and clarify information for everyone involved.

Map the Domain, Not the Job Titles

To move away from rigid silos, you need to build a resilient mesh of overlapping knowledge within the team. In this mesh, there should be a shared "core" of knowledge about the specific problem domain that everyone in the team understands.

Instead of relying on traditional job titles, run a workshop to map out the actual tasks required to deliver your product. Have team members volunteer for tasks they can lead, tasks they can assist with, and tasks they want to learn. This builds out those W-shaped skillsets and protects the team from disasters, such as a key team member holding a critical silo of knowledge suddenly leaving the company.

Change How You Measure Success

It's important to realise that what is optimal for the individual is not always optimal for the team. If you measure success by individual utilization, you will inevitably create silos. Instead of evaluating team productivity as the sum total of contributions by individuals, we should evaluate it as the collective output of the entire team.

Stop worrying about unimportant details like exactly how many tickets or story points each specific person completed. Instead, focus on overall system performance and consider trialling DORA metrics alongside agile flow metrics (like cycle time or lead time for ideas) within your team. This ensures non-engineering disciplines are also included in the success metrics. High-performing product teams must relentlessly focus on collective outcomes rather than measuring individual output18!

Utilise AI Tools as Training Wheels

Finally, explicitly encourage your team to lean on AI to bridge their personal knowledge gaps. As I mentioned earlier, generative AI acts as the ultimate co-pilot, lowering the barrier to entry for cross-skilling.

If a product manager is picking up a piece of front-end work or a back-end engineer is writing basic UI copy to help maintain the team's flow, encourage them to use AI tools to explain unfamiliar syntax, scaffold the basic structure, or review their initial drafts. AI doesn't replace the need for deep experts on "black swan" issues or for quality control and mentorship, but it acts as an incredible set of training wheels to help generalists become productive in secondary disciplines much faster.

Conclusion

Modern software delivery is fundamentally a team sport. As an individual member of the team, you need to check your ego at the door and embrace the day to day functions of the job roles surrounding you.

By breaking down silos, learning to collaborate better, and incorporating AI tooling to enhance our skills, we can optimize our teams to solve complex problems faster, cheaper, and safer. As Karim Lakhani famously stated, "AI won't replace humans, but humans with AI will replace humans without AI”19. The era of multidisciplinary teams of isolated specialists is ending; the era of omnidisciplinary teams is just beginning.

  1. Syed, M. (2019). Rebel Ideas: The Power of Diverse Thinking. John Murray Press.↩︎
  2. Page, S. E. (2007). The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies. Princeton University Press.↩︎
  3. Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.↩︎
  4. Tom Vaughan (2022). Optimising learning in high-performing teams↩︎
  5. Sudeikis, J., Lawrence, B., Hunt, B., & Kelly, J. (Creators). (2023). Ted Lasso (Season 3) [TV series]. Apple TV+.↩︎
  6. Winner, D. (2000). Brilliant Orange: The Neurotic Genius of Dutch Football. Bloomsbury Publishing.↩︎
  7. Chase, C. C., et al. (2009). Teachable Agents and the Protégé Effect. Journal of Science Education and Technology.↩︎
  8. Edmondson, A. C. (2018). The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. John Wiley & Sons.↩︎
  9. Guest, D. (1991). The hunt is on for the Renaissance Man of computing. The Independent.↩︎
  10. Brown, T. (2010). IDEO CEO Tim Brown: T-Shaped Stars: The Backbone of IDEO’s Collaborative Culture. Chief Executive Magazine.↩︎
  11. Jones, B., et al. (2020). The W-shaped model of professional competencies for the Fourth Industrial Revolution. Journal of the European Honors Council, 4(1), 1-16.↩︎
  12. Brynjolfsson, E., Li, D., & Raymond, L. R. (2023). Generative AI at Work. National Bureau of Economic Research (NBER Working Paper No. 31161).↩︎
  13. Dell'Acqua, F., et al. (2023). Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality. Harvard Business School Working Paper.↩︎
  14. Peng, S., et al. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. Microsoft Research / GitHub.↩︎
  15. World Wide Web Consortium (W3C). (2023). Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation. https://www.w3.org/TR/WCAG22/↩︎
  16. Dell'Acqua, F., et al. (2023). Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality. Harvard Business School Working Paper.↩︎
  17. Taleb, N. N. (2007). The Black Swan: The Impact of the Highly Improbable. Random House.↩︎
  18. Cagan, M. (2024). Transformed: Moving to the Product Operating Model. Silicon Valley Product Group.↩︎
  19. Lakhani, K. R., & Ignatius, A. (2023). AI Won't Replace Humans—But Humans With AI Will Replace Humans Without AI. Harvard Business Review.↩︎