You do great work. Your code ships, your tickets close, your reviews are thorough. And yet your colleague who sits next to the manager in the office just got the promotion you were expecting.
This is not a fairness problem with a solution of “work harder.” It is a visibility problem with a very specific solution.
Why Remote Workers Get Overlooked
When a manager thinks about who to promote, they run through mental models built from interactions. In-office employees get dozens of micro-interactions per day - hallway conversations, overheard problem-solving, lunch table discussions. These interactions unconsciously build a picture of competence, leadership, and ambition.
Remote developers get their weekly 1:1 and their Slack messages. That is it. The surface area for impression-making is tiny.
This is not managers being biased (well, sometimes it is, but that is a different problem). It is a structural gap in how remote work communicates value.
The Four Ways Remote Developers Become Invisible
1. Doing work without narrating it. You solved a gnarly production bug at 11pm. Did your team know? Did your manager know? Or did you just close the ticket?
2. Being available but not present. Being always online but never initiating - never proposing solutions, never raising concerns in public forums, never volunteering for cross-team work.
3. Only communicating when asked. Waiting for your manager to pull updates out of you instead of proactively surfacing them.
4. Treating 1:1s as status updates. Your manager should hear your thinking, your opinions, and your ambitions - not just what you shipped this week.
The Fix: Strategic Visibility
None of this means being fake or becoming an obnoxious self-promoter. It means giving people accurate information about the value you create.
Narrate your work in public channels
Before a significant task: “Starting work on the payment service refactor this week. Goal is to reduce average latency from 400ms to under 100ms.”
After completing it: “Shipped the payment service refactor. Reduced latency by 73%, here is the before/after graph. One interesting thing I learned: [brief technical insight].”
This is not bragging. This is helping your team understand what is happening. A side effect is that your manager sees it, remembers it come promotion time.
Raise issues before they become problems
Remote engineers who flag potential problems early - in writing, in public channels - build a reputation for thinking ahead. In-office engineers do this in hallway conversations. You need to do it in Slack/Teams.
“Noticed our database connection pool config might become a bottleneck when we hit the Black Friday traffic spike. Want to dig into this more - worth a quick discussion?”
That message takes 30 seconds to write. The reputation it builds is outsized.
Use your 1:1 better
Bring your manager something every week that shows you are thinking beyond your tickets:
- A pattern you noticed in the codebase that could cause future problems
- A process inefficiency you have been thinking about
- Your opinion on a technical direction the team should take
- Where you want to grow and what you are doing about it
Managers advocate loudest for people they understand. Make yourself easy to understand and advocate for.
Ask for scope, not just tasks
The difference between an IC who gets promoted and one who does not is usually scope. Promoted engineers own problems, not just tasks.
Instead of waiting to be assigned work, proactively own areas: “I want to own our observability stack. I will audit what we have, identify gaps, and propose improvements.” Then do it.
Ownership is visible in a way that task completion never is.
Building Relationships Across Teams
Promotions are not just about your immediate manager’s opinion. They are influenced by skip-level managers, peer engineers on other teams, and stakeholders who interact with your work.
Remote engineers tend to have narrow networks - just their immediate team. To grow, you need cross-functional visibility.
Tactics:
- Volunteer to be the on-call contact for your team’s systems
- Help people in other teams when they post questions in shared channels
- Join optional architecture discussions, even as a listener
- Comment thoughtfully on PRs outside your immediate codebase
Each of these builds your reputation one small brick at a time.
A Weekly Visibility Routine
| Day | Action | Time |
|---|---|---|
| Monday | Post your week’s goals and key focus in your team channel | 5 min |
| Wednesday | Share a mid-week update: what shipped, any blockers, what is next | 5 min |
| Friday | Post a brief “week in review” with your biggest shipping or learning | 10 min |
| Weekly | Come to 1:1 with one non-status topic: an opinion, a concern, a goal | 15 min prep |
This is 30-35 minutes of your week. It is not a lot. The impact is disproportionate.
Bottom Line
Remote developers do not get overlooked because they do bad work. They get overlooked because their good work is invisible. Narrate your work publicly, raise problems proactively, use your 1:1 for real conversations, and build relationships across teams. Make it easy for your manager to build a case for you - because if they have to figure it out themselves, they probably will not.
Comments