Great engineering leaders are forged through the fires of experience. It’s that rich, diverse history of projects we’ve worked on, technologies we’ve worked in, problems we’ve solved, and teams we’ve worked with that gives us the scar tissue it takes to effectively lead organizations. So, it’s not uncommon to find ourselves in a position where we have more experience and technical knowledge than those we work with.

Shared artfully as context, our experience and knowledge can be applied in service of a team’s greater good. But per “Maslow's hammer” (“to a man with a hammer, everything looks like a nail”), when we become over-reliant on domain expertise as the most familiar tool in our leadership toolkit, we will apply it indiscriminately and inappropriately. This typically manifests as rigid prescriptiveness.

Using our domain expertise as fuel to overzealously dish out solutions for our team’s problems can mean stunting the growth of our reports. Allowing them the space to navigate these issues themselves will give them the opportunity to cultivate new skills, leading to a much higher-performing engineering team. In other words, clearly defined problems breed autonomy and productivity. 

Common anti-patterns 

“I know, so I’ll come to you” 

When it comes to prescriptive behaviors, there are a couple of anti-patterns I’ve noticed over the years.

The first I call “I know, so I’ll come to you.” This is a technical leader who proactively jumps into all their teams’ projects and decisions. This leader is likely very passionate about the systems they own and about their team, both of which they want to “protect” from things going wrong. In service of that protection, they want to be in every meeting, reviewing every line of code, and ultimately making a lot of the decisions on behalf of everyone else.

This often leads to a situation where a leader becomes overwhelmed. They may start to experience a lot of stress, anxiety, and exhaustion. If you feel overwhelmed more days than you don’t and your calendar is back-to-back with meetings, it’s worth asking yourself if this could be you.

Like any system, engineering teams exhibit symptoms when something is amiss. Here are some signs that this could be an issue for you: 

• a team is hesitant to make decisions;
• the team is quiet in public channels and they don’t tend to document their thinking in Slack (or similar chat);
• team members are quiet in meetings and the manager does the majority or all of the talking;
• delivery of work may be sluggish (as a result of members of the team sitting back and waiting for the leader to make decisions for them rather than proposing solutions to unblock themselves).

Overall, this anti-pattern manifests as hesitation and uncertainty in teams.

“I know, so you come to me”

The second anti-pattern is “I know, so you come to me.” This is a technical leader who believes they hold all decision-making rights for their group, creating a dynamic where no one is allowed to act without their permission. 

This often leads to slow-moving teams (and slow delivery) due to bottlenecked decision-making. Rework may be high due to engineers’ repeated attempts to solve a problem the “correct” way (with some working solutions deemed unsatisfactory). If you see yourself as the team decision maker and especially if your team(s) aren’t achieving or exceeding their goals, it’s worth asking if this could be you.

Symptoms of this anti-pattern for your reflection:

• a team is active, but borders on chaotic;
• delivery timelines are difficult to predict because teams don’t know if the solution they are attempting will be accepted;
• teams tend to participate more actively in Slack and meetings. If you were to do a sentiment analysis of the contributions, they would skew negative, often calling out why things won’t work in an attempt to “collect receipts” on times they pushed back;
• in extreme cases, hostility and a heightened sense of “right and wrong” can become visible in this environment.

This anti-pattern looks most like fear and frustration for teams.

Breaking the cycle 

If you have a sense that you may be applying your domain expertise ineffectively in your current role – you’re in good company! This happens to all of us at some point or another. And it makes sense why. As individual contributors (ICs), we spend years being praised and rewarded for “knowing stuff”. For many, this leads to opportunities in leadership positions. Naturally, these patterns of always “knowing stuff” will be brought along with you. 

It’s not bad or wrong to rely on sharing our domain expertise. But it is worth noting that, in some situations, doing so may not be in the best interests of the people we work with.

How to circumvent these scenarios 

What got you here won’t get you there.

It’s important to step back and remember the role of a leader. It’s not our job to do all of the things or to solve all the problems. The role is to facilitate the doing and the problem-solving, ultimately accomplishing far more than we could ever dream to do alone.

As leaders, we must give up being great at certain things in order to create the space for others to learn to be great as well.  In doing so, we become force multipliers and strategic designers of sustainable teams.

Pro tip: Reflect on your role and the roles of other team members. By applying your knowledge to solve all of the problems, where might you be stepping outside of your core responsibilities and stepping on top of someone else’s?

Practice determining the cost of being prescriptive.

As leaders we cannot be one thing – different situations call for different versions of our leadership. Sometimes it actually is the best thing to be prescriptive and tell your team exactly what to do in order to achieve some goal or objective! But every single decision has tradeoffs and being prescriptive means the team doesn’t level up their knowledge.

Pro tip: Reflect on your team’s current work. Is being prescriptive right now worth the longer-term cost of slower growth and diminished engagement for your team? If yes, how can you communicate that intentionally? Is there a way to diversify your approach and let some projects have more breathing room than others?

Consider that you might not have all the answers.

Just because you have previously solved a problem one way, doesn’t mean that it’s the only way the problem can be addressed. Realistically, however, we have no idea what could have been if the problem was attacked in a different manner. We have no idea if an alternative solution would have scaled better, or fit the business better, or cost less money over time. We have no idea if that solution has not been surpassed by better, different technology that we’ve not yet had the opportunity to investigate.

Pro tip: Consider the possibility that you actually might not be the most experienced engineer in the room. If that were the case, how would that change how you show up for your team right now?

Practice describing outcomes, not solutions.

The leaders I most respect have described leadership to me as three primary responsibilities:

1. Provide the context
2. Set the vision
3. Hold the context and the vision (i.e., repeat steps one and two over and over again)

The most important way you can apply your experience and expertise is to create crystal clear problem statements (describe the context) and robust explanations of the desired outcome (describe the vision) for your team(s).

Then, you can leave your team to figure out how to get from point A to point B while you hold that vision for the group, using open-ended questions to guide them towards smart decisions that will ensure success.

Pro tip: Reflect on your current projects and ownership areas. Ask your team(s) explicitly where the vision and context might not be clear to everyone yet.

Practice asking your team members explicitly if they want coaching (listening and asking questions) or mentorship (giving advice and guidance).

We have many tools of influence available to us as leaders; coaching and mentoring are among them.

Coaching looks like deep listening (hearing what is said explicitly and also reading between the lines) and asking powerful, high-quality questions that move things forward. Mentorship looks like sharing our own experiences and domain expertise and giving explicit advice to our people.

Our craft deepens by practicing and honing all the tools in our toolkit, not becoming too reliant on any one. And we can deepen the relationships with our peers by learning which approaches work best for each of them in different circumstances.

The quickest route to discerning if coaching or mentorship will be more effective is by simply asking. If you notice in the context of a 1:1 or team conversation that you might have experience or advice to offer, ask explicitly if you can share it. This invites your team members to take advantage of your experience as input into their problem-solving process. This is in contrast to telling them what you believe the answer to be, which removes them from the problem-solving process.

Reflect on which projects or relationships may benefit from different percentages of coaching and mentoring.

Ultimately, technical depth can be a strength or an opportunity area depending on how it’s applied. Reflect on where your domain expertise is allowing you to be of high service to your team and where it might be getting in the way of your ability to serve powerfully.