Why Your Ideas Keep Getting Shut Down

Dev Leader Weekly 141

May 25, 2026

TL; DR:

When your ideas always get shut down, it’s rarely the ideas
How you pitch them is the lever you actually control
Genuine curiosity beats trying to win the argument
Join me for the live stream (or watch the recording) on Monday, May 25 at 7:00 PM Pacific!

Why Your Ideas Keep Getting Shut Down

Another week, another ExperiencedDevs Reddit post that hit me a little harder than most. This time it was from someone who’s just exhausted from speaking up. They keep proposing ideas, the team keeps ignoring them, and they’ve reached the “why am I even bothering” stage. You can feel the defeat coming through the screen. That’s a pretty rough place to be in your job -- and it’s the kind of thing I think about a lot from the manager side too, because I genuinely need the people on my teams to feel like they can speak up.

But after digging through their post and the comments, I think most of the advice flying around misses the real lever. So let me walk through how I’d actually approach this if it were happening to me.

You can check out my full thoughts on this in the video below:

The Reddit Post That Got Me Thinking

The post itself doesn’t give a ton of context. The poster says they’re experienced on the team but not the tech lead, and they keep getting shut down when they propose ideas -- particularly around scoping and design. They feel like people are over-engineering or building things that don’t need to exist. The main concrete example they gave: their team wants to support multiple file formats when, in their view, the system only needs CSV.

That’s basically all we get. So I’m going to do what I usually have to do with these threads -- make some assumptions, walk through the most likely scenarios, and try to be useful even with incomplete information. If you’ve been here before, this is similar to how I worked through the post from someone telling their manager they were burnt out -- there’s only ever one side of the story, and you have to read between the lines a bit.

It’s Probably Not Your Ideas

Here’s the assumption I’m going to start with: statistically, this person doesn’t always have bad ideas. Nobody has only bad ideas. Some are going to be good, some are going to be okay, some are going to be off-base. That’s true for me, that’s true for you, and that’s true for the Reddit poster.

So if their ideas are being consistently rejected -- not occasionally, not in specific scenarios, but constantly -- the most likely explanation isn’t that the ideas themselves are uniformly bad. It’s much more likely that the way the ideas are being pitched is the problem.

I’ll use the file format example to walk through this. Imagine you’re in a design discussion and someone proposes supporting five file formats. You think it’s wasteful and unnecessary. You speak up:

“We don’t need that. That’s a waste of time.”

Now, you might be completely right. Maybe the team really doesn’t need it. But how does that land on the person who proposed it? They’ve now had their idea bluntly shut down with no engagement and no follow-up. They’re going to defend their position. The room is going to side with whoever feels more reasonable and can make a better case for their perspective. And you just lost a conversation you were trying to win.

I see this pattern a lot, and it shows up the worst in technical design debates where the answer genuinely isn’t clear-cut. I wrote about a perfect example of that recently in the Feature Slicing vs Clean Architecture comparison -- both are defensible, both have tradeoffs, and the “right” answer is contextual. If you come into that kind of debate with your mind already made up, you’re going to get rolled by whoever is willing to actually engage with the tradeoffs.

Try Genuine Curiosity Instead

The single biggest change I’d suggest if you keep getting shut down: lead with genuine curiosity, not your conclusion.

Same file format scenario. Someone proposes five formats. Instead of “we don’t need that,” try:

“Interesting -- what’s driving the need for the extra formats? Is this coming from customer requests, or is it more anticipatory?”

What does that buy you? Information you didn’t have before. Maybe they had a conversation with the product owner that you weren’t in. Maybe they’ve seen customer support tickets you haven’t seen. Maybe they’re just optimizing for “we’ll need flexibility later” with no real data behind it. You don’t know until you ask.

Actionable Tip -- A genuinely curious question has a few properties:

