I present what I think is the best case for us, and people can disagree with that. And, you know, they often do. I'm steering and influencing more than saying, "I've got the authority to just tell you what to do." I've never seen that style work well. - Keavy McMinn
Most folks have worked with someone who thinks they're never wrong. In each discussion, they lean in, broaden their shoulders and breach their way into the role of the decider. They'll continue debating until their perspective wins the day or time runs out. They are often right, but right in a way that sucks the oxygen out of the room. As their tenure at a company increases, they may fancy that they've become very persuasive, but frequently it's a form of persuasion characterized by the resignation of their peers.
A few of the technical leaders that I've worked with have found a way to never be wrong without dominating the room. To be right while creating space for others. Someone who has always embodied this approach for me is Franklin Hu, who I've seen reliably disarm contentious discussions with his commitment to finding the best outcome for everyone, willingness to leave his starting position and the default assumption that there's always an additional piece of context that reconciles seemingly conflicting perspectives into a unified view.
To become a senior technical leader, you must build a deep perspective on technology and architecture. To operate as such a leader, you must then develop an equally deep pragmatism and agnosticism to technical religion to remain skeptical of yourself. This can feel like a paradox, but it's the line you'll need to walk every day.
Listen, clarify and read the room
A lot of times, you'll see engineers go into a discussion confident that their perspective is right and with the goal of getting other folks in the room to agree with their approach. This mentality turns each meeting into a zero-sum debate. Even in the "best case" that their approach is agreed upon, they didn't get to learn from anyone else in the room, and it's unlikely that the rest of the room is leaving energized.
The most effective engineers go into each meeting with the goal of agreeing on the problem at hand, understanding the needs and perspectives within the room, and identifying what needs to happen to align on an approach. They approach each meeting as one round within the broader context of the project and their relationships with the folks in the room. If the room is ready to agree and move forward on a solution, they land the team on that approach. If the room isn't ready, they don't force it to happen.
To get good at this, you need to master three approaches: listen through questions, define the purpose, and know how to read the room.
Listening through questions is a form of active listening with the goal of understanding the rest of the room's perspectives. The act of asking good questions with good intent opens up a conversation, creating space and safety for others to ask their own questions. Good questions are asked with the desire to learn, and they are specific. They sharpen the conversation. They free the answerer from the obligation to defend their position. In a potentially contentious meeting, ask three good questions before you share your perspective, and you'll see the room shift around you.
Good meetings start from a clear purpose and agenda, but many meetings don't meet that definition, particularly ad-hoc discussions. If you ever find yourself in a conversation with an unclear goal, then define the purpose. Take a moment to ask if your understanding of what the group hopes to accomplish is correct. This works best as a statement wrapped in a clarifying question along the lines of, "Just to check, our goal here is to decide whether to postpone launching the project by two weeks?"
Note that defining the purpose can be disruptive if it's used too frequently. Rather than helping to clarify the conversation, in that case, it creates conversational churn. For the most part, try to avoid using it if someone else has already made an attempt. Meetings with multiple failed reframings almost always end with scheduling another meeting.
Finally, in each meeting, you have to read the room. Oftentimes folks get frustrated with a conversation and try to force agreement, which creates so much pressure on the discussion that it's unlikely to conclude well. If the folks in the room are too far apart, then identify a subgroup who are able to spend more time digging into it together or identify an appropriate party to escalate to outside of the room. If there's simply too much stuff in the drawer, stop trying to shove it shut.
How to practice
If these behaviors don't come naturally to you, that's okay; the opportunity to practice is all around. Every comment on a document is an opportunity. Every meeting is an opportunity. Every pull request is an opportunity.
Start each week by picking one of these skills you want to explicitly use in the meetings you head into. If you have a particularly difficult meeting come up, spend some time practicing in your head or with a peer how you might use these approaches to facilitate forward progress despite the challenges.
Jerks
The above approach works well most of the time, but not always, and one of the notable exceptions is when you're dealing with a jerk. In this case, a jerk is someone who withholds their consent from the group, isn't willing to compromise, or doesn't listen. This is someone who hasn't learned that their career depends more on being easy to involve than being technically correct.
The two most effective ways to deal with jerks are:
- including someone they can't be a jerk to in the meeting (like their manager or the CTO)
- investing heavily into aligning with them before the meeting, so they feel heard and are less likely to derail the discussion
Both of these can feel ridiculous to spend your time on, but they're what tends to work best, especially if it's a jerk you interact with infrequently. If it's someone in an area that you're responsible for or someone you work with frequently, then you have a somewhat different set of obligations. In that case, give them the feedback as kindly as you can while still being honest. Give it a second time. Document both, and if you don't see an improvement, then communicate the concerns to their manager, including the specific documentation, in a face to face or video discussion.
It's also useful to recognize that the authority created by your title shelters you from many of these folks, so whoever you're experiencing is being less of a jerk to you than they are to others. If the behavior feels borderline for you, it's potentially more egregious for others.
How it helps
This approach is powerful because more complex projects get derailed by personal conflict than by technical complexity, and this is a repeatable way to replace tension with partnership. It feels like it's slow because it can take longer to get started, but ultimately it's fast because you're more likely to complete the work without disruption.
In addition, longevity as a senior leader is just as much about maintaining your relationships as it is about standout successes. You'll see a bunch of folks who burn bright for a while but later lack the support to make forward progress. If you want to avoid that fate, learn to never be wrong and never stop practicing.
