The Tension in “So… what do you think?”

It happens more often than I care to admit. Someone on my team drops a draft or an idea in front of me and asks how to evaluate early ideas—“So… what do you think?” There’s a pause, sometimes awkward. I know this moment—the mix of hope, uncertainty, and that little fear behind their eyes. If you’re in this position too, you feel the tension, the responsibility. Every time.

There’s always a split-second debate in my head. Do I say what I really think? Is now the time to push them harder, or do I need to thread the needle and not crush their energy? Maybe a redirect would help, but will it land right, or just deflate them? These questions never really go away.

Honestly, I’ve had some stupid ideas. No pretending otherwise. The difference is, I had leaders who didn’t confuse a bad idea with a bad engineer. If my own thinking gets a pass sometimes, it’s only fair we give others that same room.

Here’s the larger issue. When we fail to evaluate bold bets early, imperfect ideas get judged too quickly—and that shrinks our pipeline of bold bets. It slows real innovation. The pressure of early judgment and criticism directly holds back productivity and stifles idea flow—social anxiety and criticism fuel that drop. And if I, as an established engineering leader, have had bad ideas… then your team will too. It’s not about lowering the bar. It’s about keeping the door open just long enough for someone to show you why their gamble deserves a chance. That’s where the learning really happens.

From Gut Instincts to Evidence: Rethinking How to Evaluate Early Ideas

Here’s the trap I see all the time. The moment someone floats a new approach, the question that instantly shuts everything down is, “Is this stupid?” That question leaves people weighing how not to look foolish. Better is, “Will this work?” This gets everyone testing the thing itself, not the person behind it. It’s a subtle shift in tone, but it’s what keeps teams open to bold bets instead of defaulting to a safe idea review.

Think of early-stage ideas like prototypes in a wind tunnel. You aren’t judging the shape by how “creative” it looks. You’re watching the airflow metrics. Success criteria are the gauges that tell you if the concept could cut through. Validation plans are the test runs. Let’s see what happens when we actually turn on the fans. You don’t need perfect models to learn; you need repeatable tests that show signal before you commit more resources.

This works best when review means looking at the proposal, not the person, and when you present fair analysis and normalized ranges. Outcomes, not job titles, are what matter. I’ll admit, it took me way too long to separate feedback about the work from feedback about the teammate. Your ideas aren’t your identity, and healthy teams know how to treat them that way.

So, when thinking about how to evaluate early ideas, what should success criteria and validation plans actually measure, right now? You’re asking: does this solve the problem in front of us, with the resources and constraints we have this week? Look for outcomes you can observe fast—real signal, not vague optimism.

Ready to run idea reviews that don’t kill momentum? Your Move. The “Will This Work?” Leadership Playbook.

The “Will This Work?” Leadership Playbook: Method and Scripts

Start with the root. Every time I vet a new idea, I use an idea evaluation framework and ask the team, “What’s the real problem you’re solving, and how will we know if your approach actually works?” Clarity upfront is half the battle. Make success criteria simple—real-world metrics anyone can check. For example, if it’s a deployment change, maybe “no downtime and all users see new data in under a minute.” Once you’ve got that, you can talk about how to measure progress, not just “I think it’s better.”

Next, you need to surface what’s not clear. Here’s a move I use: I say directly, “Here’s what I’m unsure about—and why. What are you seeing that I’m not?” It’s a prompt that opens space for context and keeps it from feeling like an attack.

I’ve learned to state my doubts as questions, not conclusions. “I’m not convinced the API will scale under real load, but maybe I’m missing something in your design—can you walk me through it?” You’ll hear details you didn’t expect and, more often than not, find out there’s more logic or data behind the idea than was visible at first glance. This script does two things. It names gaps, and it invites the teammate to fill them—without forcing defense. The tone is critical. If you sound like you’re cornering someone, you’ll kill curiosity. If you frame it as, “Let’s illuminate blind spots together,” you get team learning out of the review, not just judgment.

