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!