You fixed the bug that had support answering the same ticket for three weeks straight. You did it alone, without asking for help, and the fix got merged on a Thursday at eleven at night. On Friday, at standup, nobody mentioned it. Two weeks later your manager asks you in a 1:1 if you're "engaged" with the project, because they barely see you in the team's conversations.
This happens to senior remote devs all the time, and the better you are at your job, the more it happens. With six, eight, ten years of experience, you solve things fast and without noise. The problem is that on a distributed team, no noise means invisible. Nobody sees you think, nobody sees you iterate, nobody sees you discard three solutions before landing on the right one. All they see is a PR that showed up and got merged.
Here's my take: visibility in remote work isn't about personality, or about "turning on your camera." It's an information problem. The team makes better decisions when it knows what you're thinking, what you evaluated, and why you chose what you chose. If that information stays in your head, the team loses something real, not just you.
Why generic advice doesn't cut it at this stage
The typical advice (turn on your camera, join meetings, say hi in the company channel) is built for someone who just joined and needs to show they're learning fast. You don't need to prove that anymore. The inverse problem is that as you need less and less help, you communicate less and less, and communicating less in remote work reads as being less present, even when you're performing at your peak.
The solution isn't to talk more for the sake of it. It's making the thinking work visible, which for a senior is half the real value you bring.
Document the decisions, not just the code
A PR that says "refactor: new internal protocol" tells you nothing. A PR that says what problem it solved, what alternatives you considered, and why the winning one won, does.
Concrete example: if you migrated an internal service from REST to gRPC, the diff isn't enough. Write a short document (a one-page ADR works) that captures the real problem (network latency between microservices that was hurting an SLA), the alternatives you considered (keeping REST with HTTP streaming, using GraphQL subscriptions, moving to gRPC), and the trade-off you accepted in exchange (the team's learning curve, less mature tooling in some languages). That document is worth more for your career than the code itself, because it's evidence that you think in systems, not just tickets.
At Howdy, a lot of teams use the PR description as if it were the ADR: context, alternatives, decision, accepted risk. It's free, it doesn't require a new tool, and it stays searchable forever.
Become the person people consult, not just the one who delivers
There's a big difference between solving problems in private and solving them where the team can see it. If someone DMs you a technical question and the answer would help more than one person, answer in the team's public channel, not in the DM. It's not a personal marketing trick, it's keeping three other people from wasting the same time next week.
The same goes for when you solve something weird and non-trivial: a concurrency bug, a race condition in a cron job, an edge case in a payments integration. Write two paragraphs in the internal wiki or the team channel explaining what happened and how you diagnosed it. That positions you as the person who understands the system deeply, which is exactly what separates a senior from someone who just writes good code.
Quantify your impact instead of listing tasks
Weekly reports like "worked on X, made progress on Y" are noise. Nobody reads them twice. A report that says "cut build time from 14 to 4 minutes by tuning the Docker cache, saving each dev on the team about 45 minutes a day" is information a manager can use, repeat upward, and remember at your next compensation review.
This isn't about inflating achievements. It's translating technical work into a language the rest of the organization, which doesn't read your code, can understand and value. If you don't do it, nobody else will do it for you.
The limit: not everything needs an announcement
Save proactive communication for the moments with the highest leverage: when you close something that was blocking others, when you catch an architecture problem before it reaches production, when you made a decision another team is going to inherit. The rest (routine day-to-day work) can go in your weekly report, no need to narrate it in real time.
None of this replaces real human contact: it's still worth showing up at the office once in a while if you have one nearby, because in-person connection still builds trust in a way no async tool can fully match. At Howdy we have eight offices across Latin America for exactly that, even though day-to-day work stays remote.
