Software Leadership – From chaos to self-organization

Starting software projects with a new team can be overwhelming. In between achieving customer satisfaction and meeting sales expectations; there is the challenge of aligning skills and expertise for success. This article breaks down various stages of a software project and how team organization can affect the outcome.

Software teams are highly dynamic – they have a vast set of skills with varying depth of expertise among members. Pulling a dream team together with precise skillset and expertise is never the case. A Software developer invests months, if not years, in developing a skill i.e., learning a language or getting hand of a toolset.

Often an individual must make quick shifts to alternatives; either due to client demands or following peer’s popular toolbox. Moreover, personal career goals can deviate from project demand.

The chaotic nature of software development

These aspects of software development effects the developer one or both ways:

1. Lack of Motivation

Frustration is natural when a developer knows their core skills are not enough to effectively contribute towards success of the project. Project kick-off is the worst time as the client demands and fast pace does not allow room for learning the new tools.

2. Lack of Inclusion

Motivated developers are strict on their personal goals, therefore any project that deviates from those become a second priority. This results in thinking they pose a hurdle for their peers, who are more skilled in handling the tasks.

This chaos explodes as a typical team consists of at least 2-6 developers, each wanting to pull the project within their area of expertise.

Learning and self-organization in software leadership

The amazing aspect of working with software teams is the instinct to learn. Someone with a background in software understands that tools and languages keep evolving. Early on, software developers get into the habit of continuous learning, thus making them experts in self-organization: creating own roadmaps, acknowledging technical debt, and building new capabilities.

A leader can tap into this learning instinct to drive the team to success. However, it takes time, effort, and dedication from the leader to create a learning environment where project goals align with developer’s personal goals. The eventual result is a self-organizing team equivalent of a well-oiled machine.

The three stages of becoming a self-organizing software team

It is important to remember that a project cannot by default start with a self-organizing team. There are typically three stages to reach a self-organizing team.

1.     Survival Stage

A good indication of being in survival stage is asking yourself the question: Can I send half the team on holidays for a few weeks? If the answer is never, then you are in survival stage. This is where a team culture takes shape; assignments agreed; and a communication structure, including with the client, established.

The most important job a leader should do is establish a clear line of communication not only among the team members but with themselves and the client. Let the team have direct relationship with the client, albeit in a command-and-control manner. The leader must dictate major technology and roadmap decisions. This allows for inclusion at a core level of your project.

A natural question is: how does being a dictator go along with feeling included? This is addressed by achieving self-organization as one of the project goals i.e., openly discussing how a learning team environment looks like and how the team is set to achieve it.

2.     Learning Stage

This is the stage where the team culture is beginning to take shape; the client already has seen results; and you do not have to rely on command-and-control anymore. The biggest challenge in this stage is team ossification i.e., the team is getting used to the rigid culture; happy with their assigned roles; and the workload does not seem challenging enough.

The cracks start appearing when the team faces an unexpected disaster (with software projects disaster is imminent). More often than we like, these situations happen when part of the team or client or the leader is unavailable. The team members must reorganize and stand up to the challenge. Sounds an awful lot like being thrown back to survival mode, which is precisely what is happening.

To avoid the vicious cycle, it is important that the leader becomes less of a dictator and focuses more on being a coach. Always anticipating a disaster, the leader should guide the team on being prepared:

1. A starting point would be cross-code reviews e.g., let the backend developers review frontend and vice-versa.
2. Following, cross-assignment can allow individuals to take tasks outside the comfort zone e.g., an SQL developer could write a small API.
3. The best method, if achievable, is to arrange a learning session. A paid-for course will boost morale as the developer knows they have a project to apply this gained knowledge.

Note that at this stage, the leader is a coach and not a dictator. Taking your team’s wishes into account is more important than assigning them a knowledge path by force. The goal is to create a learning environment that indirectly translates to giving up control.

3.     Self-Organizing Stage

Now that the team is set on a path of self-improvement, it is time to give them control. Let the team decide how they would like to shape the project. A functional team would know how to tackle problems; who to ask for help; and how to deal with disasters.

One key element that the team might be missing is to manage client expectations and keep client satisfaction up. Here, the leader would like to take time and build a stronger relationship between the team and the client.

An effective way to nurture this attitude is to ask the team for improvement ideas and moonshots. Challenge the team to produce their own roadmaps taking their peers into account. Have a productive debate and then allow the team to pitch the ideas to client themselves. Rejections are inevitable but a good leader would coach the team how to deal with it and keep trying.

Eventually, the team gets to a stage where the leader is redundant and acts as a facilitator. They key indication for this is that the leader’s absence no longer effects the progress of the project. The team generates tasks, gets client approvals and delegates while taking learning into account.

Why Self-Organization?

A leader is not someone who is hardcore, puts 9 hours a day and can take over the team when needed. No, a leader has the responsibility to make sure their team is working at their best.

When it comes to software, personal goals of each developer are the most important ingredient in making a wonderful team. If the leader can create an environment where the project and personal goals of each developer aligns, then the development machine does not work because it has to, but it wants to. Considering team growth and diversity, self-organization manages this alignment while keeping motivation up and everyone included.

---

Inspired from: Osherove, Roy. Elastic Leadership: Growing Self-organizing Teams. Manning Publications, 2016.