Stage 1

Rough start

“What are we actually doing?”

The tribe's early days. IT and the business now work together within a single structure. End-to-end capabilities are still being built, and some of them may be kept outside the teams, knowingly or not. It's try & buy - the organisation is testing whether this model will work here at all.

Solves

The disconnect between IT and the business - building teams that can deliver value without constant handovers between functional silos.

How to recognise this stage

The tribe exists, but the boundaries of responsibility are unclear - team members struggle to tell product responsibility apart from line responsibility
“Transformation” mainly means a new structure, not a new way of working
Key end-to-end capabilities are missing from the teams
Each team (squad) works differently - there are no shared standards, tools or events
Problems that come up are blamed on the change (e.g. on the tools)
Work and priorities come in from outside, and decisions are made outside the tribe
Dependencies between teams surface during the work, not before it
Technical debt and architecture are inherited from before the split into tribes, not designed for it - some teams are “afraid” to touch the systems and applications they inherited with the change
Improvements happen ad hoc, usually after a major outage or failure - there is no regular cadence for learning lessons

What usually hurts

The tribe delivers, but “slowly” and unpredictably. The change of structure hasn't significantly changed how the work is done. “Agile theatre” - we have the names, teams, meetings and boards - the rituals of the new way of working. What's missing is an understanding of the intent and depth of the change, and a shared understanding of who is responsible for results and processes.

What usually happens next

The tribe delivers better than before. Better enough that it makes sense to carry on, but the lack of a shared cadence and language between teams starts to hold it back and get in the way. Stage 2 begins.

Where you see it

Organisations shortly after launching their first tribes - usually within the first year, most often in sectors with a historically strong IT/business divide (banking, insurance, e-commerce, retail), before broader transformation programmes kick in.

Recognise this stage in your tribe? Let's talk about what usually blocks the move to stage 2 and where to start in your case.

Let's talk about stage 1

Transition 1 → 2

How to move to stage 2

Signal that it's time to start

The tribe delivers, but every team does it differently - different tools, a different cadence, a different understanding of “done”. “Agile theatre” (names, teams, meetings, boards) is no longer enough - the tribe lead and the team leads start to name together that the problem isn't the structure (that already exists), but the lack of a shared way of working. The key question to agree on together: “what makes our teams different today, and does it have to stay that way?”

Who leads

The tribe lead together with the team leads - this is the first transition, which the tribe makes mostly on its own.

When you need someone from outside the tribe

Rarely needed. The exception: when the differences between teams come from standards imposed from above (e.g. security, IT department requirements) - then aligning engineering practices first needs agreement from outside the tribe.

First tangible result

The first shared quarterly business review in which all teams refer to the same goals rather than their own local priorities.

Warning sign

The cadence exists on paper, but in practice it is often skipped or postponed - a sign that the tribe formally claims stage 2 but in reality still works like a collection of separate teams from stage 1.

We agree the specific steps in a conversation, because they depend on your context.