12. Team and Project Organisation

In theory, organising teams and projects sounds simple: you have people, you have work, you connect the dots.
In reality of software development, how you connect those dots has a huge impact on motivation, delivery, and long‑term performance.

Over the years I’ve seen three dominant approaches:

1. A stable team bound to a single project.
2. A matrix model, where people are moved across projects based on competences.
3. A team‑first model, where you invest in a high‑performing team and let that team tackle different projects over time.

All three can “work” on paper. But they create very different dynamics for people and for results.

In this post I’ll walk through each model, with pros and cons, and share why I believe a team‑first approach is usually the most sustainable choice – especially if you care about high performance, trust and long‑term impact. I’ll also connect this to Tuckman’s model of team development and to my earlier view on Product, Process, People from What Is Engineering Leadership?.

One team, one project – deep focus with hidden risk

The first and probably most common approach:
You create a team, you give them a project, and they work on it for a long time.

The upsides

There are clear benefits here:

• Stability and routine – people know their domain, stakeholders, and codebase.
• Deep domain knowledge – over time the team becomes the “experts” on this area.
• Predictable collaboration – ways of working, ceremonies, and relationships stabilise.

From a Tuckman point of view (Forming → Storming → Norming → Performing), this model gives you a decent chance to reach the Performing phase and stay there for a while. The team has time to go through conflicts, norms and eventually operate smoothly.

The downside: your success equals your project

The problem is on the other side of the coin:

• If the project is not successful, the team is also seen as not successful.
• If the business priority changes, the project can be frozen – and the team with it.
• People may get trapped in a shrinking or low‑impact area for a long time.

I’ve seen teams doing great work in a project that later was deprioritised or cancelled. The team’s skills and potential were still strong, but because they were too tightly bound to “their” project, they struggled to reposition themselves.

In other words: in this model the project is the centre of gravity, not the people.

Matrix organisation – optimising for competences, not for humans

The second approach is a matrix model.

You have a “home” team (for example, all backend engineers in one group), but in practice people are constantly allocated to different Scrum teams or projects based on current needs and skills. Designers and testers might be shared in a similar way.

Why organisations like it

From a pure spreadsheet perspective, this model looks optimal:

• You can optimise for competences – put the “right” experts into the “right” projects.
• You can react quickly when priorities shift – just move people around.
• Capacity planning looks flexible – FTEs can be distributed across many initiatives.

On a slide deck, it looks beautiful. In reality, it often hurts people and performance.

What it feels like for the team

From the human side:

• Belonging becomes blurry. Am I part of my functional group, or my current project?
• Tuckman never finishes. If you keep changing team composition, you stay in Forming / Storming and rarely reach stable Performing.
• Personality and energy fit are ignored. People are matched mainly by skills, not by how they collaborate or what energises them.
• Context switching increases. Some engineers effectively work for multiple “teams” at once.

Leaders sometimes forget that teams are not just a sum of competences. Team dynamics, trust, psychological safety and shared history matter at least as much.

I wrote earlier in 10. Building Trust in Engineering Leadership that trust is built through consistent behaviours over time. In a matrix model, “over time” is exactly what you don’t have. The team composition changes before trust can fully grow.

As a result, matrix structures often look efficient but feel fragile.

Team‑first model – build a high‑performing team, then rotate projects

The third approach – and the one I personally prefer – is a team‑first model.

You start with the question: “What would it take to build a high‑performing team?”
Then you optimise around that, not around individual projects.

What this looks like

• You invest in a stable, cross‑functional team – engineers, QA, maybe design and product.
• You pay attention to mental and personality match, not only competences.
• You give the team time to go through the full Tuckman cycle and reach Performing.
• When a project ends or priorities change, you keep the team together – and let them pick up a new challenge.

In this model, projects are temporary, teams are durable.

The team might work on Project A for 18 months, then switch to Project B or a new problem space, but they stay as one unit. The context changes, but the core relationships and ways of working remain.

Why this works better in practice

A team‑first model supports all three “3Ps” from What Is Engineering Leadership?:

• Product – the team builds deep meta‑skills: discovery, delivery, learning from metrics. They can apply them to new product areas.
• Process – rituals, communication patterns, and decision frameworks mature over time. You don’t reset them every quarter.
• People – trust grows, feedback flows, delegation becomes natural. People feel safe and connected.

It also connects strongly with the idea of Multipliers from Mental Models for Engineering Leadership. A high‑performing, stable team multiplies its own impact when you move it to a new problem – without starting from zero.

And finally, it matches a simple truth about our industry:

Projects are not babies.
They are containers for value in a given moment, not extensions of your identity.

Projects can change, pivot, or die. The world of software is full of shifts. If you bind people too tightly to one project, those shifts hurt. If you build strong teams and treat projects as assignments, not identities, you stay flexible without breaking trust.

Choosing (and moving towards) a team‑first model

You might be reading this from inside a project‑centric or matrix organisation and think:
“Nice theory, but we’re not there.”

You don’t have to flip the whole company at once. As an engineering leader you can start with your local environment.

Practical steps you can take

• Name the model you want. With your manager and product partners, share the difference between project‑bound, matrix, and team‑first. Use concrete examples.
• Protect team stability where possible. When new work appears, try to assign it to an existing team instead of creating a temporary “task force” from random people.
• Design for cross‑functionality. Bring the key roles into the team, even if on partial allocation at the beginning. Reduce dependencies on external queues.
• Invest deliberately in team development. Use retros, clear operating manuals, and tools like FUKO feedback or the delegation framework (Effective Delegation Framework) to strengthen how the team collaborates.
• Challenge constant shuffling. When someone proposes moving people around “for efficiency”, ask: “What will this do to our ability to reach and stay in the Performing phase?”

You may not control the whole org design, but you do influence how your team experiences it.

Final thoughts

How you organise teams and projects is not just an operational detail. It defines whether people feel part of something stable, whether they can grow into high performance, and how resilient your organisation is when priorities change.

Project‑bound teams offer focus but risk tying people’s identity and success to a single initiative. Matrix models can look efficient while quietly damaging trust and performance. A team‑first approach takes more patience at the beginning, but pays back through stronger ownership, faster learning, and better long‑term outcomes.

If you’re leading today, ask yourself:
Is your organisation built around projects – or around teams? And what would it take to move one small step closer to a team‑first model this quarter?