A practical guide for junior developers on raising concerns, getting heard, and building credibility when you think the room is wrong.
Read the full newsletter post here.
There’s a specific kind of dread that hits us early in our tech career.
You’re sitting in a sprint planning meeting, or a design discussion with your team. A senior engineer proposes something. And a quiet alarm goes off in your head. Their approach or thinking is going to cause problems. I can see it.
You look at everyone in the zoom meeting/room. Everyone seems to be nodding along. Maybe you’re missing something. Maybe you should just stay quiet. You’re filled with doubts.
I remember feeling stuck with 3 questions in this situation:
➡️ “Should I say something?”
➡️ “Will it really matter if I say something?”
➡️ “What if I am totally wrong?
This situation is more common than anyone admits. How you handle it will shape your reputation, your growth, and - if you’re right - the outcome of the project.
Here is my mind map for navigating this without torching relationships or swallowing your instincts 👇
Subscribe to get your free guide on how to make a great first impression HERE
Pressure test yourself before speaking
Before I say anything, I like to spend sixty seconds asking myself a few honest questions.
🤔 Do I understand the full context?
There’s a good chance the senior folks have considered constraints I don’t have visibility into - legacy system quirks, a business reason for why they made a decision, or a failed attempt at exactly what I’m about to propose.
If you want to raise your concern while also being respectful of the research that has already gone into the decision, here’s two ways that I think work best:
1️⃣ You can try to surface your concern as a question instead of framing it as a correction. This allows you to keep an open mind about things you may not know, while showing your thoughtfulness and curiosity to the team.
2️⃣ You can label it as a hunch. “I have a gut feeling about this and I want to make sure I’m not missing something” lands very differently than stating an objection as fact when you can’t fully defend it yet.
🧗♀️ Is this a hill worth climbing?
Not every sub-optimal decision needs to be challenged. If the stakes are low and the disagreement is just about style and has multiple sound options, let it go and keep your credibility for when it matters.
If you see a real scalability issue, a security gap, or something that will create months of tech debt, that’s different - staying quiet isn’t humility, it’s a disservice to the team.
My framework for how to raise your concern
How you frame it says a lot.
There’s a meaningful difference between these two sentences:
➡️ “I don’t think that’s going to work.”
➡️ “I want to make sure I’m understanding this correctly - if we go this route, what happens when we hit X edge case/scenario?”
The second phrase does the exact same work as the first, but it lowers everyone’s defenses.
If you’re wrong, they explain it and you learn something. If you’re right, the problem surfaces naturally through the question itself and doesn’t require you to “defeat” anyone in front of their peers. It gives the room a graceful out to say, “Ah, good catch.”
I asked a few tech leads for their go-to phrases, and they suggested adding these:
“I might be missing context here, but I’m worried about [specific scenario]. Has that come up?” - The hedge isn’t weakness; it’s precision. You’re flagging a specific concern instead of issuing a verdict.
“I’d love to understand the tradeoffs on this one a bit more.” - Useful when you can’t fully articulate your concern yet but feel something’s off.
“If we make this choice, can X be a problem?” - Useful when you think the decision adversely affects something specific.
“Can I ask a clarifying question before we move on.” - This is low-stakes to say and signals you’re actively listening, and not adversarial.
📝 HQ Tip: What you want to avoid is framing the disagreement as “I think you’re wrong.” Even if that’s true, it puts the other person in a defensive posture.
Think about it this way - your goal should never be to win an argument but to make sure the right information is in the room.
What to do if they brush past you
Sometimes you raise the concern and it gets acknowledged briefly and moved past.
This is frustrating but don’t treat this as the end of the road. There’s a couple ways I’ve seen people deal with this.
1️⃣ Write it down and send a follow up
After the meeting, send a short message to your manager or tech lead - not a long manifesto, just a note. Something like: “Hey, I raised a question in today’s meeting about X and I want to make sure it got captured. Here’s what I was thinking...” This creates a record without being confrontational, and it shows you’re thorough.
2️⃣ Ask for a one-on-one conversation
Team meetings are bad venues for changing minds on anything complicated. If you feel strongly, ask the relevant person if they have fifteen minutes to walk through your concern more carefully. Most of your engineering peers will likely respond well to this. It signals that you care about the outcome, not about being seen as right.
3️⃣ Know when to let it go and learn
If you’ve raised your point clearly, documented it, and the decision stands - let it stand. Ship the thing, observe what happens, and update your model of the world accordingly. Sometimes you’ll be right and it’ll bite the team later; sometimes you’ll realize you were missing something important. Both outcomes are data.
When I worked at Amazon, I lived and breathed one of their famous (and quite honestly one of the most useful) principles - “Disagree and Commit”. It means that you should openly challenge decisions during the planning phase but once a decision is made, the debate ends. You don’t drag your feet or wait around for it to fail. You execute on the chosen path as fiercely as if it were your own idea.
Building the credibility to be heard
There’s a longer game here.
The reason early-career folks get brushed past isn’t always that their ideas are bad - it’s often that they haven’t yet built the credibility that makes others stop and listen.
That credibility comes from a few things you can actively work on.
✅ Be right in smaller moments first
When you spot a bug in a code review, flag it clearly and correctly. Point out small misses or ask thoughtful questions about decisions in a design doc. These small wins build a track record that makes people take your concerns more seriously over time.
✅ Do your homework
If you disagree with an approach, come back with a concrete alternative or a specific data point - not just a feeling.
“I think we should look at option B because it would reduce our write latency in the P99 case we discussed last sprint” is much harder to dismiss than “I’m not sure about this” or “I have a feeling this is wrong”.
✅ Be genuinely curious
The engineers who get heard fastest tend to ask a lot of good questions before they issue a lot of strong opinions.
Curiosity builds relationships. Relationships build influence.
Don’t underestimate yourself
Being six months into a job and noticing something that a ten-year veteran missed is not as rare as you’d think.
Seniority ≠ always being right.
Speak up with a question, not a claim to win 🥇,
And you’ll be surprised how quickly the room starts waiting to hear what you think.
That’s it for today! Do you feel heard by senior folks on your team? Let me know in the comments!
If you found this post valuable:
I write short actionable posts on things I struggled with, which I have developed some mind maps for - how to navigate your tech job, network with people, and grow your net worth along the way, backed by my experience, tons of research and learnings from tech leaders.
I wish you a great week!
Until next time,
Sonika
Top comments (2)
The fact that you think you can lose your job for pushing back against proposals shows that it is not a good relationship.
As the less experienced developer you should be able to talk freely. When you say; I don’t think that’s going to work. The more experienced developer should say; why not.
It is true it is better to come with the facts first, but sometimes you don't remember it at that moment. That is why the experienced developer should give you time to think about them.
Even if you are wrong, it is a teaching moment for the experienced developer.
And if your right, the experienced developer should be glad the team work payed of.
This is the career content that actually matters but almost nobody writes about. Technical skills get you in the door, but knowing how to disagree respectfully and still be heard that's what separates people who grow fast from people who stay stuck. The framing of 'raising concerns without killing your career' is perfect. Most junior devs either stay silent forever or go too hard and damage relationships. There's clearly a middle path and I'm glad someone is finally writing about it!