In the fourth episode of the CIO Debate Podcast, Olaf Terhorst and Nils Gralfs from mgm consulting partners discuss whether organising IT into squads and tribes actually helps to create value more quickly – or whether it dangerously undermines clear responsibilities and governance. We summarise the most important arguments from the pro and con sides of the debate.
The squad model – what’s behind it?
Squads and tribes, often inspired by the ‘Spotify model,’ organise themselves cross-functionally. They combine different disciplines such as development, operations, specialist departments and testing in one team – with the aim of delivering customer value at high speed. The central idea is to break down silos, shorten time-to-market and increase the teams’ individual responsibility.
But how suitable is this model for everyday use? Where are the opportunities – and where are the stumbling blocks?
In the debate: Olaf Terhorst, Partner at mgm consulting partners, and Nils Gralfs, Senior Manager at mgm consulting partners
Moderator: Karsten Kneese, Marketing Manager at mgm
Length: 42 minutes
Listen to the podcast and join the discussion
Pros: Greater speed, autonomy and customer proximity
- Improve time to market: Close collaboration between disciplines within a squad eliminates traditional handovers between development and operations. Decisions can be made faster and features delivered quickly – ideal for dynamic product development.
- Focus on customer value: Instead of focusing on technical silos, squads concentrate on value for the user. Each squad works on a specific product or customer problem, which leads to a clearer focus and often to higher motivation within the team.
- Small-scale experimentation possible: A major advantage is that the transformation can be iterative. Instead of turning the entire organisation upside down in one fell swoop, pilot areas or lighthouse projects can be launched. This allows a company to learn what works – and what doesn’t.
- Modern architecture meets modern organisation: The principle of microservices – small, autonomous functional units – fits perfectly with the squad model. If you want to modernise your IT architecture, cross-functional teams are the ideal organisational counterpart.
- Attract new talent: Young professionals who are used to modern ways of working often feel more comfortable in agile, autonomous teams. The squad model can help you remain an attractive employer.
Cons: Complexity, governance issues and cultural barriers
- New silos emerge – just in a different form: Instead of functional separation, there is a risk of new fragmentation: each squad optimises its own part of the problem – but how do you keep sight of the big picture? Without cross-functional coordination, chaos quickly replaces customer focus.
- Governance and quality assurance under pressure: Many releases, fast deployments: This requires a high degree of discipline and automated processes. If this technological maturity is lacking, quality suffers – and operations become prone to errors.
- Not suitable for everyone: German SMEs in particular often lack the personnel for roles such as product owner, scrum master or DevOps engineer. Introducing such models can overburden resources and provoke resistance – especially when established structures are affected.
- A high level of change effort: A true squad model requires more than just new team names. It affects roles, processes, technologies – and above all, the mindset. Many transformation projects fail because this change is underestimated.
- Regulated industries are struggling: Banks, insurance companies and healthcare providers often have strict process and compliance requirements (e.g. ITIL). This makes it almost impossible to deal with structures freely, which in turn makes agile scaling difficult.
Conclusion: No one size fits all – but lots of potential
The conclusion of the two consultants is nuanced: squads and tribes are not a panacea, but they are a sensible response to modern requirements when used correctly. Organisations should not be blinded by the Spotify model, but should develop their own approaches. The key point here is that cross-functional collaboration is less a finished goal than a learning-oriented process.
Three key recommendations from the discussion:
- Think about technology, organisation and processes together: The model can only work if architecture, skill sets and governance fit together.
- Start with pilot projects: Learn on a small scale instead of failing on a large scale.
- Involve top management: A truly agile organisational model needs support from above – and the courage to change.