Then, co-design how you’ll actually test the idea. Ask, “What’s the smallest proof we can run—ideally this week—that gives the clearest yes or no on those success criteria?” Make it outcome-focused idea testing by tying the test back to real outcomes, not just theoretical claims. If we’re picking a new storage system, maybe it’s a single feature with mock data before live users ever touch it. Fast feedback beats big bets. You’re looking for anything that gives clear signal. Something you and the team can look at and say, “Did we hit the bar or not?”

Once a test is agreed, back the person—even if doubts remain. Set clear checkpoints, run peer-led feedback rituals, and ask for updates. “Show us what you learned by Friday, and let’s regroup to see if it hit our success mark.” The act of consulting the team, hearing their input, and factoring in their views backs psychological safety in innovation—consultative leadership is the engine for shared momentum. I’ve noticed: when people see you trust them to run with it, they pick up speed—and you get a pipeline full of learning, not just safe picks.

Just as important—keep track of early ideas, revisit the promising ones (even if the first run didn’t work), and celebrate teammates who keep pitching bold bets. When you do that, you’re protecting the pipeline that keeps innovation alive. Your Move.

Addressing the Fears: Time, Quality, and Morale

Let’s start with the time argument. I hear it constantly—“Won’t this take too long?” The truth is, a bit of structured curiosity at the front saves huge blocks of time later. When you carve out space to clarify success criteria and dig into what’s really needed, you stop ideas from wandering down paths that burn weeks and only deliver dead ends. You also get to yes or no faster, instead of living in that drawn-out, maybe-limbo that drags everyone’s momentum. Upfront investment in a sharp review keeps the team moving forward, not spinning their wheels.

Now, about the fear of the “quality bar” slipping. The bar doesn’t disappear just because you’re curious or open. Success criteria—real metrics, observable outcomes—are the bar. Tests are the proof. High psychological safety paired with accountability powers rapid learning and growth—feedback and real responsibility set the bar and accelerate progress. So bold bets don’t get a free pass. They have to show clear signal, not just confidence or vibes.

Let’s talk honestly about the demotivation worry, because I’ve felt it directly. The “no” is tough—on both sides. If you’re not careful, shutting an idea down feels personal and people stop raising their hand. Here’s what changed for me. When we tie rejection strictly to evidence (not personal taste), and deliver that message respectfully, it keeps dignity intact.

I’ll say it directly—“This didn’t hit our test criteria. Here’s what we saw. The idea’s not right for now, but your willingness to bring it forward is exactly what keeps our momentum alive.” You don’t have to cushion everything, but you do have to make it clear. Turning down a proposal isn’t shutting down a person. That’s what builds trust and ensures the next bold idea still gets airtime. We’re here to test, learn, and iterate—not to get it perfect on the first shot.

If I’m being honest, I wish I could say this approach always keeps morale high, but there’s still this undertow in team dynamics I haven’t quite solved. Some folks bounce back. Others quietly withdraw for weeks. Even now, I haven’t found a way to guarantee everyone stays engaged after a tough review. It’s still a work in progress.

In the end, pairing curiosity with clear criteria doesn’t lower standards. It accelerates learning and consistently raises product quality—without ever rewarding weak ideas. That’s real engineering leadership.

Making It Real: What to Do Next (Checklist, Scripts, Commitment)

Grab your next idea review and walk through these steps right now. Jot down what success looks like, call out what feels uncertain, map the smallest possible validation, ship a minimal version early, and pick a regular check-in rhythm—weekly or biweekly works. This gives shape to the whole review, not just the kickoff.

Open the discussion like this: “I’m curious what led you here—can we walk through it together?” Keep the focus on the proposal. “Just to be clear, I’m responding to the idea, not you. What context should I know before we dive into the tradeoffs?” When teams see reviews framed this way, the back-and-forth cycle gets cut down and progress accelerates. So start with genuine curiosity.

If you do anything today, let it be this. Protect your pipeline and let outcomes, not ego, decide who moves forward. Try it out, mark the shift, and invite one other peer to do the same. #LIPostingDayApril