I see technical leaders that diminish their impact by contributing to a lessor part of the problem or discussion. The most impactful technical leaders I see tackle the most important part of the problem. They contribute to the most important part of the discussion or problem being solved. Focus is important as a leader because you can’t do everything all the time. And focusing on the most important part of problems distinguishes you as a technical leader.

How do you know where to focus? Take stock of who is in the meeting and what is the goal of the meeting. If you’re one of the more senior folks in the meeting, folks are looking to you to help prioritize what’s important. Ask yourself what’s on the critical path to the goal. If you focus on apparently trivial details, that’s a sign that the most important stuff is already taken care of. For example, have you ever been in a meeting when someone senior focused on some apparently bureaucratic detail? Did that make you think more or less of that person as a leader?

If you’re in a group of your peers, consider where you can make the most impact on the goal of the meeting. If the goal of the meeting isn’t clear, one of the best moves to make is to ask “Let’s be clear about what the goal of this meeting is…” - trust me that’s a move that everyone will appreciate because they’re asking the same question you are asking.

When you’re about to contribute, ask yourself “if I don’t contribute here, will the goal still be achieved?” I recognize this may be difficult because you feel compelled to contribute to prove it was worth you attending this meeting. And there’s truth to the fact that you should be contributing. You should be contributing something impactful; if the goal can be achieved without you there maybe you should decline next time. Keep pressing yourself to find the most impactful thing you can contribute.

Another reflective question “Is my contribution directly related to the core of the problem being worked?” I often see technical leaders contributing in a way that distracts from the goal rather than building on it. It’s slightly different than the first question in that some technical leaders don’t realize they are distracting from the problem by contributing an idea that is top of mind for them. For example, a technical leader that says “this would be a great problem for Python” because they see adoption of the new language as important. Be as “in the problem” as possible and leave your baggage at the door.

Conversely, don’t contribute something that is not the most important part of the problem being worked. I see technical leaders diminish their impact by contribute lesser insights. Operate at the top of your ability, and folks will see the impact of your contribution. Operate any lower and that’s what folks will associate with you. When you contribute something like “you didn’t follow the process” to a hairy technical problem, folks will assume you don’t have any insight to contribute to the technical problem at-hand. Even acknowledging that the hairy part of the problem has no easy answers, and working to wrestle with it has more weight than falling back on something not core to the problem.

Probe to get clarity on where the real complexity lies. Ask the question, “what’s at the heart of this problem?” or “what should we be worried about that we’re missing here?” Be aware that if this is all you do, it will come across as entirely without content. These questions can be very helpful early in the discussion to nail down the consensus of the group on what is the real nut of the problem. Follow-up on these questions with statements to help nail it down, or ideas to propel the discussion forward.

Let’s take a particular example - a meeting and your contribution to that meeting. Let’s say it’s a technical review of a story being implemented. One of the engineers you work with is presenting the technical design for the group to review and provide feedback. Your role is to help make the design as good as it can be to fulfill the requirement. Examples you might focus on are that the design will be difficult to maintain over the long-term, that the performance characteristics won’t allow it to scale, that the administrative overhead of managing it in production will be larger than normal. Examples you might not want to focus on are why the language chosen isn’t as good as your favorite language, why the person didn’t follow the right process leading up to the design review or that the format presented is non-standard.

When you operate at the top of your ability, and that’s how your team will treat you. If you operate in the middle even when you have the ability to solve hard problems, folks will associate you with contributing less and having less ability. Solve the hardest problems you can solve, and leave the easy stuff for others. Or better, delegate the easy stuff to others. But that’s a different topic...