Engineering Leadership Tactics: Finding Focus
Making your software engineering team work less and deliver more
While talking about Systemic Leadership for software teams, one question that often comes up is how to apply it in practice. Yes, systems thinking makes sense, but how does an engineering manager (EM) use it in their daily work?
While teams are different, some situations happen often enough they can be considered patterns where systems thinking can help, one of which is the focus challenge. In other words, how teams can increase their performance by increasing their focus.
Why Focus?
Before discussing the problem and possible solutions, we should clarify why this matters. First, why is focus so important?
The idea of focus as a tool to increase productivity has been used in many industries over the years. For example, at this point, it is well known that multitasking decreases productivity individually. In Lean production systems, companies use “work in progress” as a critical metric for their processes since it will lead to higher costs (more unfinished material), lower revenue (fewer products ready to be sold), and overall higher risk.
The situation above translates well to software. The longer it takes your team to complete a project or parts of it, the longer it will take to validate it in the market, incurring more risk, and the higher the costs will be since engineering time is usually the main expense in a software team.
Beyond the similarities, in software development, some characteristics make focus even more critical than for individual work or other production systems:
- Software teams are usually small and cross-functional, with the same individuals executing different parts of the process (i.e., design, code writing, code review, and quality assurance).
- Software engineering has a low level of documentation compared to other disciplines. A significant part of the knowledge related to systems is only available as tribal knowledge in the engineers’ minds.
Because of that, when software teams have low focus, with engineers spread across many initiatives, it leads to blockers and bottlenecks across the system. For example, pull requests wait for code review for a significant time, delaying when work is delivered. Or work is executed with lower quality since the most knowledgeable engineer was busy with another activity, leading to rework in the future.
To make things worse, given how companies evaluate engineers for their individual performance, low-focus teams lead to even more work in progress. When an engineer is blocked because the team is not focused, they pick up new work to be “productive,” creating more work in progress and even lower focus. This pattern creates a vicious cycle that can significantly affect how a team can deliver.
Here is where systems thinking can help.
To improve a team facing these challenges, we need to think about the whole (what is the objective the team is trying to achieve?) instead of the parts (what is every engineer doing right now?).
The not-so-hot-take is that the fewer initiatives the team works on, the more productive they will be. What I have found in practice is that while most managers agree with this statement in theory, there are challenges with the practical aspects of it, so let’s talk about that.
Lack of Focus in Practice
A software team in most companies has an array of distractions to spend their time on. Multiple projects are being delivered and maintained. There are issues and bugs discovered both internally and by customers. Some incidents require attention. People in other parts of the company raise questions.
In this sense, due to how software companies are organized, there is already a natural amount of parallel work that will always be there. Because of that, a passive approach towards focus will likely lead to a team with many initiatives and low productivity. And this will only get worse if a team allows additional complexity to enter the system.
What is additional complexity in this case? It’s any activity that will allow the number of parallel streams to increase. While it’s impossible to compile an exhaustive list, some examples are:
- Lack of discipline about starting and finishing initiatives allows them to multiply.
- A structure of work that incentivizes engineers to work independently, creating de facto independent backlogs for each person.
- Low-quality work leads to excessive issues and rework, creating interruptions that the team cannot control.
- Long waits for collaboration, as in long cycles of code review or quality assurance, lead to engineers picking up new work.
- Constant reprioritization and focus shifting lead to frequent context shifting by engineers.
In summary, anything that allows for more work to be started and less work to be finished.
What can an EM do about it?
As the team’s manager, the EM is in the best position to influence the team’s focus by acting on its system and how people work together. Of course, every situation is different, but there are a few practices and principles that I have seen used effectively often.
Focus on team efficiency over individual efficiency
If I had one tip to give to managers, it would be to make it extremely clear to engineers that team efficiency is more important than individual efficiency. Every team member should understand that the primary metric is not how busy and productive they are individually but how fast the team can deliver features to customers together.
This attitude doesn’t come naturally in most environments, given that engineers are evaluated individually. However, it is inevitable that if the team collaborates well, every member will also increase their individual productivity.
Have the team’s priorities straight
Managers should make it clear what the team’s priorities are at any time. While there are different ways to manage goals (i.e., OKRs, quarterly goals, sprint goals), it should be easy to understand the milestones and objectives the team is working towards.
Engineers are making hundreds of decisions every day. From which ticket to work on to how the approach for a feature’s implementation. The more they understand their work’s business goals, the better they can decide how to approach every decision.
Visualize the work
Software engineering is an abstract discipline by definition. Therefore, the simpler it is to understand what the team is working on and whether they need help, the more effective they will be.
The easiest way to do that is by visualizing the work regularly as a team, ideally at the standup, so everyone is clear about it. And the manager can play a critical role by removing blockers, incentivizing collaboration and knowledge sharing, and ultimately defining the best formation for their team for the day.
Work in groups
In a perfect world, every team would have one goal and project and be 100% focused on it. That is unrealistic in any company environment, though. Teams usually have multiple initiatives going at any time.
Even in that context, there is still a significant difference between an individual engineer working on single or multiple initiatives simultaneously. And there is also a substantial difference between them working alone or as part of a group. Individual work will very likely lead to knowledge silos and blockers. And if one engineer is splitting their attention between multiple projects, they will constantly be context-switching.
A practical alternative is temporarily dividing the team when multiple initiatives are being acted upon. For example, this could be done by dedicating a pair of engineers to bugs while the rest of the team works on a project or defining sub-teams that will work together for a project or sprint. In this way, the team can still be flexible and execute different types of work while maintaining a high-level of focus and collaboration.
Reduce waste and minimize distractions
Besides acting on the present, the manager can work on reducing future distractions for the team, increasing their productivity in the long term.
They can analyze the type of work the team has done and understand what leads to work in progress. For example, the main issue could be bugs in a specific part of the system that can be improved or a product strategy that is too flexible and could be streamlined.
Keep the team on target
While it’s a neverending journey, actively focusing the team on its main objectives is one of the most high-leverage activities a manager can do. Keep the team on target. They will work less and achieve more.
If you have found this content interesting, this post is part of a series on Leading Software Teams with Systems Thinking. More broadly, I write about leading effective software engineering teams. Follow me if you are interested in the area.
