Gelling your Engineering leadership team.
One of the first leadership books I read was Patrick Lencioni’s The Five Dysfunctions of a Team, which introduces the concept of your peers being your “first team” rather than your direct reports. This was a powerful idea for me, because it’s much harder to be a good teammate to your peers than to your direct reports. While your incentives are usually aligned with the team you manage, it’s very common for your incentives to be at odds with your peers’ incentives. The Head of Marketing may want you to prioritize work that your team believes won’t be impactful, or the Head of People may want you to be more selective in assigning top performance designations even when you believe your team has earned them. Those are difficult topics to agree on.
Even if it’s easier to align with your direct reports than your peers, it is nonetheless surprisingly difficult to create an engineering leadership team who are aligned with each other. Well-intentioned members will occasionally find themselves at odds with one another, and it’s your job as the engineering executive to establish clear values for the team, and to referee conduct that falls outside those values.
In this article, we’ll discuss:
- Debugging the Engineering leadership team after stepping into a new role
- Gelling your leadership into an effective team
- What to expect from your direct reports in that leadership team
- Diagnosing conflict within your team
By the end, you’ll have a framework for forming and operating an effective team.
This is an unedited chapter from O’Reilly’s The Engineering Executive’s Primer.
Debugging and establishing the team
When you start a new executive role, one of your most important tasks is developing your point of view on your functional leadership team. This can be tricky because often by the time you are hired, the previous executive is long gone, and the engineering leadership team has been operating without guidance or feedback for some time. As such, early glimpses of your new leadership team are more likely to reveal them at their worst than their best.
Despite that, you need to answer a few key questions in your first couple months:
-
Are there members of the team who need to move on immediately? These are folks who either have significant behavioral issues or who have lost the confidence of their team and peers. Rather than underperforming, these are individuals actively causing damage.
For example, if a member is complaining widely about their role and the company, such that they cannot energize the team they lead, it may be time for them to move on.
-
Are there broken pairwise relationships within your leadership team or between members of your team and their key stakeholders? You’re looking for individuals who clearly cannot work together, or even communicate successfully with one another despite needing to collaborate.
For example, if the product and engineering leaders on a business line never interact directly in meetings, and contradict each other in private, you need to solve that quickly.
-
Does your current organizational structure bring the right leaders into your leadership team? Your biggest focus should be adding representation for teams like Data, Security, or Infrastructure where their absence prevents important decisions from moving forward quickly, and on elevating important teams from places where they are being neglected or mismanaged.
For example, if your company suffers from a significant lack of a security mindset, and your Security team is nestled deep within Infrastructure where it’s managed by someone without direct Security experience, you may want to pull Security into your leadership team.
As you spend time meeting with folks one-on-one, attending meetings, and watching the team operate, you should quickly form initial opinions on answering each of these questions. Once you have a first opinion, spend time trying to disprove it. You’ve been hired to determine the truth, not coalesce the most popular narrative, and you’ll never regret being suspicious of simple narratives.
Once you’re confident in your interpretation, it’s time to take action. Start by moving out the individuals who won’t be part of the team going forward. Each time you change members of your leadership team, you will have to gel that team afresh, so it’s important to get to a plausible leadership team quickly. This can feel uncomfortable, but letting an untenable situation linger doesn’t help anyone. Making personal changes quickly lets you shift time from dealing with interpersonal conflict to instead working through more durably valuable decisions around execution and strategy.
Sometimes the decision to be made won’t have a clear answer. For individuals who are struggling but you believe have a role to play on your leadership team, have a frank discussion. As a new leader, you have a small window to set clear expectations, which makes it easier to have those difficult discussions. I particularly want to discourage you from waiting to have these discussions because you’re afraid you might lose someone you can’t afford to lose. Most leaders have a strong desire to perform, and establishing clear expectations sends the message that you’re here to help them perform. That’s what good folks want! Anyone who leaves because you set expectations is already too frustrated or burned out for you to help.
Finally, once you’ve edited the members in the room, you have to decide whether to tweak your organizational structure to bring the right folks into the room. It’s not a goal to directly represent every team in your leadership team, but there should be someone who can represent the most important teams with reasonably high granularity. Particularly early on in your tenure, I recommend erring on an overly broad leadership team to ensure a wide set of perspectives are surfaced. You’ll have to balance that against the value of stability. If you’re just not sure, you can always experiment with bringing folks into your meetings on an interim basis.
Should you include engineers in Engineering leadership?
When it’s possible, it’s well worth your time to consider including one or two senior engineers to report to you, as opposed to only managing engineering managers. An engineering executive is responsible for blending the technical and managerial perspectives of engineering, and that’s most easily done when both perspectives are represented within your leadership team.
In some cases, this will be difficult to accomplish. You may have too many direct reports already, and feel it will be overwhelming to include more. In that case, work to establish a group of senior engineers that you interact with frequently to ensure you’re hearing their perspectives. This is frequently an architecture team or the senior-most engineer from each business unit.
Operating your leadership team
Once you’ve decided on your initial leadership team’s members, you have the larger task of turning those individuals into a team. This hinges on creating the values, structure, and relationships your team needs to be effective. Whereas your initial edits on the leadership team will be quick, gelling and operating this team will require ongoing effort throughout the entirety of your role.
Operating your team can be boiled down to four themes:
-
Define team values. How do you want this team to make decisions? How much should they focus on enforcing consistent policy versus solving escalations? Your team values should connect with your organizational values, but will likely focus more on behavioral tradeoffs in how you do work. The most important values to establish are those that explain navigating conflict within the team, e.g. how should the team navigate the tradeoff between delivering new product functionality and supporting the migration necessary to deprecate an unreliable component?
Some teams will write these team values down, and others will simply live them actively. The important thing is having and enforcing them, whether you’ll benefit from writing them down will depend largely on the sorts of people on the team.
-
Establish team structure. These are the mechanisms and rituals that the team relies on to operate Engineering. What meetings does this team rely on to broadcast context and resolve conflict? How does information flow from your company’s executive team down to this group? Do folks give a weekly update over chat?
-
Find space to interact as individuals. Many senior leadership teams become so transactional that they feel impersonal. A transactional collection of individuals can do good work, but a gelled group that knows each other is better positioned to work through the inevitable difficult moments. Your role as the team’s manager is to create some unstructured space to interact as informal, unstructured humans. That unstructured space is locally inefficient–it certainly won’t generate any action items–but relationships are the slack necessary for large groups of humans to work together successfully.
-
Referee detection from values. Some leadership teams struggle despite having clear values, structure and relationships. Usually this can be traced back to one or two members of the team violating the team’s values without consequence. Once someone defects, others will become skeptical whether following the values is necessary for them either. Your role as the executive is to hold members accountable to the values. Mistakes will certainly happen, but tolerating consistent violations is the same outcome as not having team values at all.
As is often the case in leadership, these steps are fairly simple, and the hard part is consistent implementation. There will be some initial setup here, and there will also be ongoing maintenance every single week–to some extent, every single decision–that you’re serving as an executive. Fortunately, you are not doing this alone, you’ll need the active participation from the team itself.
Expectations of team members
A central part of creating your team’s structure is setting expectations for how members participate with the team. Often individuals on their first leadership team will assume that the team exists to help them do their work, rather than recognize that they lead their organization on behalf of the business’ goals. Setting explicit expectations helps folks recognize if they have an inverted view of priorities.
It’s particularly useful to set expectations on:
- Leading their team. Some companies focus internal leaders on bureaucratic execution, lauding pristine headcount spreadsheets and thoroughly documented quarterly plans. Other companies evaluate their internal leaders primarily on dynamically firefighting issues as they emerge. Another set of companies anchor heavily on visionary leadership rather than operational concerns. It’s essential that your leadership team understands however you and your company will judge them.
- Communicating with peers. Some leaders are naturally relationship oriented, and will build a wide network within the company. Those folks will generally know what their peers are working on, and what they’re struggling with. Not all leaders act that way though. Another common archetype will be heads down optimizing their team’s operations, mostly unaware of what their peers are doing. If you don’t tell your team what you expect, they’ll default to their natural state, which probably won’t be what you want.
- Staying aligned with peers. Being aware of their peers’ goals is a necessary precursor to resolving conflict, but is certainly not sufficient. Your team should understand your expectations around how they resolve tension between each other’s goals. Should they work to resolve the conflicts directly, and only escalate to you when that is unsuccessful? Should they escalate together, or is it more importantly to escalate quickly, even if it’s a bit messy?
- Creating their own leadership team. Although the leadership team reporting to the functional executive is particularly important, each member will have their own leadership team as well. It is turtles all the way down. It’s not enough for you to communicate to your team, you need each leader to communicate with theirs, and so on: leaders exist everywhere in high-functioning organizations.
- Learning to navigate you, their executive, effectively. One of the enduring controversies in the engineering management community is whether “personal READMEs,” short documents which describe how to work with you, are a sign of professional or self-absorption. Regardless of your opinion there, the reality is that your team will spend a significant amount of energy figuring out how to work with you, and you should do what you can to make it easy for them. Are you a stickler for process or very much the opposite? How much risk should they take? Which stakeholders should they prioritize? Let them know!
Each of these is a useful topic to discuss in your weekly team meeting or one-on-one sessions. Start early, engage with individuals who are finding aspects difficult to adopt, and review these topics periodically as membership of your leadership team shifts. Your team will eventually pick up your expectations even if you don’t state them explicitly, but it’s much faster to just tell them what you want from them.
Competition amongst peers
Sometimes you’ll pull together your leadership team effectively, it works well for a while, but a year later you’ll notice something’s gone wrong: collaboration has slowly faded into internal competition. There are a few different reasons why this can happen, but ultimately it means that members of your team believe they’ll be rewarded more for capturing capacity from each other than creating capacity for the organization overall.
The three most common causes of competition that I’ve seen are:
- Perceived lack of opportunity
- Misapplying poor habits learned in the context of shrinking or bureaucratic companies
- Signal that you are failing to referee your team
The first of these three, a perceived lack of opportunity, has been particularly common in my experience. If your team believes they’ve exhausted their personal runway within your team, then they’ll look for ways to create opportunity for themselves, which often means competing with peers. It’s certainly true that only one person can take on any given stretch assignment.
When you’re managing less experienced folks earlier in your career, it makes sense to solve this problem for them by giving them specific opportunities for growth. For senior leaders, I recommend giving the problem back to them: the next step in their career is being an executive, and certainly no one is going to tell them how to advance their scope at that point. Particularly encourage them to look at opportunities to grow themselves and their career in ways that aren’t zero sum. With some creativity, there’s no reason for your team to compete over access to opportunity.
The next common challenge is team members who’ve learned bad habits in bureaucratic or shrinking companies. Those environments often teach the implicit leadership lesson that it’s more effective to capture existing capacity within the company than to create new capacity for the company. Leaders immersed in that lesson often view success as a zero-sum game. Your goal is to convince them that today’s capacity represents a small fraction of the future capacity. By instead focusing on the capacity that can be collaboratively created in the future, they’ll have significantly more opportunity.
Finally, if neither of those hypotheses fit particularly well, then it’s likely the issue here is you. Teams composed of ambitious individuals typically only follow rules when following those rules is the best path forward. If they’re defecting from your stated rules, then you’re not enforcing them effectively. Get back to the basics that we started with!
Summary
Working with a new team, particularly one that has been trying to lead itself without an engineering executive for some time, is both messy and necessary. This piece covered getting started debugging your new Engineering leadership team and operating that team once it’s gelled. Keep in mind that, even if you do a remarkable job with your team, you’ll be spending time on this from your first day until your last.