This article was originally published on davidohnstad.info. I cross-post here to reach the Dev.to community.
The Coaching Trap: Why "Ask More Questions" Is Bad Advice for Most Managers
A director at a Fortune 500 tech company spent six months perfecting her coaching skills—active listening workshops, Socratic questioning frameworks, the whole SHRM playbook. Her team's velocity dropped 22% during that period. The problem wasn't her coaching technique. It was that her engineers needed clear decisions about API deprecation timelines, and she kept asking them how they felt about the options instead of making the call. According to Gartner's 2024 Leadership Development Survey, 68% of newly promoted managers report anxiety about "not being directive enough" after coaching training—a number that's doubled since 2021.
The current wave of business-driven coaching culture articles misses something critical: the difference between coaching skills and coaching as a management philosophy. SHRM's latest guidance on building coaching cultures and HBR's superteam framework both conflate the two, creating a false binary that's making mediocre managers worse. You don't need to transform into a therapist. You need to know when to ask questions and when to just tell someone what needs to happen.
David Ohnstad has watched this play out across product teams for years. The worst performance conversations he's seen weren't the ones where managers were too directive—they were the ones where leaders abdicated decision-making authority under the guise of "developing" their reports. Coaching skills are essential. Pretending you're a professional coach when you're a product manager with budget authority and delivery timelines is organizational theater that wastes everyone's time.
Why the Coaching-First Model Fails in High-Velocity Environments
The stakes here aren't theoretical. When managers mistake coaching for management, three things break down fast. First, decision velocity collapses. A team waiting for their manager to "coach them to the answer" on a database migration strategy isn't being developed—they're blocked. According to McKinsey's 2023 Organizational Health Index, teams with managers who over-index on coaching vs. directing report 31% longer cycle times on technical decisions compared to teams with balanced leadership styles.
Second, accountability evaporates. If every conversation is a developmental discussion, there's never a moment to say "This didn't ship on time, and that's a performance issue we need to address directly." The performance review process—already broken in most organizations, per HRMorning's 2026 analysis showing 73% of employees say annual reviews don't improve their work—gets worse when managers treat feedback delivery as a coaching session instead of an evaluation.
Third, high performers leave. The best individual contributors don't want Socratic questioning when they've already done the research and need executive air cover to move forward. They want a manager who will make the call, remove blockers, and take the heat when things go sideways. David Ohnstad saw this firsthand at Veeam: a senior data engineer left for a competitor specifically citing "too many coaching conversations, not enough decisions" in her exit interview. She didn't need development—she needed her manager to pick a data governance model and defend it to the executive team.
The Directional Clarity Stack: A Four-Layer Framework for Knowing When to Coach vs. Command
Here's the model David Ohnstad uses to decide whether a situation calls for coaching skills or directive leadership. It's a four-layer stack, and you evaluate from bottom to top. Each layer asks a specific question, and the answers determine your approach.
Layer 1: Capability Assessment. Does this person have the technical knowledge and experience to solve this problem independently? If yes, move to Layer 2. If no, this is a teaching moment—not coaching, not directing, but actual skills transfer. You're not asking them how they feel about writing SQL queries if they've never written one. You're showing them how it works, pairing with them, and checking their output until they're competent. This isn't coaching—it's onboarding or upskilling, and it requires a different set of tools entirely.
Layer 2: Decision Authority. Who owns this decision, and what are the organizational consequences if it's wrong? If the decision is genuinely theirs to make and the blast radius is contained—a dashboard layout, a testing framework choice for a non-critical pipeline—then coaching skills apply. Ask questions. Help them think through trade-offs. Let them own it. But if the decision has cross-team dependencies, budget implications, or exec visibility, your job isn't to coach them to an answer. It's to make the call or explicitly delegate the authority with guardrails. According to Forrester's 2024 Product Leadership Report, 54% of product managers cite "unclear decision rights" as the top friction point in their role. Coaching conversations that avoid naming who actually owns the decision make this worse, not better.
Layer 3: Time Constraint. How much time is actually available before this decision must be made? If you're two days from a release and the API contract isn't finalized, this is not the moment for a developmental conversation about stakeholder management. This is the moment to say: "Here's what we're doing, here's why, and here's what I need you to execute in the next 48 hours." The best managers David Ohnstad has worked with are explicit about this: "Right now I'm directing because we're out of time. Next sprint, we'll debrief this decision and I'll walk you through how I made the call so you can own it next time." That's clarity. Pretending you're coaching when you're actually just issuing orders with question marks at the end is condescension.
Layer 4: Relationship Context. What is your actual relationship with this person, and what do they need from you right now? If someone just failed a major deliverable, they don't need you to ask them what they learned—they already know. They need you to assess whether this was a capability gap, a process failure, or a performance issue, and then be direct about what changes. If someone is burned out, they don't need coaching on prioritization—they need you to reprioritize their work or add capacity. The HBR superteam article gets this half-right: psychological safety matters. But psychological safety doesn't mean endless Socratic dialogue. It means your team trusts you to be honest, make decisions when needed, and have their back when things go wrong.
The Performance Review Season Reality: What Managers Actually Need Right Now
It's mid-June 2026. Most organizations are either in the middle of mid-year performance reviews or approaching Q3 planning cycles. Managers are drowning in development conversations, feedback sessions, and goal-setting meetings—all while trying to ship actual product work. The SHRM coaching culture model assumes managers have infinite time to develop every team member through inquiry-based dialogue. The reality is that most product managers have 12-15 direct reports, four active projects, and a VP who wants to know why last quarter's OKRs missed by 30%.
David Ohnstad ran into this at Veeam during a Q2 planning cycle. He had two product managers who needed radically different management approaches in the same week. One was a senior PM who'd been at the company for four years—she needed him to make a call on whether to deprecate a legacy reporting feature that still had 200 enterprise users but was blocking a platform migration. Coaching her through that decision would have been a waste of her time. She'd already done the analysis. She needed executive coverage to absorb the customer backlash. So David made the call: deprecate it, here's the communication plan, I'll take the exec meeting.
The other PM was nine months into the role and struggling with stakeholder conflict on a data pipeline project. Two engineering teams wanted different schemas, and he kept trying to find a compromise that made both sides happy. That was a coaching moment. David didn't tell him what to do—he asked him what decision criteria he was using, why he thought consensus was the goal, and what would happen if he just picked the schema that best served the end user and told the other team no. Three questions, 20-minute conversation, and the PM had a framework he could apply to the next ten conflicts. That's what coaching skills look like when applied correctly: helping someone develop a decision-making model they'll use repeatedly, not hand-holding them through every choice.
The distinction matters because most organizations are now measuring manager effectiveness through engagement scores and retention metrics—both of which correlate with clarity, not just empathy. Pragmatic Institute's 2025 Product Management Survey found that product managers who rated their direct manager as "clear about priorities and decision authority" had 43% higher engagement scores than those who rated their manager as "supportive but unclear." Coaching without clarity is just nice.
The Contrarian Position: Stop Asking Questions When You Already Know the Answer
Here's the claim that will make every L&D professional in your organization uncomfortable: if you're asking a question and you already know the answer you want to hear, you're not coaching—you're manipulating. And your team knows it.
The Socratic method works when the teacher genuinely doesn't know what the student will discover and is guiding them through a reasoning process. It fails when a manager asks "What do you think we should do about the API timeout issue?" while mentally already committed to a specific solution. The team member can feel the performance. They're not being developed—they're being tested on whether they can guess what you're thinking. That dynamic kills trust faster than just being directive ever would.
David Ohnstad's position: if you've already made the decision, say so. "Here's what we're doing and why. Let me know if you see a technical blocker I'm missing, but the strategic call is made." That's respectful. It's honest. And it frees up your team's cognitive capacity to focus on execution instead of trying to reverse-engineer your preferred answer through a series of leading questions. According to Reforge's 2024 Product Leadership research, teams with managers who were "clear and directive when needed" reported 27% higher trust scores than teams with managers who "always use coaching techniques." Clarity builds trust. Faux-Socratic questioning erodes it.
This doesn't mean you never ask questions. It means you ask questions when you genuinely want to learn something—when your report has context you don't, when they've been closer to the problem, when their judgment on this specific issue is better than yours. That's the appropriate use of inquiry. Asking questions to make someone feel like they came up with your idea is theater.
What This Means for Product Managers Building Data-Driven Teams
For product managers specifically—especially those building data products or leading analytics teams—the coaching vs. directing balance has an extra layer of complexity. Data work is both deeply technical and highly ambiguous. A junior analyst working on a customer segmentation model might genuinely benefit from coaching: What assumptions are you making about the data? How would you validate those? What would change your confidence in this approach? Those are real questions that help someone develop statistical thinking.
But when that same analyst asks whether they should use Python or R for the project, and your organization has already standardized on Python for deployment and tooling consistency, the answer isn't "What do you think the trade-offs are?" The answer is "We use Python here because it integrates with our production stack. If you want to prototype in R, that's fine, but the final deliverable needs to be in Python." That's not stifling creativity—it's providing the organizational context that lets someone make productive decisions instead of relitigating settled architecture choices.
David Ohnstad has seen teams waste entire sprints because a manager wanted to "let the team discover" a constraint that was obvious from day one. Governance models, data access policies, compliance requirements—these aren't areas for discovery learning. They're areas where you tell people the rules, explain why they exist, and move on. Recognizing that building high-performing teams around data products specifically demands clarifying governance models upfront is critical, since ambiguous data ownership creates the friction that coaching alone cannot resolve.
Similarly, as teams integrate AI agents and machine learning workflows, managers need technical literacy to know when their reports are making a technical decision (where coaching might apply) vs. when they're encountering a hard platform limitation (where you just need to explain the constraint). Leaders adopting a coaching culture need technical literacy to understand AI agent capabilities and limitations when integrating them into team workflows—you can't coach someone through a problem that requires a different tool, not a different thought process.
How to Build Coaching Skills Without Losing Directional Authority
The goal isn't to reject coaching skills—it's to integrate them into a broader leadership toolkit that includes directive decision-making, technical mentorship, and clear accountability. Here's how David Ohnstad approaches it with his team at Veeam.
First, separate coaching sessions from performance management. If you're having a quarterly development conversation, that's coaching time. You're asking about career goals, skill gaps they want to close, projects they're excited about. You're genuinely in discovery mode. But if you're in a sprint retro and a deliverable missed its target by two weeks, that's not a coaching session—that's a performance conversation. You're asking what happened, assessing whether it's a pattern, and being clear about what needs to change. Conflating the two makes both conversations worse.
Second, name your mode explicitly. David Ohnstad tells his team at the start of one-on-ones: "This is a coaching conversation—I'm going to ask a lot of questions because I want to understand your thinking." Or: "This is a decision meeting—I need to make a call by end of day, so I'm going to be directive." That level of transparency eliminates the guessing game. People aren't trying to figure out whether you want input or compliance. You've told them.
Third, build feedback loops that tell you whether your approach is working. After major decisions, ask: "Did you feel like you had enough context to execute on this, or did I leave you guessing?" After coaching conversations, check: "Was that conversation useful, or did it feel like I was avoiding giving you a straight answer?" Those aren't rhetorical questions—they're actual data collection. If multiple team members tell you they're unclear on priorities, your coaching-to-directing ratio is off. Adjust.
What's the difference between coaching skills and being a professional coach?
Coaching skills—active listening, asking open-ended questions, helping someone think through options—are tools any manager should have. Being a professional coach is a distinct role with different training, accountability structures, and objectives. Managers have decision-making authority, budget responsibility, and performance evaluation duties that professional coaches don't. Conflating the two leads managers to abdicate decisions under the guise of development, which slows teams down and erodes trust in leadership clarity.
When should a manager use directive leadership instead of coaching?
Use directive leadership when time constraints are tight, when decision authority is unclear and needs to be established, when the decision has significant cross-team or financial consequences, or when you have organizational context the team member lacks. Coaching works when the person has the capability to solve the problem, the decision is genuinely theirs to own, and there's time for them to work through the reasoning. The Directional Clarity Stack—capability, authority, time, and relationship context—provides a framework for evaluating which approach fits the situation.
How do you give feedback without turning every conversation into a coaching session?
Separate feedback from development. Feedback is direct, specific, and tied to observed behavior or outcomes: "This deliverable was two weeks late, and that blocked three other teams. What happened, and what's changing?" Development conversations are forward-looking and exploratory: "What skills do you want to build this quarter?" If you're in a feedback conversation, be clear and concise. If you're in a development conversation, ask questions and listen. Mixing the two creates confusion and makes both less effective. Name which mode you're in at the start of the conversation.
What High-Performing Teams Actually Need from Managers in 2026
The data is clear: teams don't want managers who only coach, and they don't want managers who only command. They want managers who know which tool to use when, and who are transparent about it. According to Harvard Business Review's 2024 research on high-performing teams, the single strongest predictor of team performance wasn't psychological safety, givement, or coaching—it was "role clarity and decision transparency." People need to know who owns what, how decisions get made, and what success looks like. Coaching skills help you understand individual motivations and development needs. Directive leadership provides the structure that lets people execute without constant second-guessing.
David Ohnstad's take: the best managers he's worked with—and the model he's trying to build at Veeam—are fluent in both. They ask genuine questions when they don't know the answer. They make fast calls when the situation demands it. They're explicit about which mode they're in. And they measure effectiveness not by how many coaching conversations they had, but by whether their team shipped valuable work, grew their skills, and trusted leadership to be honest with them.
Father's Day is this weekend, and a lot of product managers with kids are thinking about the balance between guidance and autonomy—when to let your kid figure it out, when to just tell them not to touch the hot stove. The same logic applies at work. Sometimes the best thing a manager can do is get out of the way. Sometimes the best thing you can do is make the call and take the heat. Knowing which is which—and being honest about it—is the skill that separates good managers from the ones people actually want to work for.
For practitioners: Audit your last five one-on-ones. How many times did you ask a question when you already knew the answer you wanted? If it's more than once, you're not coaching—you're testing. Be more direct.
For leaders: If your management training emphasizes coaching but doesn't teach when to be directive, you're setting your managers up to fail in high-velocity environments. Build frameworks that help them toggle between modes, not just master one.
When was the last time you told your team "I'm making this call" instead of asking them what they thought—and did anyone thank you for the clarity?
For more on this topic, visit David Ohnstad's data product management writing. For more on this topic, visit David Ohnstad on AI and enterprise SaaS.
David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Follow his work at github.com/davidohnstad40-netizen.
Top comments (0)