How Many Teams?
How many software teams can you lead or manage?
With a single team, you can usually both manage and code, balancing your time between engaging with team members and working on your personal projects. Often this is still possible when you manage a couple of teams, particularly if the programming domains are closely related. But combining management responsibilities with engineering duties does not scale. At some point, it does not make sense to attempt to be both an individual contributor and a manager of a set of teams. You become a bottleneck.
If you are a purely technical leader without any management responsibilities, it might appear that you can scale indefinitely. As a software architect, for example, you can provide the technical direction for many teams. But the way in which you provide technical leadership needs to change if you are to effectively guide larger groups of engineers. When projects reach a certain scale, you can no longer code all the key solutions or specify the entire design in fine granularity.
Possible Approaches
One approach to resolving this conundrum is to work longer and harder. Recognition of hard work is often why people are placed in leadership roles in the first place. Your teams and management may be used to you doing everything—it’s like a habit that is hard to break. The problem is that ability to scale in this way is inverse to your ability to have a life and sleep. Mere mortals can do only so much. Rely on this technique only for short-term emergencies. If this is the status quo, you should consider a different position.
The classic approach is to designate lieutenants—managers and/or leaders to whom you give advice and guidance, trusting them to work effectively with your teams. Delegation can work extremely well, particularly if you have good leaders, provide them with useful training, and give them clear guidance.
Self-organizing software teams handle much of the organizational, process, and technical needs for themselves. In this scheme, everyone on the team is a leader, and the team requires appropriate training and (as always) clear guidance. It is a particularly useful approach for software engineering when management and leadership experience is in short supply. It can take much of the pressure off the managers and technical leaders as it requires only a light touch.
Provide your teams with clear direction, prepare them with training on any technical areas, coach them on all processes, and they can manage themselves. You will need to step in only if they need assistance. In this way, you can manage many teams, and any managers and leaders reporting to you will also scale.
The Agile Manifesto
If you have any background with Agile techniques, the concept of self-organizing teams might be stirring some of your neurons. This concept is part of the Agile Alliance’s Agile Manifesto:
The best architectures, requirements, and designs emerge from self-organizing teams.
While researching for this post, I discovered that Mike Cohn, a founding member of the Alliance, had recently posted an excellent article on self-organizing teams.
The original Agile Manifesto focused on the technical and architectural benefits of self-organizing teams, but Mike Cohn’s recent post focuses more on the organizational and team wins. The nature of my blog means I focus on the team, leadership, and management aspects.
Making It Work
Occasionally, teams will naturally self-organize. This can happen with motivated teams containing experienced members. You need to give these teams clear guidance, then get out of their way.
Most teams are not ready to fly “solo” without some mentoring. Spend time with your teams to ensure that you understand what level they are at and what they need to learn—whether it is domain knowledge, process expertise, technical training, interpersonal skills, or how to get things done at your company
Some suggestions:
- Challenging personalities, knowledge gaps, cliques, and unmotivated folks can all hinder the development of strong teams. Identify and address the people issues before they can stall the team’s progress.
- Encourage your teams to reach out to you (or others) when they realize they need assistance. Build trust with them, so that they feel it is safe to get help when it is truly necessary. A self-organizing team should develop a good sense of when they can handle issues autonomously and when they need outside assistance.
- A great way for teams (and people in general) to learn is to let them make mistakes and experience the consequences for themselves. My favorite analogy for this is “Let them stub their toes, but don’t let them cut their feet off.” If a team is about to make a minor mistake, you can speak up, point out the risk, and outline possible alternatives, but let them make the call. If the possible consequences are severe, you need to step in more forcefully. If you always need to step in, there is either a problem with you or the team.
- One reason engineers avoid management and other leadership roles is that they fear they will spend too much time on management and “people issues.” Train your team to be experts on managing themselves—they will be a joy to manage, and you will have an easier time bringing up the next generation of leaders.
- Providing clear, concise guidance is a skill that a strong leader must develop. Good guidance states what work is needed, but not (unless truly required) how to do the work. Software engineers, in particular, enjoy figuring out the “how” part.
Final Thoughts
Most teams crave ownership and independence. Allowing them to self-organize is not about tricking them into doing more work but rather handing them the control they desire.
You may have noticed that quite a bit of work is involved in fostering self-organizing teams. You will need to make an early investment in time and effort to boost your teams’ self-managing skills. Like many good investments, the returns may seem small in the beginning, but will compound over time.