Does every team always need a leader? Can a self-organizing team be successful? It’s a common truth that there’s no way a project can succeed if nobody’s in charge. It’s just a natural way of how people work: they get tasks, they’re supervised in the process, and then their work is reviewed. Work has been like that for ages and we’ve grown used to such professional patterns both as workers and leaders. It’s fine. It is fine. Or is it?
“New’’ trends in management and leadership prove that some common beliefs about how teamwork should be organized belong in the past. I say ‘’new’’ because they’re not that new in reality: great leaders have always been around, but luckily now true leadership is a trending topic. Organizational silo and traditional hierarchical structure are slowly moving out of workplaces. In our article about DevOps, we’ve already shared our thoughts on why we don’t believe in silo. And now we want to talk about some misconceptions surrounding self-organization, the prerequisites to achieving self-organization within development teams, and what benefits can be derived from it.
What is self-organization?
One of the pivotal aspects of a successful Agile setup is to have self-organizing development teams. It is even mentioned in the Agile Manifesto itself: “The best architectures, requirements, and designs emerge from self-organizing teams.” But ‘’self-organization’’ as a concept has a very wide definition. It can mean a lot of things, so how do you define whether the team is self-organizing?
Let me describe what I mean when I say ‘’self-organizing team’’.
1. Decision-making authority & ownership
A self-organized team doesn’t have to be told how to do stuff. They’re not robots fulfilling the client’s requirements, they actually shape the way the final product will look. If a team is made up of individuals who take responsibility for their work, they will not wait for anyone to provide them with a to-do list and detailed instructions on how to do it. This sense of ownership is helpful throughout the development process – when the team knows they have influence on the product development and they can help improve it, they’re more committed.
2. Teamwork & collaboration
The team is assigned some task but nobody makes them do it in a certain way. They have to decide how to divide the work, estimate it, make some elements work well together. Teamwork is a big part of the process, as they’re not going to achieve much working as individuals. Additionally, they have to remember to collaborate with the product owner to make sure that all requirements are well-understood, so the client’s expectations can be met. Communication within and outside the team is a must.
3. Trust & respect
As mentioned above, communication is a must. But it’s not just any communication. We all know that teamwork is much more than a few people sitting together by one table. If any team member is disrespectful, others may not want to ask such a person for help or help them. When they don’t trust each other, they may want to control what the others do. In a perfect team, though, all members will communicate freely, talk about the issues, and help each other in order to achieve a common goal.
For me, these 3 characteristics are typical of self-organizing teams. But with all the perks come some fears, too. As self-organization encourages independence and self-sufficiency within a team, it may be feared that the team takes it to an extreme. What are some misconceptions surrounding the topic of such teams?
It’s the team’s job to decide everything
There is some decision-making authority, that’s true, but some is the key word here. The extent to which the team may decide about the project is something the evolves over time. Does the project manager disappear completely? No, but a lot depends on team maturity. If it’s a newly created team we’re talking about, they need some guidance. Is there going to be any structure within their team? Are there any processes they should implement? These are some of the things that should be discussed with the team before they get to start working together. After a while, they will learn who does what and they’re not going to need as much support from any ‘’outer’’ party.
When it comes to the product that’s being developed, the team is not omniscient, either. When they decide something, they do it with best intentions. Let’s say: they want to change a technology that was initially suggested to be used in the project. They know an alternative that will make the development process faster, so they decide to go for their choice. And all is great. But the team’s self-reliance is restricted in some ways. Any decision made along project development will affect the outcome – so also the client’s business. That’s why there need to be some frames within which the team can actually be self-contained. Some accountabilities regarding business matters will still be left for the managers.
You can’t tell a self-organizing team what to do
This belief probably comes from ‘’self-organization’’ weaponized in its most extreme form. The thing is, this form does not really exist in reality. Being a part of a project, every team member bears in mind that they have certain things to do in it. They know what to do, as they have the requirements, but they can find their own ways of achieving the goals, as long as they don’t lose sight of the client’s objective. If they get off track and distract themselves with matters of lower importance, you can tell them to do thing A instead.
Is there a risk that the team won’t listen? They’re self-organized, after all, they make all the decisions. Is it a risk? Yes. But I wouldn’t say the probability is high. If a team is self-organized, they’re also responsible and respectful. Sure, some developers may go through a teenage ‘’don’t tell me what to do!’’ phase, but in the end, they all realize that they should make decisions about matters within their expertise and not take on any additional responsibility.
So is there no leader?
Even though we now know that self-organization doesn’t equal absolute power, it’s hard to imagine the role of a leader in such a team. Is there any place for a manager there?
There are some people in the Agile community who believe that the position of a manager is obsolete. If the organization revolves around self-organizing teams, there should be no need for any additional management. When teams become self-organizing, why don’t we go a step further and make them self-managing?
This may be a thing, but I’m not convinced.
It’s great when a developer understands business as well, but should we really require every team to basically run a small company? As far as I appreciate entrepreneurial spirit in people, I still believe that sometimes it is just too much. The boundaries of self-reliance of each team are rather individual, but they definitely should not be responsible for everything.
Being self-organized, they’re still not on their own. A leader is not there to manage people on daily basis but to provide guidance and watch over team productivity. If there is any impediment to self-organization, a manager will then step in to shake things up, but they’ll still do it in a subtle way.
Think of it this way: you’re in a car, taking a trip with some of your friends. You’re sitting all laid-back in the passenger’s seat and your friend is driving. You know how to drive but you’re not the driver this time, so you’ve no control over the car. Suddenly, a deer jumps onto the road right in front of your car and freezes in panic. Consciously, you know what to do in such a situation, but it’s your friend who needs to react right. You can tell them what to do, but you can’t do it yourself.
That’s similar to how management works in self-organizing teams: you can navigate, but you’re not in total control. The manager decides what product will be developed, who will be on what team. They may also provide the team with some general standards that will help set the tone of future teamwork. Then, the manager’s role is to observe and influence the team in indirect ways in order to hone collaboration.
How to encourage self-organization?
Making teams self-organizing may be a piece of cake or a hard nut to crack, depending on what kind of people you work with. Some people are used to having a boss who’d tell them exactly what to do and changing their mindset may be a challenge. There are a few things, though, that can be done to help create self-organizing teams.
Implementing self-organization in your team can be divided into three steps:
Training – Coaching – Mentoring
Training
It’s important to make sure that all team members have the desired skillset. As an employer, you should provide on-site training, both professional and behavioral, in order to prepare the team to self-organize.
Coaching
Once the team starts working together, the Scrum Master should provide them with support and guidance. The Scrum Master should keep their eyes open and observe the team in order to guide them towards solutions and provide need-based coaching.
Mentoring
When the team reaches the self-organizing mode, this state should be sustained. They don’t need ‘’command and control’’ but they should be given a mentor who will help them go to the next level.
Self-organization is not only a form of organizing work, it’s often a change in mindset. It requires a lot of maturity from people as they need to take on responsibility and commit. Managing your own work is often difficult, and making it work in sync with the rest of the team may be challenging at first. This is why it’s crucial to stand by some values represented by all team members. Is there a common ground for all them, matching them in a successful team will be less of a struggle. What shared values should they all have?
Self-organization is not only a form of organizing work, it’s often a change in mindset. It requires a lot of maturity from people as they need to take on responsibility and commit.
Trust, transparency, and confidence
Trust is a must in every team. Without it, there is no team, there’s only a group of individuals.
Transparency is essential on many levels. First of all, communication within the team, the company, and with the client should always be 100% transparent. Requirements should be well-understood, doubts should be done away with, problems discussed. It’s also crucial that the team members can share constructive feedback with one another. They should be able to point the areas for improvement, but also praise their teammates when they’ve done something great.
But what about confidence? This sounds ambiguous. I mean confidence in a few ways: first of all, confidence in their own skills. The team members have to be aware of the fact that they’re fine on their own. They’re not left alone, of course, but they are mostly self-reliant, and they should know that. Secondly, they should have confidence in one another. If they trust each other and have confidence that together they can figure it all out, they will be more successful. And then, there comes… overconfidence. This one should never be let in to any team. It’s great to boost confidence in younger team members, but it’s also imperative that the more senior ones don’t feel overconfident. The more experienced developers may tend to take leadership in a team and that’s fine, as long as they take into account the opinions of their mates: and the younger guys have a fresher look on many matters and a lot of excitement for discovery. The clue is to make the team balanced.
A ‘’balanced’’ team means one that allows different levels of seniority and crossed skillsets to best answer the client’s needs. And if the team is to be balanced, it’s also crucial that all roles are understood in just the right way. As you may be guessing, traditional definitions of the roles will not be fully applicable here.
A developer is traditionally seen as the person responsible for writing the code. In a self-organizing team, however, they will have to be a little more creative and think about the best way to implement a solution, challenge existing solutions, provide expert advice, and organize their own work.
QA engineers are not only responsible for testing anymore, their role is growing, as you can read in our previous article: Why Test? The importance of software quality assurance. Now QA specialists help make sure that the requirements are comprehensible, suggest UX changes, challenge solutions, and track inconsistencies in projects.
What about project managers? Ideally, it wouldn’t be a manager but a Scrum Master who should be mainly responsible for scrum rituals, facilitating communication, and providing guidance. In reality, though, there is a whole variety of projects with an even bigger variety of needs, so a PM will naturally have to divide some tasks between team members or manage communication. The road to self-organization may be a bumpy one, but with each iteration, all team members learn from their new experiences and work out the best way for them to work together.
Is it good for every team?
It would be unfair to say that self-organization is a perfect solution for everyone. We know what reality is like: there are some people who really want to stick to their original roles and not get involved in different activities. There are some challenges that organizations may face while trying to make teams self-organize, starting with the lack of initiative to do so, through the maturity of the team. The beginning may be difficult, but isn’t it like that with every change that is introduced? Summing up: no solution is universally good for everyone. There are certain benefits of self-organizing teams, including agility, speed of work, spending less time focusing on management and more focusing on the client, and building a culture of true collaboration. All these contribute to the ultimate goal of customer satisfaction but also employee satisfaction as all team member commit to the project and see the purpose of their work. But is this solution the best? I’ll leave the answer to you.
