For the first three years of my career, I was invisible in meetings.
I'd sit there, listen, nod, and leave. Sometimes I had an idea but didn't say it — I figured someone more experienced would say it better. Sometimes I had a question but stayed quiet because I assumed I was the only one who didn't understand.
I was wrong on both counts. And I was accidentally killing my own career progression without realizing it.
Meetings are where careers happen
This sounds dramatic. It's not.
Your manager's perception of your ability is built primarily in two places: the code you produce (which they might not read closely) and how you show up in meetings (which they see directly, every time).
A developer who writes great code but says nothing in meetings is, from a manager's perspective, hard to evaluate. They might be brilliant. They might be struggling silently. The manager doesn't know, because they have no signal.
A developer who writes decent code but communicates clearly in meetings — asks good questions, flags risks early, gives updates without being asked — that person looks competent. Not because they're performing. Because they're giving their manager the information needed to trust them with bigger things.
This isn't politics. It's communication. And nobody teaches it in a bootcamp.
The three things to do in every meeting
I'm not talking about becoming a "meeting person." I'm not saying you should talk more for the sake of talking. There are three small things that, done consistently, change how people perceive your ability.
Ask one question. Any question. "What's the timeline for this?" or "Who's handling the API side?" or "Are we blocked on anything?" It doesn't have to be brilliant. It just has to show you're engaged and thinking. One question per meeting. That's it.
Flag one risk. If you see something that might go wrong, say it. "I think this might take longer than estimated because the API documentation is incomplete." Flagging risks early is one of the most valued behaviors in any engineering team. It shows judgment, not just execution.
Give one update without being asked. "Quick update on the login flow — I'm about 70% done, should have a PR up by Thursday." Proactive updates reduce your manager's anxiety. And a manager who isn't anxious about your work gives you more autonomy.
Three things. That's the whole framework.
Why developers resist this
I know the objection because I had it myself: "I want my code to speak for itself."
It doesn't. Code speaks to other developers who read it. Your manager might read it occasionally. Your manager's manager never will. Promotion decisions, project assignments, opportunities — they all happen in rooms where nobody is looking at your git history.
The developers who get promoted fastest are rarely the best coders. They're the ones whose value is visible.
How to start today
Add a brief note to your team Slack or Discord when you ship something meaningful. Keep a running list of wins — a simple notes file works fine. In your next one-on-one, share one thing you shipped and why it mattered.
Technical skills get you in the door. Communication skills move you through the building.
This is part of devkoan — one tool, one lesson, one step forward every week.