Back to Posts

Why small teams kick ass

Sometimes less is more: When you want to move fast forward, go small.

What is a small team?

In this case the term “small team” reflects on:

  • The team size: number of team members
  • An independent culture: the team is responsible for itself and it’s tasks
  • Consistency: team members stay the same over a certain time
  • Small team size does not equal small companies, even big companies can organize in small, independent teams to kick ass!


When humans work together there is no such thing as “the one truth”. The idea of one process that fit’s all companies might sound worth achieving but in reality it isn’t. SCRUM isn’t for everybody and so aren’t Kanban or Extreme Programming. And that is why those methods sometimes fail and sometimes work just fine.

Working together means you have to find some ways of organizing work. But if every process works doesn’t every team - how can you find the “perfect” process? Well, you doesn’t have to! There doesn’t have to be a finish line on your improvement as a team. For example: Some scenarios demand to prioritize speed, in others you need to focus on quality. Usually those priorities will change during the lifecycle of your product / project. You want to be able to adjust quickly to outside and inside circumstances. For that an open culture to allow failures and dispel fear of trying new things is very important.

With fewer team members you can try out new processes. Always identify weaknesses and strengths in your workflow to draw conclusions much faster. You simply get everybody on board in one call, not wait for every 50 people to have them read that memo.

Bonus: tools. tools. tools

If there is no “one size fits all” in processes – there can’t be one tool that fits every use case. Small independent teams can be more flexible in choosing the tools every individual needs to deliver good work. If you have ever been in touch with a IT-Department of a traditional company you know that flexibility is usually not their core strength.


As technology is evolving extremely fast these days and so many things are possible. It’s just not easy to get everybody on the same page and to actually talk about the same ideas. Communication is key - whether it’s spoken or written. Even when using the same words, you might not talk about the same ideas. So e.g. you might use mockups, images, descriptions, etc. to standardize requirements. In the end everybody on the team has to build her/his part that needs to fit together. The better your communication the easier this gets.

After a while you usually know each other and how your colleagues communicate. You better know what they want, when to ask them to specify something or you even know when to ask for their opinion. Make sure your team is diverse and consists of different people and opinions. Combining those views together and create great pieces of technology means you have to have a good culture of communication.

Working in smaller teams makes it much easier to adjust to others behavior and be more sensitive about others to move forward, together.


If we have learned something in the last years it’s that requirements change - especially when working with clients. The industry tries to embrace constant changes (e.g. agile movement, the devops idea, and more). And this is great! But you still need some kind of commitment.

Everybody has it’s own pace and mindset on how to tackle work. A good culture reflects that and gives everybody the chance to improve but not overstrain too much. “How much can we get done this week?” is only one part of the topic, but a very obvious one. If you work with other teams that rely on your output or you simply need to document to superiors, this is a very common “KPI”. When it comes to predictability within your team it is also quite interesting to agree on “How small do tasks need to be before we can get to work?”. Some people only need a rough idea, some others might need more details and smaller sub-tasks to be able to go concept from execution.

Whether you estimate in days, in points or other labels – and especially when you don’t estimate at all: At some point (mostly) you need to know what a team is capable of - which is simply much easier to measure and adjust when you have 4 people than 15.


Having a hierarchy or a flat organization doesn’t matter. At a certain point of team size, you have some kind of overhead. Overhead is that kind of activity that you need to keep the organization alive. Of course you want to minimize that.

The more people there are, the more needs to be organized, the more needs to be strictly structured. Bigger organizations compulsorily need to think more as a collective than to consider the individual human being. That doesn’t mean that such an organization is automatically cruel. But big teams demand more handovers of information, higher need for organizing daily business and e.g. in result more meetings.

Small teams make it easier to share knowledge, fewer need for a strict structure (“it just works”) and in result getting more work done!

photo credits: by clement127

Jonas is a technical product manager. He translates between developers and humans. Born in Germany he now likes to travel the world. His goal is to collect memories and meet new people instead of owning things.