There is no WHY in TEAM.

Nothing defines the success of a product more than the team that builds it. Without the right people and skills, nothing gets done. Well, nothing good at least…

From Jeff Bezos’s 2-pizza rule to cringe-worthy team building activities, a lot has been written about how to create the perfect team. Yet in most workplaces, we see a different reality.

We see teams formed around a singular vision: scaling. Most team building is an answer to the question: How can we do more of the same?

Teams are assembled top-down by a management that believes they can shape creative work. “Here at ACME, each team has 5 devs, 2 testers, 1 analyst and a project manager.“. You get to be self-organized as long as you organize yourself the way we tell you to.

Management will shift and shape teams as they see fit and while it’s no longer allowed to use the word “Resources”, rest assured they still calculate in FTE’s.

Old-School managers will tell you team building is extremely important and that people are the true assets of the company. But when they really need to push this sales report, they’re going to assign Sally to that. Don’t worry, a new guy starts on Monday and he’ll join to replace her. Win-win, no?

Corporate IT management is still sick with this 80’s factory mentality. The good news is that they are being outpaced by the companies that do understand teamwork.

So, how to design a good team?

Size matters

A team should be as small as possible. 4 is good, 2 is better. This feels counter-intuitive, but that’s the nature of creative work. Fewer people means easier and better communication. When Lennon and McCartney composed together, they got super productive. That’s much less likely when it’s all of the Beatles and their management. And a writer from the record company.

Some complex problems will require slightly larger teams, but that’s the exception, not the rule. In general, the pizzas should be small and the people very hungry.

Glorious purpose

A team should have a mission. Do they own a product? Can you describe in one sentence what this team does?
Too many people are stuck in Scope Farms. Their purpose is to build whatever is asked from them. No questions asked. It’s unproductive and a horrible waste of talent.
Every team has a purpose. This can be a project goal or the ownership of a product. It can be a small subset of a larger whole, but within those borders, they set the direction.

Without a mission, there is no team.

Be cross-functional or go home

One of the laziest ways to circumvent the 2-pizza rule is splitting up teams by skillset. “After the Design team has delivered their wireframes, the Dev team starts working and then …”.
This is a perversion of group dynamics! Technically you have 2 smaller teams, but they are painfully connected to each other. You’ll optimize so that analysts can spew out as many JIRA tickets as possible. You’re not optimizing for a great product. If you see this siloed approach in your organisation, it’s time to sound the alarm!

A real team has all the skills to solve their problem. We don’t divide people into job titles but stimulate them to apply their complementary talents. Kim is not a developer. Kim is a person who is very skilled in software development. She also knows a thing or two about SEO. We don’t need 1 dev and 1 SEO specialist. We need Kim.


Management consultants love to put “Self-organizing” on their slides. It means they are hip to the modern lingo. Most of the time, it’s BS.

Here is the real test for self-organising teams: Do they get to choose their scope? Can they pick their members?

If you have to work with JIRA and you have to follow a synchronized 2-week sprint, you’re not in an autonomous team.

A self-organizing team has agency. They can pick their own tools, methodology, scope, deadlines and team size. If that makes your stomach a bit queasy, you don’t believe in self-organization.

A self-organized team on a mission will move the world. Give them a problem and they will come up with a solution. It will never be the solution you had in mind. That’s great! That’s why you invest in this team.

To the Old-School, this sounds terrible. They are used to a siloed approach where a conductor orchestrates all the parts to play the symphony that’s on the sheet.
Stakeholders who believe they can come up with a better solution are delusional. They are going up against a team that was custom made to solve this specific problem.

They are no match. They will lose.

Building software is hard, but don't let that stop you.

If you're building a product and feel like you could use a supportive techie in your corner, let's set up a quick chat to see if I can help you.