Francisco Trindade

Aug 19, 2021

5 min read

Team and Individuals. The how-to for a tricky balance in software development.

This post is part of a series on Creating Effective Teams.

One of the current philosophical discussions in software engineering is the challenge of balancing individual and team needs. Companies want highly productive teams but understand that software is a creative process that requires some personal inspiration. On the other hand, individual engineers want the freedom to create but usually fail when delivering solo efforts in highly complex contexts, either technical or bureaucratic.

These are shifting sands in the industry. What started with management and process-heavy approaches in the past has recently moved to talent-focused ones, with the belief in 10 (or 100!)x engineers.

However, as great teams have discovered time and time again, this distinction is a false dichotomy. But before we get into solution mode, let’s look at the problem from closer up.

Vader instructs his new clean team by stavos is licensed under CC BY 2.0

Software is a team sport.

Starting with the obvious, software development is done much more effectively as a team activity. There are considerations about the size of the team (4–6 people has worked well for me), but if teams weren’t the best option, all technology organizations wouldn’t be organized in groups. Most useful systems are large and complex enough that one person cannot build and maintain them by themselves.

And the main goal for most teams is to become highly productive. In other words, deliver as many great solutions to real-world problems in the shortest amount of time. The objective is not total lines of code or features produced, nor strictly adhering to the process. Instead, the goal is to solve someone’s problem, preferably quickly, while building easily maintainable systems.

But individuals need space

On the other hand, engineers need space and freedom to deliver solutions. So while collaboration is essential (a vote for pairing!), creative space is required to develop efficient solutions for complex problems. Since efficient solutions are what we are looking for, we should incentivize methods that can deliver them.

Engineers also need practical space to grow in their careers. Most companies have some level of individual delivery expectations to allow for career growth. How does one decide who is performing well if you don’t have visibility on individual contributions? How to improve as an individual if day-to-day work is constraining?

The path to an equilibrium

“The strength of the team is each individual member. The strength of each member is the team.” — Phil Jackson

The truth is neither here nor there. And the good news is that when a team finds a balance on these topics, it gets well rewarded.

As a manager, one of the ways I onboard new engineers is by saying that one of my main contributions to their career will be to make them work in a productive team. A software team that works really well will create more growth opportunities, and growing and motivated engineers will supercharge the team results.

To achieve these results, here are my view on practical steps:

Different engineering managers work in different ways, and the work also varies depending on team composition and size. There is a broad list of areas where they can get involved, while time is limited, from recruiting to technical decisions.

While everyone should play to their strengths, remember that you are responsible for how work is defined for the people you manage. A typical anti-pattern I’ve seen in the industry is engineers struggling, sometimes to the point of having their performance questioned because projects are not managed well.

As a manager, make sure to work with your peers in product and design to think about the whole system end to end, from problem to software delivery.

Most organizations that have been around for more than a few years are drowning in technical debt. Within that context and with constant product pressure, it’s easy to fall into the habit of patching a broken system and focusing on short-term improvements.

When that happens, it’s harder for engineers to find ways to generate meaningful technical contributions. If all you do is deliver features, the only path to growth in the company is to be good at feature development. Unfortunately, that work is sometimes not exciting nor rewarding.

Having a long-term technical vision for your team(s) will broaden the paths to grow as an engineer. While some might be great at getting product features out, others might have their strength in evolving the technology landscape. And everyone wins.

Getting things done in any technology organization requires much more than just technical skills. The more undefined the system is, engineers will need more political talent to find a path for meaningful contribution and recognition.

Many groups will find that hard. From introverts to minorities or remote people, they struggle to contribute, be recognized, and grow when what’s required is to influence the right people.

As a manager, you have the power to change this imbalance. First, create straightforward communication methods that are inclusive, from meetings to written options. Then, develop transparent systems to propose ideas and get feedback that don’t require approvals.

A better defined technical contribution system will level the playing field, making it easy for everyone to find their path.

While having a ‘highly experienced’ team is the paradigm that most companies are looking for, having teams without seniority diversity will make it hard to find growth paths for everyone. If all engineers are experts, how does someone become better at teaching?

Besides growth opportunities, the reality of companies is that not all work is exciting, new, and challenging for someone that has been in the industry for many years. Having engineers with different levels of experience will mean that different people will be interested in various types of work, improving delivery overall.

Lastly, make your job easier. Align individual goals with what the team has to achieve. While the default manager playbook says that engineers have to define their objectives, effort leads to motivation. Suggesting growth goals that align to team challenges can be as much of an exciting endeavor for an engineer as the ones they came up with themselves. In addition to that, working in something that helps the team will mean more support from colleagues and the company. And more recognition for their success!

In summary, remember this. Next time you think about how to make your engineers fulfilled, improve your team.