Ownership as a Skill for Engineering Managers
Whether you think you can or you think you can’t — you’re probably right.
Engineering Managers (EMs) work in a complex environment. A team has multiple initiatives. There are different opinions, from people above, below, or adjacent in the organizational structure, on tackling technical challenges, how the team should work, and even what people should work on. Around all of this, there are deadlines and different types of internal and external pressure. In summary, it is easy to get lost.
This complexity creates a real challenge for EMs. When teams perform poorly, often the problem doesn’t lie in the quality of the individuals involved or even the problem space they are in. It is centered on their lack of consistency. They might lack consistency in their practices, never really mastering them. They might lack consistency in their work, executing a brittle roadmap. Or they might lack consistency in their vision, having constant doubts about their path.
Our lack of confidence is not the result of difficulty. The difficulty comes from our lack of confidence. — Seneca
Independently of the type, inconsistency creates a fragile team, and at some point, a fragile team will get railroaded by its environment.
Distractions, distractions everywhere
The reality of a modern software team is multi-faceted. At any point, multiple projects will be in flight, and there will be some in planning. Design docs for suggested technical improvements will go around, and bugs and incidents will be raised regularly.
To succeed in a sea of distractions, a team must have a clear perspective on what they will work on and how to tackle those challenges. While these don’t have to be prescriptive, like a detailed roadmap or technical design, the direction needs to be steady. A steady view of the customer will allow a team to prioritize the important from the less critical issues. A constant view of technology will allow technical debt to be tackled in the long term.
Keeping a direction is a challenging task, though. Amongst all of these options, there will be multiple opinions. People will have different perspectives on how to work, what to work, and even what aspects of work should or should not be improved.
A simplistic view of this problem might say it is just about separating good from bad ideas. A more realistic perspective is that most opinions will be valuable. One person thinks this, the other feels that, and the third has done it differently in their past experience. And they might all be correct within their contexts.
The other simplistic approach is to believe that a team can evolve through a step-by-step approach to continuous improvement: you just have to measure the results and iterate. That might work in the books. However, in reality, a team is a web of multiple systems that interact with each other, and understanding the actual result of minor improvements will be much easier said than done.
Going with the Flow as a (poor) Leadership Strategy
Because of the situation above, an easy but risky path to take as an engineering leader is going with the flow, or in other words, with what other people say. The product manager will likely have unlimited features to deliver, and every team member will have perspectives on possible improvements. There are multiple ways to take this path, but the common trait is believing that someone else always knows it better.
And that might work well for a while. If the team has an exciting roadmap, focusing exclusively on delivering it will lead to a positive impact. If the organization is going well enough, most team inefficiencies are hidden in the tide lifting all boats. As said before, “Every management theory works in a growing environment.”
However, it also breaks down eventually. Keeping a team successful in the long term means that the team will face challenges. The business environment might change, leading to churn in the roadmap. Technical debt will continue accumulating, leading to a slowdown in productivity. Or team members might leave, leading to disruption in the capacity.
In that environment, the inefficiencies will become apparent. Diverging opinions will lead to confusion, the lack of a plan will lead to low impact, and that is when you can see teams going sideways, moving backward on the path to productivity.
This is where I see teams struggling often. They are not teams with less competent or technical people. They are teams that don’t have alignment, that don’t have a clear view of their mission and roadmap, or that don’t agree on how to work effectively. The result is teams that are not obviously failing but are also not being very successful.
Ownership as a Tool
The goal of an Engineering Manager (EM) is to create an effective team. While they have peers they work with in Product, Design, and other disciplines, they also manage most of the people in an engineering team. The team’s success is the EM’s success.
Because of that, helping the team align on a path forward is the EM’s responsibility. That doesn’t mean they must have all the ideas or call all the shots. But they must be fully confident in the team’s direction and act if that is not the case.
Other members of the team have great perspectives and ideas. They surely do, and it is part of an EM’s role to understand these perspectives and create space for them to be surfaced. However, what they don’t have is a high-level view of the team or the accountability for the results. On the other hand, leadership above the team has a broad perspective but doesn’t have a close view of the day-to-day reality. Due to this, the EM needs to be a leader, owning the problem and the solution that will deliver the expected results.
Not all team members will identify the same critical issues, nor will they think of the same solutions, even if they did. Some solutions will result in more critical issues.
Out of this intellectual cacophony, the leader has to do the work of comparing and contrasting concepts, integrating proposals, answering and asking questions, correcting misunderstandings, providing due recognition, sequencing input, and finally, producing a plan of action to achieve the purpose.
Systems Leadership: Creating Positive Organizations
In practice, that means that the EM needs to provide direction, maintaining a steady environment for the team. They should do it within product, working closely with product managers and design peers to decide what to do and communicate it to the team. They should do it within engineering, leading engineers and the team in a long-term technical path. And they should do it with process, defining effective practices for the team’s context.
This is especially important when teams try to improve or change direction in a fluid environment. In any change process, things tend to get worse before they improve, and results won’t be achieved unless consistency is maintained long enough.
Direction, not Dictatorship
However, providing direction doesn’t mean telling everyone what to do or not creating a safe and inclusive environment for people to provide their opinions. It means aligning the team towards a goal and helping everyone execute within it. A successful approach means incorporating all perspectives, making people feel heard, and aligning together on a path forward.
Below are a few practical aspects to keep in mind when trying to actively lead a team.
- Understand the context: every team is working within an environment. The company will have its culture, the organization will have a strategy, and the people around the team (both upwards and downwards) will have different perspectives. For any approach to be successful, it must respect and act within that context and not ignore it.
- Understand your authority: an EM has authority over a team, but that authority is not unlimited. There are peers in different disciplines, like product managers and designers. There are people above in the organizational structure who also have perspectives. There are team members that need to be heard. EMs should understand their circle of influence when acting and escalate when changes are needed in areas outside their purview.
- Iterate toward a result: Nobody is always right, and even when an EM proposes alternatives, some might not get accepted or need refinement. While it might be simpler to give up, getting feedback, refining the perspective, and iterating towards a successful outcome will lead to a better result.
- Use principles, not practices: To better adapt to existing contexts, EMs should consider principles more than practices. For example, talking about how short feedback loops are important is easier than imposing pair programming in a team. The familiar anti-pattern here is the application of Scrum-by-the-book, which has slowly (but surely) created an aversion to agile methodologies within the industry.
- Listen, discuss, and adapt to the context: while EMs have authority, they should aim to use it sparingly. Discuss problems with the team, listen to different perspectives, and build alignment before taking action.
- Take ownership: in a complex environment, it is easy to expect that someone else (leadership, the manager, etc) will come and solve the problems at hand. EMs should feel ownership of the team direction, actively proposing alternatives until alignment is achieved.
- Keep refining your principles: as they keep working with teams, experiencing different situations, and seeing the result of actions, EMs should keep refining their principles on how effective teams should work. That perspective will be their strength in the long term, allowing them to act with more confidence in the future.
Leading a team means ensuring that the team succeeds in its context. EMs should feel empowered and responsible for it, helping the team find the best even in complex situations. While that can sometimes seem overwhelming, it will guarantee a better, longer-term perspective for the team and its members.
