Engineering Leadership Tactics: Resilience Through Collaboration
Building stronger software engineering teams
Collaboration is a good thing. There will be no one in the technology industry saying otherwise. As a rule of thumb, most companies and software engineering organizations are organized in cross-functional teams, allowing people in different disciplines to work together towards the same outcome.
However, it is still common to see teams where individual work is the main focus when it comes to software engineering. For example, while in the past, teams were throwing work over the fence to other teams, engineers now throw pull requests (PRs) to others over GitHub. They also deliver projects in isolation to be more efficient and think about architecture over document comments. In summary, while all engineers in software teams work together, not all collaborate effectively.
Engineering Managers (EMs) leading teams focusing on individual work might be getting more efficiency in some cases. After all, the experienced engineer with knowledge of a specific part of the codebase will deliver faster in that area if they can power through it. However, EMs sometimes don’t realize that they are effectively buying risk with this approach. And in the long term, it doesn’t pay off.
A Tale of Two Projects
To better understand the challenges in this area, it is worth going through two software projects that I have observed. Both happened in cross-functional teams, where product, design, and engineering collaborate daily.
In the first one, a group of engineers within a team worked on building a new product feature. The project was led by one of them, and they were responsible for executing most of the work, as well as working individually in one of the project work streams. Other engineers in the project had different parts of the work delegated to them (frontend work, for example).
The team lead struggled with their assignment. They were not delivering their work as fast as expected and not guiding other engineers well. Because each stream of work was separated from the other, the rest of the team became blocked, adding pressure on the team lead. The lead’s performance only worsened with the extra stress, delaying the project even further.
In the second example, a similar-sized team worked on another product feature. While this team also had a lead, they didn’t divide the work into separate streams. In practice, all engineers worked on different tickets that iteratively built the functionality and user experience.
Not separating the work meant everyone on the team had to understand the architectural plan, leading to more discussions. While the team had frontend (FE) and backend (BE) specialists, all the tickets had FE and BE components, so anyone could pick any ticket and ask for help from their colleagues when needed.
In this project, the team lead had personal issues while it was in progress and was not working full-time for a few weeks. While that impacted the speed at which they could deliver, their absence was a blip in the team’s performance. Everyone else kept executing in the same manner, leading to the project being delivered successfully.
If you want to go fast, go alone. If you want to go far, go together
The first example above highlights one type of inefficient collaboration, although that is not the only one. There are multiple reasons why teams decide to focus on more individual processes.
Some of the ones I’ve heard are:
- Individual Efficiency: Engineers believe (and are right sometimes) that if they work alone, they can deliver a task in less time.
- Individual ownership: With companies rewarding individual ownership to the extreme, engineers believe they must do some part of the work by themselves to be recognized.
- Remote work: While collaboration can be achieved in a remote setting, it is also more challenging in some cases, leading to teams moving towards a low-communication environment.
- Team Efficiency: Teams believe that separating work leads to more efficiency since no one will double down on the same task, or they will minimize the need for communication while delivering the project.
However, the examples above also show that effective collaboration, where engineers work closely together in the same areas, offers a significant benefit for teams and EMs: resilience.
Resilience in production is not a new concept. In Lean Production Systems, the Heijunka concept focuses on leveling production work. The goal is to avoid spikes since a better-leveled process will lead to a more consistent flow, allowing the system to better adapt to changes.
In software engineering, it works in the same way. Focusing individuals exclusively on their specialty areas (or a specific part of the work or a particular discipline) will lead to unevenness, and that means the process is more fragile to unexpected conditions that are bound to occur.
And this is not an if. In any sizable project, unexpected things will happen, leading to more resilient teams delivering better in the long term. A few examples of common areas of variation in software teams are:
Missed Details — software is a complex discipline, with engineers trying to hold significant context during their daily work. Usually, details will be missed if only one person focuses on a particular part of a problem. Having overlap and multiple perspectives on the same activity will minimize the risk of missing essential aspects.
Hidden Complexity — the most obvious challenge teams face is that projects have hidden complexity that appears as the work is in progress. Being able to increase capacity and focus on a particular area will allow the team to minimize the impact of these issues.
People being Human — while robots haven’t taken over, people deliver software. And people will make mistakes, get sick, and have personal issues. Having a resilient team also means having a more humane and inclusive team, allowing people to go through the ups and downs of life without significantly impacting their work (and the work of others).
In other words, EMs should resist the temptation of individual efficiency and set up a process where engineers work in close collaboration, creating a more stable and predictable environment. As with many things, software development is a marathon, not a sprint.
If you have found this content interesting, this post is part of a series on Leading Software Teams with Systems Thinking. Follow me if you are interested in effective engineering leadership.
