Self-Organizing Teams
Table of Contents
This article is part of the Technical Manager Guide that I'm writing for technical leads to scale their development and be good leaders. Being a good manager is all about empowering & enabling your teammates.
Over the last three years, our small digital agency, has grown from only two developers to 50 smart people across various departments. We were doubling in size year over year, which brought us challenges in organizing multiple teams to work on different client projects.
There were conflicts, output issues, developer satisfaction issues, a high yearly employee turnover rate, and other problems that we had to solve. In terms of organizing people, the agency model is much more complicated compared to a product-based company where everyone is focused on one common goal all the time.
We started with the usual method of organizing work: Product owners talk with the client and then tell the teams what they need to do, and the teams do it. We quickly realized that this method is neither efficient nor in line with our core values of transparency and taking ownership of what you do.
To mitigate this, we made some drastic changes to the way we work: We've decided to go full force on self-organization, and we've put the teams in charge with everyone else in a support role to make sure they are not blocked. No more hierarchy, no more "you do this, you do that," more of "I will do this, and then I'll also do this," flat structure and direct cross-team communications.
From Bottlenecks to Team Ownership
We started shifting the paradigm of decision making โ instead of the management deciding where to go and what to do, we asked the team where they think it's more efficient to go.
If you hear a lot of "Go ask X for a decision" where X is a name that often comes up โ that means your structure is not efficient, and there's a single point of failure and a potential blocker. We still sometimes have this issue, but much less prevalent than in the last few years. I encourage people to make decisions independently. I trust them to find the best possible solution to the problem that they're facing.
The responsibility for the product (also a type of bottleneck) is never on a single person but always on the whole team. We don't want a single person to suffer from the stress of being responsible for the entire project. A shared burden is always easier to bear when teammates support each other and share the pressure.
The second thing that we focused on is treating our team members as adults. We do not babysit them with micromanagement to make sure they meet their deadlines, and we don't do constant tracking of hours to ensure they do their 8 hours per day. We're all grown-ups here. In a team where people are trying their hardest to deliver a fantastic product, someone who is not giving their 100% will be noticed very quickly. The people trust the management to make their life easier, and we trust them to function correctly.
ะ team at mindnow is usually seven to ten highly-skilled people across all areas of expertise โ design, communications, development โ a self-sufficient unit that can be parachuted into any project and start working on it with 100% efficiency within days. The team communicates with the client, decides on the backlog, determines what they will do as the next increment, and organizes itself, so the increment becomes possible.
We don't usually do fixed-price projects, but we make commitments to the scope that we can deliver in one sprint. This structure keeps the development agile and guarantees a specific increment and deadline.
Reaping the benefits
One of the cool things about self-organized teams is the team's emotional buy-in. The sense of comradery brings higher self-worth and growth for everyone involved. I've often seen people come to us from some outsourcing agency where they worked in a task-in-task-out environment. As soon as they feel the freedom within the team, they climb higher and higher โ more complex tasks, more confidence in their skills, more desire to step away from tunnel vision on a single ticket and view the system as a whole.
We did some exit interviews for such contractors, and they were always eager to come back to us โ that's how much they liked being in control to handle the problems.
I've realized that the team bonds a lot closer while solving messy cross-disciplinary tasks rather than just consuming tickets and processing them as part of a well-oiled machine. Sometimes having a bit of a mess is a good thing โ it allows people not to be afraid of making mistakes and move with confidence.
The benefits for management are straightforward:
My concern switched from being the know-it-all in all projects to putting the team together to take the product from zero to a hundred with proper product goals and constraints. I'm focusing on facilitating effective collaboration โ meaning I make sure that people know how to act when they don't have all the information. I also help handle any crisis in the development, give guidance with proper procedures and Iโm there as someone to lean on.
Breaking the old habits
As mentioned above, one of the most popular issues we face is that people are used to being given tickets and not overthinking about why they're doing the task or if it is really necessary.
Once you break this cycle and start asking them to take responsibility for the whole product, not just the task, there's much indecisiveness that pops out. That's why it's crucial to have senior people who have been with the company for a long time who can help them out and advise on how they should proceed. Not just telling them what to do, but showing them how to act.
Some more bad habits that I noticed that we needed to deal with:
- Avoid micromanagement altogether. Product owners should not be working against the development team looking over their shoulder and making sure they deliver but rather side by side. Their goal is to help them with the stuff that could be blocking them - good backlog, accurate client information, and a well-defined vision.
- Avoid unnecessary meetings that are a remnant of hierarchy where a leader gathers everyone and tells them what needs to be done - embrace asynchronous communication and discussion between peers. It's tough to give inputs when there are ten people in a meeting, and it's effortless to speak up in a Slack channel with a well-formulated message.
- During onboarding, mentorship should not happen in a top-down approach but rather exchanging experience with colleagues. New employees, especially junior developers, naturally look towards more experienced team members to help them figure out the best first steps.
Next steps
Each year we're getting closer and closer to building a proper Holacracy in the company. This will be our next evolution step that makes sense for any company trying to move away from traditional management forms. I'm currently in the phase where I'm trying to understand its ins and outs to make sure that we do a smooth transition.
We're also in the process of revamping the way our teams organize resources. One of the ideas that we have is that any developer should be able to join any squad with almost zero friction. That means the frameworks/libraries/documentation style/code style needs to be standardized across teams to ensure that everything is familiar. There may be different functionality but itโs still built with the tools that everyone knows.
As we are heavily reliant on human resources, it makes sense for us to offer everyone a revenue-sharing model in the future. It's way more fun building something, knowing that you will also get the % of the profits rather than just a fixed salary. We've already started work preparing for this in 2022.
Hopefully, we will be growing at the same pace and will onboard more cool people who will benefit from our way of working.
Thanks for reading! Here are some things I think you might like: