It always helped me to be proactive, which meant basically something like a quick status report to everyone on the team (not just superiors) every few weeks, whether they asked for it or not.
It's always short, maybe around 3-5 bullet points, with a link to something showing the end result of the task. (Github is good enough for a technical audience, but you probably want to link to the actual end-result for nontechnical audiences)
The big thing though, is the attitude you have towards yourself and your teammates when presenting this stuff.
You shouldn't be presenting it as proof that you're working and not sitting at the beach or something. You also shouldn't present it as some sort of validation, like "Bob got praise from the CEO, I did good stuff too, I want praise!". Instead, you should approach it as "I've been working on this thing that's related to what you've been doing. I kind of feel like you might not know about it, or not know the extent that it impacts your work. Here's some info. If it's old info, I've wasted the minimum amount of your time I can. If it's new, I've just made your job that much easier".
And just send them out when you feel that disconnect. More often than not, your instinct is right and the other team members really could use that info.
To date, I've only ever received positive feedback on these sporadic unscheduled status reports :)
We do this as a weekly team practice, remote or not (our team is mixed). It's quite good, especially if tasks get captured in JIRA or GitHub or some other linkable manner if people want to dig deeper.
It's particularly valuable when meetings that happen entirely in one office get the result shared out to remote folks who might not have even known it happened. The biggest complaint we have from remote workers is FOMO, and often just a one-liner about a meeting's result puts a lot of that to rest.
Comments
It always helped me to be proactive, which meant basically something like a quick status report to everyone on the team (not just superiors) every few weeks, whether they asked for it or not.
It's always short, maybe around 3-5 bullet points, with a link to something showing the end result of the task. (Github is good enough for a technical audience, but you probably want to link to the actual end-result for nontechnical audiences)
The big thing though, is the attitude you have towards yourself and your teammates when presenting this stuff.
You shouldn't be presenting it as proof that you're working and not sitting at the beach or something. You also shouldn't present it as some sort of validation, like "Bob got praise from the CEO, I did good stuff too, I want praise!". Instead, you should approach it as "I've been working on this thing that's related to what you've been doing. I kind of feel like you might not know about it, or not know the extent that it impacts your work. Here's some info. If it's old info, I've wasted the minimum amount of your time I can. If it's new, I've just made your job that much easier".
And just send them out when you feel that disconnect. More often than not, your instinct is right and the other team members really could use that info.
To date, I've only ever received positive feedback on these sporadic unscheduled status reports :)
We do this as a weekly team practice, remote or not (our team is mixed). It's quite good, especially if tasks get captured in JIRA or GitHub or some other linkable manner if people want to dig deeper.
It's particularly valuable when meetings that happen entirely in one office get the result shared out to remote folks who might not have even known it happened. The biggest complaint we have from remote workers is FOMO, and often just a one-liner about a meeting's result puts a lot of that to rest.