Self-managing Teams: a Growth Strategy Tip for 2022

Creating self-managing teams might be the secret sauce to growing your company in a sustainable way that is fulfilling for everyone involved. 

When you start your company

Imagine you've just started your own company: you’re a two-man army, and no longer “just a freelancer”. You win another project and you realize you need a bigger team. You start recruiting people. A few months later, you get another project, and another, so you hire more and more people.

Because of hiring you’ve gained so much non-project related work that you are flooded with papers and administrative stuff. You appoint yourself as the CEO to keep track and let others do their jobs. You think to yourself: IT people don’t need many people in Operations - surely they can self-manage and solve all of the problems in real-time with one another. After all, it’s not that many of them. As it turns out, there’s actually plenty to do.

As a whole company, you need to handle:

• recruitment,
• sales,
• tech consultations,
• promotions,
• marketing (and in a very crowded market to keep more projects coming).

There are some people who believe it’s technically possible to do all this and not die along the way, but I’m yet to see it with my own eyes. So what can you actually do?

When you start to grow

You promote people internally and hire experts to take care of all these aspects of the company’s life, and to keep the company growing. You need to recruit more people to take care of your projects, but when those projects are finished, you need to sustain the people you hired and give them a new project. So you need sales. Sales on a larger scale is impossible with little or no marketing efforts, so you hire those specialists too.

To keep your tech employees happy you promote someone whose experience and expertise you trust to become a CTO and take care of the feedback and all other stuff for you.

Scaling your company is realizing you can't do everything by yourself, and giving your employees trust and integrity to deliver their tasks. 

Your role now is to help everyone do their jobs and facilitate teams’ work day to day. The next step is probably to hire more developers, designers, more Ops to keep it all flowing. You’re planning on scaling the team twice the size it is at the time, but there appears to be a problem.

Necessary role differentiation

Your CTO needs to make up about 30 promotions and raise decisions in the next quarterly review.

And also, he has no real idea on how to evaluate the designers’ work. Even if he tried really hard, they wouldn’t be too content to hear feedback from a person who hasn’t designed anything in their life. So you promote someone to a Lead Designer position. Now, the CTO has half the people to evaluate. The juices are flowing again.

All seems to go according to plan, but a year later you notice you’re facing yet another problem.

The team grew, you introduced new Team Leads for Web & Mobile and your CTO moved totally from evaluation processes. But you start to notice something new: it’s getting really hard to grow any further. People start arguing more, some of them even leave, you lose stability, experience, and may even lose some clients. What’s happening? 

The invaluable role of feedback

You start to gather feedback from your teams and see the communication issues within the teams. Developers might not like working with designers and vice versa, people might feel unimportant (since you’ve been growing the company, people might lose connection with each other), and they might feel like they’re not learning enough (e.g. if they are in the same project for too long, or maybe organizing bottom-up initiatives in a scaled setting with more people is harder than it’s been before).

How do you fix these problems your team is mentioning? The answer is, unfortunately, discouraging. Because you may never fully know - there’s no one golden rule that applies to every situation, and it really just depends. But gathering feedback is the key element of detecting the cause.

Here are the issues mentioned above, but this time grouped by category:

• Cross-team issues,
• Lack of knowledge sharing
• Company structure - no growth & learning perspective for individual employees,
• Heavy dependence on few individuals
• Money

What are the conclusions from the feedback you gathered?

We don’t see many inside-teams problems. People have less criticism for their project’s colleagues, people they know and work with. Similarly, we don’t get too much negative feedback from people in the same tech department (like inside web, mobile etc). It’s always outside the teams people know or associate with.

Long story short: in growing companies, people may feel detached from others, unless you find a way to bind them together again.

It turns out that science identified this issue, and even suggested a solution for it. In 1981, it was proved that people working in smaller groups have more interactions, they are more cohesive, and have a higher job satisfaction than the less specialized and bigger groups with no real common denominator.

The solution is already there.

Stop grouping people by tech or specialty, and rather build cross-functional smaller teams that are equally represented. For example: one mobile developer might feel underrepresented in a group with 4-5 frontend and backend developers.

Self-management solves some of the scaling company's problems 

Issue solved: Cross-team misunderstandings

• There are less occurrences of cross-team issues because you can keep different teams in closer contact.
• People identify with their team more than they identify with their technology (which used to be the only common denominator).
• Wait-times for getting things done together drops down significantly. 

Issue solved: lack of knowledge sharing

• It's easier to set up initiatives in smaller groups rather than for whole company.
• Teams' ideas can be escalated by Team Leads easily.
• Knowledge can travel more easily between people using different technologies. 

Issue solved: no growth & learning perspective

• New possibilities for leadership roles in teams appear. 
• If you don’t see yourself as part of a team you don’t have to leave the company - you can switch teams.

Issue solved: dependence on few individuals (CEO, CTO)

• A humbling note: CEOs & CTOs involvement in certain tasks can't always be omitted. 
• But: the new setup promotes a more natural growth path for new potential leaders.
• People are less concerned about one person leaving & blowing up the whole company, because of common ownership. Thanks to teams' ownership, nothing relies solely on one person. 

Thanks to introducing self-management CTO's workload shrinks and is more specialized than before. It makes it easier to focus on growth and minimizes the risk of CTO's being flooded with administrative tasks that could be handled on a lower Team Lead's level of ownership.

Below you can find a quick depiction of how it could look like in practice: 

CTO's responsibilities before the change:

• Evaluate and monitor progress of all technical team members
• Provide environment for team members to grow
• Recruit new team members
• Handle small fires
• Handle big fires
• Make strategic technical decisions
• Organize time for developers in between commercial projects
• Share technical knowledge, and more

Team Leads' responsibilities after the change

• Evaluate and monitor progress of team members
• Provide environment for team members to grow
• Recruit new team members
• Handle small fires
• In case of big fires, escalate, and a few more...

How to make self-managing teams a successful transition?

Facilitation

At EL Passion, we created a set of specific norms for teams to follow, because, at least in our experience, having no guidance at all always results in chaos, and sometimes people deliver the same work doubling each other efforts.

We developed processes that allow groups to share their problems and search for solutions together, learning from each other. We ensured the teams are treated equally, and not recognizing only the loudest and more confident team leaders and team members. But most importantly: we tried to keep the meeting rate as low as possible, to let people work on their own and at their own pace and to avoid over-facilitation of the whole process.

Coaching & mentoring

We organized workshops for our team leaders and managers so they can actually learn the good and the bad ways to manage their teams day-to-day. Not every developer is a great manager, and also the skill set of a good manager may differ for smaller 4 person teams and the bigger self-managing ones that already have experience.

An important element of the transition is not to be afraid to slow things down a bit, until all managers feel comfortable enough at their role to actually step into action. Iteration and taking things rather slowly can bring you better results than going fast (which is usually clumsy, especially at the first try).

Teaching

Inspire others to never cease to learn: managers and teams can both learn from each other, if they allow it, and if you allow it to happen. This is probably the secret sauce of the transition. This, and actually letting people fail.

Don’t try to find readily available solutions to all your teams’ problems, sometimes you just need to let go and again - let them learn. In the long way, it will be more beneficial for you, and for your teams. Failing is sometimes the only way to success.

Summary

Introducing cross-functional and self-managing teams when scaling your company can help you reduce general scaling obstacles like: feeling of exclusion, chaos, lack of processes. The dependence on very few individuals at the company is reduced, and all responsibilities can be equally distributed among Team Leaders and management. 

Check out also

• Self-managing Teams: Benefits, Challenges, and Our Strategy - Self-management is one of the key concepts in agile software development and agile project management.