Having discussions with multiple tech executives every day, I get to see the kinds of questions they are spending their brain cycles on getting answers for. It might be questions that they are coming with to me, or that as we are sitting someone barges in with an “urgent” issue.

Observing this, I notice the tendency of leaders to supply answers or solutions reflexively. Here are some examples:

“Alice from Product wants us to stop working on the widget and focus on the dingus. Is that ok?”

“Tell her we will continue as there are three days left this sprint, and we’ll start work on the dingus next week.”

“Bob wants to write the new micro-frontend in Svelte, he swears that he can rewrite it to our regular React in two days if we decide so later, alright?”

“No, tell him he can Svelte it up in next month’s hackathon.”

“Will team B’s work be ready in two days? We will want to integrate with them by then.”

“Should be. Let me talk to them and get back to you.”

“Sam just had a great idea of turning these documents into pictures so we can serve them differently and save on costs, any reason not to?”

“We’re contractually obligated to serve the assets as-is, so how about no?”

Bam bam bam. One after the other, the VP Engineering just helped several different engineering managers in five minutes. Great success? Think again.

Even more than your average person, people from a technical background love solving issues. Yet these situations are precisely where you should use your ability to think in abstractions and consider the generic case. With my coaching clients, I often refer to this as Questioning the questions.

Take a step back, and instead of merely answering what you think is the right solution, question whether this is a question that you should be asked. Sometimes it is an issue where your input is needed, yet often this boils down to one of three themes:

• Missing guidelines: Instead of answering every instance of the question for everyone in the organization, you should put in place a value or a simple if-then concept that your managers and ICs know how to follow. Don’t be a bottleneck, and don’t keep repeating yourself.
• Missing empowerment: It might be because you’ve been around for ages, because of vibes people get from you, or because of coaching they need, but it is a widespread issue to have managers too dependent on their boss for decisions they should be making themselves. Help them be genuinely empowered and know what is up to them.
• Missing Product Mastery: When Engineering are missing the bigger picture, they’re just a highly paid out-sourcing department that happens to sit in-house. You shouldn’t be the only one that understands how things work outside of the purely technical aspects.

Let’s revisit those earlier questions with this in mind:

“Alice from Product wants us to stop working on the widget and focus on the dingus. Is that ok?”

Missing guidelines: We never change things up mid-sprint unless there’s a real emergency, and all managers should know it.

“Bob wants to write the new micro-frontend in Svelte, he swears that he can rewrite it to our regular React in two days if we decide so later, alright?”

Missing guidelines: If someone wants to add something new to our stack that replaces a tool we already have, then they either have to show a clear business case for doing so, or wait for our quarterly hackathons to give it a go.

“Will team B’s work be ready in two days? We will want to integrate with them by then.”

Missing empowerment: Why are you even in the loop here? Tell them to figure it out with team B directly.

“Sam just had a great idea of turning these documents into pictures so we can serve them differently and save on costs, any reason not to?”

Missing Product Mastery: Maybe all the senior Engineering staff needs to have a sit down with Product again to review the business needs of your clients and why some things that might seem like weird constraints are, in fact, essential.

Now you’re left with answering the right questions and will create a culture that should also trickle down the organization of empowerment and mastery.