Managers and executives are in the business of managing people and resources. Because many of our models for organization are built with the assumption that there's a manager involved, there's an expectation that there's some level of control over all the moving parts of the mechanisms we build. And for that reason, when you propose the idea of self-organizing teams to a manager, the response is often that it's just not possible. Surely everything will spin out of control. Surely the only way to maintain momentum and direction is through the guidance of a project manager and a technical manager.
It's not just management that gets confounded by the concept of self-organizing teams, though. It can give pause to team members, too. After all, in traditional organizations a developer only needs to deal with the technical manager. However, in a self-organizing team, a developer has to face at least seven or eight pairs of eyes (their team members.) That can be a pretty overwhelming prospect.
Is it possible for self-organizing teams to thrive?
Take the example of a team I have coached. One day at a daily standup meeting, a technical manager stood behind the team without saying a word.
Leeroy: "I have no tasks to claim today."
Jenkins: "Why? There's one unclaimed task."
Leeroy: "That one? I'm not sure what its requirements are."
Jenkins: "Why didn't you mention you weren't clear in the backlog refinement meeting?"
Leeroy: "There were so many people at the meeting, it was noisy, and I wasn't able to hear clearly."
Jenkins: "So why is everyone clear about its requirement except you?"
Leeroy: "Well…"
Jenkins: "You've mentioned before that you could support testing in addition to coding, haven’t you? You can go do testing."
Leeroy: "Alright!"
See, in a self-organizing team, everyone is accountable for the goal of the whole team, and everyone sees each other. It used to be that the technical manager was in charge of such arrangements, but now things get done without the technical manager even having to talk. The technical manager can cut out his micromanagement efforts and do what's more needed of them.
Work visualization
Self-organization doesn't mean you let everything go. You have to visualize your work while self-organizing.
In traditional organizations, a team member's work was in a "black box". What happens depends on how frequently the technical manager asked about it, and how honestly the team member answered. However, in a self-organizing team, the team's work is crystal clear. Whether it's on a physical task board, or in an electronic system, whoever wants to know the real-time status is able to find out, and without interrupting anyone else's work.
With such transparency in your work, do you still worry about projects getting out of control? In a self-organized team, you're able to analyze all kinds of data to find problems, and then take action to correct them over time. With self-organization, control is not weakened but enhanced.
Servant leadership
A manager still may be left wondering, "If everyone self-organizes, who do I organize? What's the value of my position?"
Self-organization is not the absence of management, nor does it require no management. It's instead the change of management style.
Without the burden of micromanagement, technical managers can create a good environment for the growth of team members. This includes:
Technical experts
With years of experience and deep knowledge of technology, the technical manager can take on the role of a technical expert. You could participate in technical reviews and code walkthroughs, as well as technical practices and technical platform improvements.
Take another example from a team I have coached:
One of the team members didn't adapt to new changes as easily as expected. He said that all of a sudden there was no one to assign him tasks, no one to do the detailed design. He felt that he had to start everything on his own.
To solve this problem, it was decided to form a technical advisory group consisting of the technical manager and several senior developers. However, the technical advisory group wasn't responsible for assigning tasks or for providing active supervision, it served only to provide support when team members needed advice or reviews. It allowed everyone to move away from the old working model and transition to a new working model, improving their overall competence and self-confidence.
In fact, technical managers reportedly feel more relaxed in the new working model. In the past, their subordinates just performed mechanical implementation or even dealt with the tasks assigned by the technical manager in a perfunctory way. All the pressure was on the technical manager's side.
In a self-organizing team, the pressure is shared by the whole team. Everyone's sense of responsibility is enhanced. The team discusses a problem together to make the solution more comprehensive and reliable.
Metrics drive
You might imagine a scrum master reacting to this concept with some reservation: "We can't move too fast. Now that we're self-organizing, each task in each iteration has no one to specify when it must be started and when it must be finished, and it's really getting a little out of control".
Self-organization is the final goal, not the starting point. You can't achieve self-organization in a few seconds, and it's not something you declare once and then forget about.
Instead of having to traditionally micromanage a team's work by giving them instructions at every step, scrum masters let everyone take initiative. However, scrum masters need to refine statistics and analysis of the data in every iteration to find where there's room for improvement. You might analyze whether everyone's schedule is reasonable, whether there are deviations from expected progress, and whether a task split is more conducive to cooperation. Through these analyses, scrum masters are able to help teams improve their self-management, as well as team's self-organization.
Coaching
Coaching isn't a way to reveal answers directly, nor is it a command-and-control instruction set. The subject of coaching has to solve problems, but the scrum master guides and inspires a team member to recognize potential improvement points and avenues that may lead to an innovative solution.
[ Related read: What's the difference between a manager and a coach? ]
The truth about self-organization
Self-organization requires effort and it requires skill. Ultimately, it builds stronger teams of stronger individuals.
Here are the important principles to keep in mind:
- Create a blame-free working environment
- Help to apply for budget for team building
- Establish a proper mechanism to encourage everyone to read more and share more
- Establish a proper valuation mechanism to help improve professional skills
- Self-organization doesn't mean you can play it any way you want.
- Self-organization is not the absence of management, but the change of management style.
- Self-organization is not the absence of rules, but self-driven under commonly agreed rules.
- Self-organization is not worry-free, but team members from all levels input greater and work hard for a common goal.
- Self-organization doesn't mean that leaders can be hands-off bosses. In means they get closer to teams, and provide more support.
This article is translated from Xu Dongwei's blog and is republished with permission.
Comments are closed.