SoftwareMill team playing paintball during one of our retreats.

There are many successful companies like Buffer, GitLab, Doist that develop their own product and are 100% remote. Our case is a bit different, as apart from being 100% remote, we develop software for clients and we work in self-organizing teams. Information about how to set up this type of work so that your team is successful is scarce. We want to share our lessons learned from 10 years of experience in such a model of work.

SoftwareMill has always run as a fully remote team. We’ve grown from 4 founders to 60 people working remotely, developing software for clients. If you’re looking for tips on how to organize the work of a 100% remote team, we’ve written a bunch of articles and an ebook for new people joining our team that focus solely on that aspect of our work. But if you want to dig into the details of how one could set up a self-organizing team so that it successfully delivers then this reading is for you.

Why self-organize

It’s quite unusual for software development teams not to have a team lead/project manager role in a team. The common belief is that there is a need for a dedicated person organizing the work and being an intermediary between a team and a client. SoftwareMill went upstream from day one. Its founders decided to go with self-organizing teams as they believed it was the best model both for developers and clients on one condition. Developers working on a project need to be senior/mid — with a few years of experience in commercial software development. Thanks to that experience they’re equipped with best practices, self-discipline and ability to take on full responsibility for the project.

What you get as a developer

Self-organizing team lets you get rid of a buffer between you and a client which usually creates lots of unnecessary communication noise. It’s much faster and easier to communicate, make decisions and discuss anything when you talk directly to your client.

The fact that all team members are exposed to communication with a client increases the chances of spotting any miscommunication.

Everyone in the team understands the broader context of the project which makes decision making a lot faster and easier.

Finally, working directly with a client gives the team members more impact on the project, as it’s easier and faster to persuade the client to different solutions and results in higher motivation within the team.

What you get as a client

Removing any buffer between you and the team is just equally beneficial for you. You talk directly with people who actually work on your project which makes the communication a lot easier and more effective.

All the decisions in the project are made by the people equipped with the best possible knowledge — they have a good understanding of the project’s context plus they’re the experts responsible for implementing the actual solution.

Finally, it’s also for your advantage that the team feels fully engaged in a project thanks to the fact that they are close to the decision-maker and being able to influence your process of software development.

5 ingredients of a successful self-organizing team

Our story shows that it’s possible to successfully deliver software working in distributed, self-organizing teams. Over the years we’ve learned that there are five important elements of making it work: the right hires, the size of a team, complementary personalities and experience, transparent communication and people empowerment.

Hire the right people

Hiring is one of the top priority processes in our organization. It not only keeps everyone in the company engaged in the recruitment but also spans throughout 5 stages from an initial web form, through a phone interview, coding assignment, technical interview up to an informal meeting over lunch.

Mary and Magda enjoying a boat trip during one of our retreats.

We keep our process meticulous so that we’re sure that we’re hiring people with really high work ethics, coding standards and that fit our culture. These two things play a huge role in a successful self-organizing team.

2. Stick to 2 pizza rule

Our teams comprise of 3–8 people following the Jeff Bezos’ rule that says that the most efficient teams should consist of that many people who could be fed with two pizzas. Especially in a remote setting, it’s important to keep teams small so that the communication is smooth and everyone shares the responsibility for the end result.

3. Have a mix of different backgrounds and personalities

We tend to mix people with different levels of professional experience. Neither a team of newbies, nor a team of veterans is a good idea. Self-organizing team means that all team members are sharing the communication and coordination in the project which is usually handled by a project manager. It’s important to have people who could learn from each other and inspire each other on how to work together.

Self-organizing teams playing an Arrow Tag game.

Another aspect that we found profoundly important is the combination of personality types in the team. Just recently, the whole company has adopted the FRIS® methodology which describes people’s different styles of thinking. Being aware of the role they play in group dynamics and knowing our team members’ styles of thinking, we’re able to build teams which members complement each other.

4. Keep the communication transparent

Communication is our lifeblood. We keep on improving it every day and always stay on the watch out for any inefficiencies. Transparency is rule number one. Whenever we communicate with a client we try to use the channel accessible to everyone in the team. We’re using a public channel on Slack instead of a private message, we add everyone in the CC when sending an email or simply debrief the rest of the team after a meeting.

Sharing communication with a client with all team members comes at a cost. These are small, additional tasks like sending an update or taking part in a meeting. We try to distribute such tasks evenly among the team to avoid one person being overloaded. Especially new people in the team need some support and guidance on how to get engaged with it and how to start taking over such tasks from people with more experience.

5. Empower people

The more autonomy a self-organizing team is granted, the more successful a project. Of course, there are some limits imposed by our clients’ setup or project’s requirements. But in general, that teams which can decide about the toolstack they’re using or the way they’re organized tend to become the most productive and successful ones.

Maciek getting ready for the game.

6. Share the ownership

Make sure you share everything within a team. Even if you start a new initiative or come up with a new tool for your project, include everyone and teach them how it works and how to use it. Include everyone in the decision-making process. You want your team to feel ownership of every decision that’s being made. Avoid dividing the project into independent areas where people work alone. The more dependencies you have and the more people exchange know-how, skills, and experience, the better for your project.

How to make decisions in a self-organizing team

Making decisions in a team with no official team leader or project manager is one of the biggest challenges in this model. It could easily lead to a deadlock when people are not sure what to do or get stuck in endless discussions.

SoftwareMill team discussing their tactics during an Arrow Tag game.

When we need to make a difficult decision and the team is divided, we start with a discussion where two sides are trying to convince one another. Sometimes, it takes one person to make the decision. It could be the one who has more experience in a particular domain or a project. It could be the one who will be implementing the solution or simply the one willing to take on the responsibility.

If that’s however not the case and the decision needs to be made by the whole group, we start with a brainstorm during which solutions get bombarded with “what if” arguments. If that doesn’t lead to a decision, we come up with a compromise. We agree on the solutions that “are good enough” and pick one of them. We know that in software development there are usually a few good solutions to every problem and the power lies in becoming efficient in the decision making and not overthinking the hypothetical situations.