When the Model Works and the Team Doesn’t

Skills-based organisations are having a moment. The logic is compelling: reorganise work around verified capability rather than job titles, let talent move fluidly to where it’s needed, make career progression a function of skills visibility rather than tenure. McKinsey, Deloitte, and a growing body of research all point in the same direction. Telstra’s T22 transformation - collapsing 1,800 roles into 200 job families - is the most cited local example of the model at scale.

Most of the debate about SBOs focuses on the technology and the taxonomy. Can you map skills accurately enough? Can the data be trusted? Can you get managers to actually use it?

These are real questions. But they’re not the hardest one.

The hardest question is what happens to team performance when you make teams fluid.

Consider this scenario. A global infrastructure firm dismantles its fixed project teams and moves to a skills marketplace. High performers get pulled into high-priority projects faster. Utilisation improves. The talent data is finally accurate. Eighteen months in, three of their highest-potential managers leave. Exit interviews say the same thing: “I didn’t feel like I belonged anywhere.”

What went wrong? And was it avoidable - or the price of the model?

Decades of team dynamics research - Hackman, Edmondson, Google’s Project Aristotle - tells a consistent story about what actually drives high performance in teams. It is not primarily a function of individual skill quality. It is a function of relational conditions: psychological safety, role clarity, shared mental models, and trust built through repeated interaction over time.

Project Aristotle is the most rigorous data point. Google studied 180 teams over two years, examining 250 different team attributes. What they expected to find was that team quality was a composition problem - get the right people, the right mix, the right expertise. What they actually found was that the dominant variable was not who was on the team but how the team worked together. Psychological safety - the belief that you can speak up without risk of humiliation or punishment - was the single most important factor. The variables that didn’t predict performance at all included co-location, individual IQ, and team size.

Here is where the tension with SBOs becomes acute. Most of this research was conducted on stable teams. Teams that knew who was in them. Teams where trust had time to compound through repeated interaction. The SBO model, at its logical extreme, creates the opposite conditions: teams that assemble around a project and disperse when it concludes. The skills match may be excellent. The psychological safety may never develop.

This isn’t an argument against skills-based organisation design. It’s an argument for being honest about what the model requires to work.

Fluid team structures demand more deliberate investment in the conditions for psychological safety, not less. They require leaders who understand that belonging isn’t an emergent property of putting capable people in a room together - it’s something that has to be built, often in compressed timeframes and across people who haven’t worked together before. The organisations implementing SBOs that are getting this right are treating team dynamics as a design problem, not a culture platitude. They’re building the relational scaffolding deliberately - onboarding rituals for new project teams, explicit norms for how decisions get made, structured mechanisms for surfacing disagreement early.

The ones struggling tend to have focused entirely on the skills infrastructure and assumed the human dynamics would sort themselves out.

They usually don’t. The exit interview data from the scenario above is not unusual. People can tolerate a lot of structural ambiguity if they feel they belong somewhere. Remove that, and capability alone is rarely enough to keep them.

The SBO model doesn’t cause belonging failure. Poor implementation does. And getting the implementation right means taking team dynamics as seriously as the skills taxonomy - not as an afterthought once the platform is live, but as a foundational design consideration from the start.