For a long time, my default leadership style was hands-on. I stayed close to implementation, offered answers, and often built alongside the team.
As I began leading larger groups of senior specialists, that approach needed adjustment. The people closest to a problem often had more context than I did. My contribution could become an interruption, especially when an early suggestion from me narrowed the discussion before the team had explored the alternatives.
One of my earliest managers at Google showed me a different approach. He used questions to understand the reasoning behind a decision and help people examine it. Over time, I began doing more of that myself.
I ask about assumptions, evidence, and alternatives. What would have to be true for this approach to work? What result would make us abandon it? Where does the disagreement actually sit?
That last question has been particularly useful. A discussion that appears to be about architecture may turn out to be about different expectations for reliability, different timelines, or different definitions of success. Understanding those differences gives us something concrete to resolve.
But questions carry authority too. “Have we considered X?” can travel through an organization as “We should do X.” A team may interpret an option I intended only to mention as a request to investigate it. I have learned to state whether I am exploring, recommending, or making a decision. The question mark does not communicate that distinction reliably.
Questions can also feel like a test. If someone lacks the context to reason through the problem, asking them a sequence of questions may create anxiety rather than insight. They may need an explanation, a worked example, or a direct recommendation.
And sometimes I already have a decision in mind. Asking questions until the team arrives at my preferred answer obscures that fact. It is clearer to state my view, explain the reasoning, and invite disagreement.
This approach requires preparation. I need enough understanding to ask useful questions and assess the answers. Asking from informed curiosity is different from making the team compensate for work I have not done.
I use questions most when the team has the expertise and the problem remains ambiguous. When a decision is urgent or execution needs a clear boundary, I give direction. The adjustment for me has been learning to recognize what the situation needs—and being explicit about what I am asking the team to do.
What I was reading
These reflections come from my own leadership experience, including observing one of my earliest managers at Google.