It assumes the other person has a reason that makes sense from their seat
It is asked before you’ve reached a verdict, not after
It is phrased as a question, not a leading statement (”Why do we need this?” is leading. “What’s driving the need?” is curious.)
You actually listen to the answer and let it change your position if the new information warrants it

And this last point is the one most people skip. If you ask a curious question, get new information, and still don’t even reconsider your position -- you weren’t being curious. You were performing curiosity to look open-minded before reasserting your original take. People can feel the difference.

The Goal Isn’t To Be Right

This sounds funny to say but, it’s the part that flips everything: the goal isn’t to win the argument. The goal is to deliver more value to your customers. Those are very different goals, and they pull you in very different directions.

If you’re optimizing to win the argument, you go in hard, shut things down, and protect your position. If you’re optimizing to deliver value, you go in curious, learn what the other side is actually optimizing for, and look for compromises.

In the file format example, that might look like:

“Personally, I don’t think shipping five formats is worth the time right now -- but I hear that flexibility matters to you. What if we shipped with the main format, but we put a thin abstraction over the file I/O so adding a second format later is a small change instead of a rewrite?”

Now you’re proposing a middle path that addresses both concerns. You’re optimizing for time. They’re optimizing for flexibility. The abstraction layer gives you both -- maybe. Now, my contrived solution might absolutely be the wrong move in some real scenarios. Sometimes the abstraction is more cost than the optionality is worth. The point isn’t that I cracked the technical answer in two paragraphs. The point is that the conversation is now productive instead of adversarial.

And from a team-dynamics perspective, this is the kind of behavior that builds trust over time. I wrote about this dynamic in the Effective Software Teams: Islands and Autonomy issue -- teams that work well aren’t the ones where one person is always right. They’re the ones where people actually engage with each other’s ideas.

When You Always Feel Unheard

If you keep walking out of meetings feeling like nobody listens to you, there are two scenarios I generally see:

Most of the time, you’re communicating in a way that’s getting in your own way. Your ideas might be great, but they’re landing as attacks, as shutdowns, or as “I’ve already decided and I’m now just informing you.” Fix the delivery and a lot of this changes.
Sometimes, the team really isn’t a fit. You can have the cleanest communication style in the world and still be on a team where people genuinely don’t want to listen. I covered the version of this where it’s specifically your manager who won’t engage in the issue on managers who refuse to give feedback -- that one has a different solution path.

The honest answer is that it’s almost always some mix of both. Some of it is on you, some of it is on the environment. The part you control is your delivery. Start there.

Actionable Tip -- Before you bring something up next time, ask yourself:

Am I going in trying to be heard, or trying to be right? Those produce very different conversations.
Have I actually asked the other side why they want what they want? Or am I just waiting for my turn to argue?
If I’m wrong, am I prepared to actually update my view? If not, the curiosity isn’t real.
Is there a middle path I haven’t proposed yet? Most “either/or” debates have a “both” answer hiding in them.

Don’t Give Up On Speaking Up

The thing I really don’t want anyone to take away from a Reddit thread like this is “well, I guess I’ll just stop speaking up.” That’s the worst possible outcome. As a manager, the people who quietly disengage are the hardest to help -- I can’t address what I can’t see. And as a teammate, that voice going silent makes the whole team worse.

There’s also a flavor of this where the person who keeps speaking up ends up shouldering everything because nobody else volunteers. That has its own downstream cost, and I dug into it in The Hidden Cost of Being the Team Hero. The fix isn’t “speak up less.” The fix is “speak up smarter, and don’t carry the team on your back while you do it.”

If you’re in this spot right now, please don’t give up on it. Try the curiosity angle for a few weeks. Try the middle-path framing. Pay attention to whether the conversations start landing differently. If they do, that’s your answer about what was actually going on. And if they don’t -- after you’ve genuinely changed your approach -- then yeah, you might be on a team that’s never going to hear you, and that’s a different conversation entirely.

Dev Leader Weekly

Discussion about this post

Ready for more?