Home → Leadership
Squad, Tribe, Chapter, Guild: Choosing an Org Model in One Week
My first week on the job, a get-to-know-you meeting with the CEO. Half an hour, coffee, "welcome aboard". In the last five minutes he handed me my first target: "Come back in a week and tell me how we should run this company."
- My first instinct was wrong: pick a framework and present it. The right move was to diagnose first.
- I spent the week talking, not drawing boxes. 52 conversations, 4 fixed questions.
- Once the diagnosis was clear the model chose itself: the problem was not speed, it was ownership.
- We did not copy it, we trimmed it. On day one we set up 3 tribes, 3 squads and 3 chapters; a guild appeared on its own months later, and a dedicated agile coach never came.
That was not the question I expected
The things I had prepared for that meeting were the usual ones: questions about the stack, the roadmap, team size. That sentence came in the last five minutes and I wrote one line in my notebook: "1 week — how do we run the company?"
Walking out I had two feelings. First, excitement — nobody hands you that much space in your first week. Second, unease: getting this wrong does not just ruin a presentation, it ruins the way we will work for the next two years.
My first instinct was wrong
Let me be honest: my first thought was to pick a framework and present it. I had a ready list in my head — SAFe, LeSS, the Spotify model, a classic matrix. I would pick one, build a nice deck and say "let us do this".
For the first two days I was doing the interviews and, at the same time, still trying to pick a framework. By the evening of day two I realised why that was wrong: I did not yet know what was broken. Choosing a model is writing a prescription, and you do not write a prescription before examining the patient. I closed the list of frameworks. The rest of the week would go not on drawing an org chart but on reaching a diagnosis.
What I did that week: 52 conversations, 4 questions
For five days I gave my calendar to one job: talking. The company built an e-commerce app and had 40 people, and I sat down with all of them: developers, QA, product, support, sales. I also sat down a second time with twelve of them, because what they said in the first conversation had not been confirmed by anyone else. 52 conversations in total, most of them half an hour; about ten a day.
I asked the same four questions every time. Keeping them fixed mattered — ask different questions and you get answers you cannot compare:
- Tell me where most of your time went this week. Not what you did — where your time flowed.
- What kept you waiting most in the last month? This is where you find the blockers.
- You notice something is broken. Who do you tell? This question reveals the real org chart.
- If you had a magic wand, what would you change? People drop their guard on this one.
The third question was the most useful. Of 40 employees, only 12 gave a clear name; the rest answered: "Honestly I do not know who to tell, so usually I do not." There is no clearer diagnostic signal in an organisation than that.
What I heard
- "I touched four different projects this month and finished none of them."
- "Who knows the payment side? Nobody. The person who wrote it left."
- "We discuss it in the meeting but no decision comes out, and then nobody remembers."
- "I do not know who to go to for a request, so I tell whoever I find last."
- "We call things urgent to get them in, because if you do not say urgent it never happens."
- "I have been asking the same thing for three months and a different person looks at it every time."
The diagnosis: the problem was not speed, it was ownership
On the evening of the fifth day, with the notes side by side, the picture was clear. The company worked project by project: a piece of work arrives, people are gathered for it, and they disperse when it is done. That sounds flexible; in practice it produced this:
- Nothing had an owner. The payment system belonged to nobody; whoever touched it last was considered responsible.
- Context reset every time. Someone opening the same module for the third time started as if it were the first.
- Nobody thought long term. Why worry about technical debt in code you will not touch in two months?
- Decision rights were unclear. Everyone looked at everything, so nobody could decide anything.
The interesting part: nobody was lazy, everyone worked hard. The problem was not effort, it was the way effort was spread.
Why squads?
Once the diagnosis was "no ownership", the candidate list shortened by itself. What I was looking for was clear: long-lived teams that own an area and can make their own decisions. That description was already the description of something.
| Candidate | Assessment |
|---|---|
| The existing project-based structure | It was the source of the problem |
| SAFe | It brought a 300-person ceremony to a 40-person company. Adding three more layers to a structure that already could not decide |
| LeSS | The most reasonable candidate at this size, but it assumes one product and one backlog. We had three separate business areas, and our problem was ownership, not sprint mechanics |
| Classic functional structure (backend team, frontend team, QA team) | Ownership still falls between the cracks; every piece of work travels between three teams |
| Classic matrix (project manager + functional manager) | What we chose is also a matrix: the work sits in the squad, the line manager is the chapter lead. The one difference: in a classic matrix the project ends and the team disperses; a squad is permanent |
| The squad model | It gave exactly what was missing: a cross-functional team that permanently owns an area |
There was also cultural fit, and that was the deciding factor. In this company people wanted to make decisions; the problem was not a lack of authority but a lack of clarity about who decides. An autonomy-based model fits a team that already wants autonomy. Put the same model into a culture that avoids deciding and it will not work — squads get created, nobody decides, and you are still the bottleneck.
- Squad — a cross-functional team of 6–12 that permanently owns an area. Like a small company.
- Tribe — a group of squads working in related areas.
- Chapter — people with the same skill (all the backend engineers, say). The chapter lead is the line manager: career and growth sit with them.
- Guild — a voluntary community of interest, open to the whole company.
The heart of the model is the chapter: managing the work and managing the person are separated. The squad decides what gets done; the chapter lead is responsible for the person's growth.
But we did not copy it
The thing that struck me most while reading about the model was the warning inside the 2012 paper itself. The authors said on day one that this was a snapshot, not a prescription: the model had been introduced gradually over the past year, people were still getting used to it, and today's solutions would create tomorrow's problems. Years later, former employees told the rest of the story: Spotify never applied the model exactly as described. There is a saying in the industry for a reason: "Spotify doesn't use the Spotify model."
That disclaimer was a relief, because it removed the pressure to copy. We treated the model like a menu: took what we needed, left what we did not.
- Squads: three of them, each owning a business area. 26 engineers: 9 + 9 + 8
- Tribes: three, one squad in each. The tribe is the name and the boundary of the business area; the squad is that area's team. In the original a tribe collects several squads; with 40 people there were no squads to collect, but I wanted the area boundary drawn from day one
- Chapters: three — backend, frontend, QA. Unlike the original, they were company-wide; kept inside a tribe, a chapter would have had three people
- The chapter lead = line manager separation
- Guilds: you cannot force one. The first guild appeared on its own in month four
- A dedicated agile coach role: a luxury at that size
How did we split the squads? This was the most critical decision and there were two options: by technology (backend squad, mobile squad) or by business area. We chose the second, because the first would have preserved the existing problem under new names. A squad had to be able to finish a piece of work end to end — without depending on another team.
Why three? Size was part of the decision: 26 engineers, three business areas. Three squads, 9 + 9 + 8. I considered a fourth squad and dropped the idea: splitting 26 four ways meant two squads of 4, and 4 is below the model's own 6–12 definition. One person on leave and you are down to three; a three-person squad is not a squad. Rather than build squads that broke the definition, we built fewer squads.
The hardest part: chapters
Setting up squads was easy; everyone was excited. The difficulty was on the chapter side, and we got stuck in two places.
That was the first instinct: chapter leads started getting involved in technical decisions inside squads. The sentence "as the backend chapter lead I cannot approve this architecture" came up three times in the first month.
But that was not the definition of the role. We had to make it explicit and boiled it down to one sentence: "A chapter lead manages the person, not the work." Technical decisions belong to the squad. The chapter lead sets standards, protects the quality bar and develops people — but does not veto the squad's decision.
The question that arrived in week two. A developer works in a squad but their performance review is done by the chapter lead. People were understandably confused.
This is the model's best-known weak point. A critique written in 2020 by a former Spotify employee is centred on exactly this: the matrix turning into autonomy with no accountability, and chapter leads losing touch with the work. We hit the same thing at a small scale. We solved it with a table, and that table is still up today:
| Topic | Who |
|---|---|
| What I work on and in what order | Squad (with the product owner) |
| How I build it, which technology | Squad |
| Code standards, quality bar | Chapter |
| Career, promotion, performance | Chapter lead |
| Time off, one-to-ones | Chapter lead |
| Moving to another squad | Chapter lead + both squads together |
That table does not live in a slide; it is pinned in the team space and shown to every new joiner on day one. The cost of ambiguity is far higher than the cost of pinning up a table.
What I actually presented to the CEO
I went into the meeting a week later with a single page. I did not build a deck, because what convinces is not the model but the diagnosis.
- What I heard: four sentences from the 52 conversations, quoted verbatim.
- Diagnosis: one sentence — "Nothing has an owner."
- Proposal: 3 tribes, 3 squads, 3 chapters, split by business area. A one-page diagram.
- What we will measure: three numbers (below).
- When I will come back: in three months, with the numbers.
The meeting took 20 minutes. What we discussed most was not the model but the first item — the quotes. They were sentences the CEO had never heard about his own company. After those quotes, the model looked inevitable.
The first months: what broke
I have told the good parts; now the honest ones. The first months were not smooth, and I did not expect them to be — the early phase of this kind of shift is always messy.
- Dependencies between squads. The goal of "one squad finishes work end to end" did not hold on day one; there was a shared authentication service and everyone needed it. Two months later we gave that service to a squad as its owner and defined a clear interface for the others.
- Ownership turned into "my territory". In month three one squad refused to touch another squad's code. We made the rule explicit: anyone can touch any code, but it goes through the owner's review.
- The first hires came in month three. Two developers and two test engineers; engineering went from 26 to 30. We did not hold the new people back to open a fourth squad; we spread them across the existing three. Four people do not make a squad; they fill up three.
What we measured
The three numbers I promised the CEO. Deliberately few — ten metrics do not get tracked.
- Time from a piece of work starting to reaching production. If ownership really formed, this shortens. We used the median, not the average; a few very long pieces of work distort the average. In three months the median went from 19 days to 11.
- How many different people a piece of work gets assigned to. The most honest measure of dependency, and you can measure it before squads exist: look at the ticket's assignee history. It started at 2.4 people on average; the goal was to approach 1. In three months it came down to 1.5.
- The "I know who to tell" rate. A one-question survey every three months — the same as the third question from that first week. In the first week 12 of 40 people (30%) gave a clear name; three months later, 31 (78%). That number became the one I am proudest of.
If you are adapting this to your own company
- Did you reach a diagnosis before picking a model? Is it written down?
- Are squads split by business area or by technology?
- Can one squad finish a piece of work end to end, or does it always depend on someone?
- Are squads permanent, or do they disperse when the project ends?
- Is the "who manages the work, who manages the person" split written down?
- Do chapter leads veto technical decisions? (They should not.)
- Do you have a product owner per squad? (That determines how many squads you can create.)
- Did you force the guild into existence, or did it appear on its own?
- Do you know the three numbers you will look at in three months?
Conclusion
That week was one of the most enjoyable of my career. Not because I found a model — the model was already out there for anyone to read and apply. The enjoyable part was hearing a company from its own employees, across 52 conversations, and watching scattered sentences settle into a single diagnosis.
And the real lesson from that week: choosing an org model is easy once you have the diagnosis. The hard part is not skipping the diagnosis because you are excited about a model. Squad, tribe, chapter, guild — those are the answer. First you have to find out what the question is.
The chapter lead's hardest job, performance and growth, is in Can You Measure Performance With OKRs?; the leadership behaviour a squad needs in order to actually decide is in New-Generation Leadership.
The original: Henrik Kniberg and Anders Ivarsson, Scaling Agile @ Spotify (2012); the "snapshot" warning is in the paper's own closing section. The critique that the model was never really applied: Jeremiah Lee, Spotify's Failed #SquadGoals (2020).