
Ask HN: Remote workers, how do you show your work? - csytan
When I was working remotely as a dev, I found one of the hardest problems was communicating what I was working on with my team.<p>My parents always taught me to be modest when speaking about myself, and to let my results speak for itself. However, I found that in a team environment, proactive communication works much better.<p>How do you share your day to day with your team? What tools, methods, or habits do you use to solve this problem?
======
fatihacet
I am working remotely for the last 5 years and currently working at GitLab
which is a remote only company. Here are my humble advices for you.

\- Always check in with your manager. Let them know your status before they
ask.

\- Make sure to deliver your stuff on time. If you can't do it, let your
manager and other related team members before it's too late. Explain the
reasons why you failed and learn your lessons. Try to avoid the same situation
happen to you again. If it's your fault, accept it and move on. Try to do
better next time.

\- Share big and important updates with your team. It can be something simple
like "Hey everybody, I did this and here you can take a look". If you use
Slack you can post this to a public channel or you can send it via email.

\- Add screen recordings to your Merge Requests. You can use Gif tools like,
LICEcap or recordit.co.

\- Be responsive to your mails, issues, TODOs, Merge Request comments etc.

\- Always make sure that you have assigned with something to work on and you
know what to do next.

\- Try to be available when someone needs your help.

\- Last one, maybe the most important one is doing a weekly meeting. If you
don't have a weekly team meeting, you should tell your manager to start doing
one. It's the most easiest and productive way to share important updates and
sync up with other team members. At GitLab, we have a shared Google Doc and
everyone can add their items to that list. Then people talk about their items
then pass it to next person. You can also do daily stand-up meetings. It
should be something quick and every team member should have 1-2 minute to talk
about their updates and answer the questions below. You can also do this in
async way by posting answers of these questions to a Slack channel.

I. What did you work on yesterday?

II. What will you work on today?

III. Is there any obstacles?

~~~
throwaway2016a
I wish some of my remote team would read this message. Though I'm not sold on
this one:

\- Add screen recordings to your Merge Requests. You can use Gif tools like,
LICEcap or recordit.co.

Also, that last meeting you talk about is usually called a stand-up meeting
and when using Scrum project management it is supposed to be every day. I
don't think I've ever heard of it being done once a week. Not that it is abad
thing, I'm curious if some other companies are only doing it once a week.

~~~
zzzcpan
> I wish some of my remote team would read this message.

To be fair most workers are never going to do on their own what the business
wants or what is good for the team. They don't understand it well enough as
they are neither business people nor managers and it's not up to them.

~~~
throwaway2016a
I know it's four days later but this might be one of the most condescending
arrogant things that I have every read on Hacker News.

Really? Business is so magical that someone with a Computer Science degree
couldn't possibly understand business.

As a manager or CEO it is your job to make sure everyone in the company
understands the mission and what is needed to get there. And that everyone is
empowered to act on a daily basis to move that mission forward.

A leader realizes that the people on their team have insights and knowledge
that they do not. A good leader empowers not dictates. You sir, have some
lessons to learn.

There is a reason so many great companies are founded by software engineers.
Based on your logic those should all fail because Software Engineers should
just stick to coding not thinking about what is best for the business.

------
i_dont_know_
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 :)

~~~
trynewideas
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.

------
qxf2
I have this problem too - both as an employee and as a remote-only employer. I
work as QA - not as a developer, though. I also work in a different timezone.
I have found people start paying attention and valuing you once they start
seeing you as a normal human who happens to work elsewhere and not as a
"remote entity". I have tried these adjustments and I think they help:

a) make an effort to share things other than work - interesting articles you
read, participate/respond in watercooler chats, post side-projects you may be
working on, your favorite hobbies, post when you are stepping out and are back
again, etc. This is counter-intuitive and not a direct solution, but you end
up seeming like a human rather than some remote contractor. Once that happens,
people start taking more interest in your work automatically.

b) get to know your colleagues, start meetings with a little bit of small
talk, explicitly ask for feedback and don't hesitate to speak up if your team
takes a decision that is not very remote-friendly (I've messed up plenty
here!). Many teams will go out of the way to integrate you if you tell them
how.

c) try writing summaries at the end of each day, week ... even if nobody is
paying attention initially. Daily summaries are private and for standup while
I record weekly updates on some internal wiki. I like cartoons, so I typically
include some cartoons in my weekly summaries.

d) attend standup and come prepared. Your updates should be much longer and
much more detailed than someone who is not remote. Days you miss standup, you
should try posting your update on Slack.

e) turn on your camera for all meetings. It's another one of those habits that
make remote workers much more 'real' and relatable.

f) make sure you have good audio/video and Internet connection.

------
eloisant
Just the same way I would if I wasn't remote. When working in an office, it's
not like people come looking at my screen behind my shoulder anyway (I would
hate it).

Basically my activity is visible on the source tracker through the PR is
submit and review, the bug tracker, Slack discussions, and we have a daily
team meeting where everyone shared what he/she's doing.

We also have a Geekbot on slack so everyone can share what he's done in the
day and what he's planning to do the next day.

~~~
amingilani
This, plus in preparation for a worst case scenario, I use Toptracker which
records screenshots and logs hours

[1]: [http://tracker.toptal.com](http://tracker.toptal.com)

------
peterkelly
Our team has a daily standup call where we discuss what we've been up to
(we're remote but in compatible timezones); where appropriate this will
include screen sharing to demo a feature we're working on.

We have automated slack notifications for GitHub commits, and the team leader
and all other developers have full access to the git logs to see what each of
us has done. We also use Trello to keep track of tasks.

------
kyranjamie
As a frontend dev, GIFs of the piece of functionality you've implemented in a
PR are a godsend. A good practice to get into even if you're not remote.

~~~
fbnlsr
What do you use to generate them?

~~~
modernerd
I do the same and use LICEcap:
[https://www.cockos.com/licecap/](https://www.cockos.com/licecap/)

Some teammates use [https://github.com/phw/peek](https://github.com/phw/peek).

~~~
chiefalchemist
Why this over a browser extension?

~~~
chiefalchemist
How does a simple and valid question get a down vote?

------
ollysb
Everywhere I've worked has had a weekly/bi-weekly showcase where the
developers show any work that they'd completed since the last one. If this
wasn't in place I think it would be hard for even onsite developers to keep
everyone up to speed with what they're doing.

------
mariojv
A few ways:

\- Asynchronous standups with Geekbot in Slack
([https://geekbot.io/](https://geekbot.io/)). Any shared doc will do here,
really.

\- Occasional demos over video chat of new functionality to internal teams. It
helps that my entire team attends.

\- Our API has a chatbot that we can use to query it, so I can show new
features for that part of the infrastructure directly in our team channel.

\- Ask people for code reviews, and rotate who you ask.

\- Ask people to pair program with you over a screen share, or offer to pair
with them.

It helps if your team is 100% remote. If it isn't, maybe talk with your team
about trying to get people to be more disciplined about making decisions via
chat or team meetings rather than only with the people in the office. One
thing a few coworkers and I did when we were 3 out of 8 who worked in the
office was catch everybody up on IRC whenever we had a side discussion. It's
unrealistic to expect _everything_ to happen over chat mediums with that kind
of team, but something like that can help.

(edited to fix formatting)

------
anon1094
After working remotely for years I found a system that worked for me. I would
email, or send a slack message, to my direct manager every single day. It
really helps especially when you're working asynchronously and you're not
online at the same time.

Here's the template:

Hey {{ manager.name}}, here’s my status update for today.

1\. I got the free email, created, scheduled, and ready to be sent. 2\. I
fixed the job creator bugs related to the timezone issues 3\. I added a few
dynamic rules to the email creator to make things easier in the future.

 _Here’s the document where I document those dynamic rules_ : {{ link }}

Tomorrow, I'm going to implement the automatic country-tagging based on the
user's timezone.

\---

A simple daily summary like that really helped increase my communication with
my manager and help keep us on the same page. I even ended up creating a
#status-update channel on the Slack we use.

------
oedmarap
In our team we use Wrike for project management. Each team member customizes
their workflow and makes their project/task list public for the most part;
completion is seen at a glance and project leads are added as default
collaborators. Project leads can also tag tasks from users into separate
folders for critical items, and do assignments and update due dates if needed.

The gantt charts and reports allow each member to ensure they can validate
their work progress, and the project manager/leads being able to visualize it
as well at any time.

Myself and two others also use Jira/Jira Core separately for operations and
software issue tracking.

Wrike and Jira both integrate with Microsoft Teams as functional, browsable
tabs and serves to provide connected dashboards in real-time.

We have team members across four countries so weekly meetings involve screen
sharing, annotation, and task creation/assignment in Wrike done on the fly as
well.

Regardless of your software choices, my tip is to ensure you have a way of
reporting/visualizing progress and being able to integrate the project
management tool with your communication tool of choice.

------
dalemyers
I started working remotely a couple of years ago and I found this immensely
challenging. I always felt like I was behind the rest of the team since they
could all see what each other was doing, but I felt like I was in my own
little bubble. It didn't help that I was working on a totally separate part of
our app that no one else was really involved with. As time went on, my manager
made it pretty clear that he was happy with my progress and I realised that
this was the only real important thing.

Since then, I've moved onto a totally different area of work, and if I'm doing
my job right, my work should be almost imperceptible to the rest of the team.
Occasionally I have to ask the team to adapt to a new process, etc. which
isn't helpful since they only really see the negative aspects of my role, but
again, my manager is happy, so I'm happy.

You asked about tools, etc. and I'll cover that, but I wanted to share that I
don't think it's of vital importance that everyone knows what _you_ are
working on. It's understandable to want to know what everyone else is working
on, and if that's the case, bring it up with your manager. Let them know that
you'd like to know more about the rest of the team and work out a solution
with them. However, it will never be perfect.

So, in terms of tooling for us, we use Slack for day to day communication
(somewhat ironic considering we work on an email client), and we have a few
different channels for our work. The two most important one are our general
one for the app where we can ask questions, share advice, etc. The other is
our "syncup" channel where we post update of what we are working on, what we
worked on, etc. It's basically a standup channel. The hardest part is
remembering to update it regularly. In addition, we have a full team meeting
once a week via video call.

So, basically, use Slack/Hip Chat/email/whatever for regular updates with
everyone, and for the bigger picture stuff, you only need to convince your
manager that you are getting everything done.

------
topkai22
I am team lead for a 100% remote consulting team. My observations mostly match
what’s already been posted, but let me reiterate what I see from a level 1
manager perspective.

If using agile, create work items/PBIs for everything and document decisions
in your tool (or, less optimally, in slack/teams/other persistent group chat
tool). I obsessively look in these tools to understand what my team is doing/
has done.

Go through work items/PBIs as a team frequently (we nominally do daily, it’s
more like every other day) to update remaining work. If I as the L1 manager
see your work melting away I’m happy and you have great evidence of
productivity.

Communicate what is happening in the rest of your life. If I know my team
member has family visiting or a sick kid I can mentally process that better
than a simple “my productivity will be down for a few days”. Even worse is not
communicating at all- I have seen team members disappear for days and screw up
our sprint commitments. I understand there are cultural issues here at times,
but team members who don’t communicate are a problem: the customer and L2+
bosses want to know reasons why things slip and this information often gets
communicated up the chain. Why work isn’t happening is also important.

Don’t miss commitments and communicate risks or issues that might cause a miss
early and loudly. And do so in writing (preferably in the chat channel). I
have had people burn down a PBI for a whole sprint only to discover it half
done, now we have a trust issue and I’m not sure I can trust the information I
do have about productivity.

Note- I don’t really track my teams PRs or code commits, I track completion of
user stories/tasks. One of my team members talked the customer into using an
off the shelf service to implement a feature last week. No code commit, but I
know her productivity is very high because she knocked off her features like
crazy.

Demo both code and features to team. This is great for knowledge transfer and
keeps the whole team aware of what is going on.

Hope that helps.

Ed- I work in a very “enterprisey” world, YMMV in more consumer or packaged
service oriented world

------
mvip
We're a 100% remote company. I wrote a blog post a while ago about how we work
here ([https://www.screenly.io/blog/2016/11/23/how-we-work-at-
scree...](https://www.screenly.io/blog/2016/11/23/how-we-work-at-screenly/)).
The tl;dr is basically hire smart (independent) people and let them do their
thing. We run a daily standup over chat are constantly experimenting and
tweaking the processes.

Tooling wise, we use Flowdock, Phabricator and Google hangouts for meetings.
PR are to have GIFs attached.

------
baristaGeek
We're a startup of >30 people, some of us work part time and we're distributed
in opposite time zones. We have no offices, everybody's work is 100% remote.
This is what we do:

-An asynchronous daily scrum session in Rocket Chat (awesome free, self-hosted tool).

-A channel in Rocket Chat dedicated to alert about commits. Commits are actually the most important criteria for measuring an engineer's output.

-GitLab board. (Previously Trello board).

-If everyone speaks in a public channel (even if only speaking directly to a single person), one's output can be judged if she is making and answering questions.

~~~
nullpunkt
terrible

------
digitalsushi
I (try) to make conversations with people about non-work, over chat, to see if
they want to make a connection with me. Those that do, always end up being
stronger work related connections.

However, the majority of people do not want to reach back, and to those people
I don't press the issue with repeated attempts. I think that a lot of people
are put off by small talk, or are just too busy for it; I hope with them that
not having a memory of me as being annoying is the best relationship I can
have.

Sometimes they will just say "Sorry I'm just really busy" \- this is great
information too just as a barometer. It's less often, but a poke with a joke
can get you onto some side work that improves your reputation if you're able
to genuinely assist someone having a bad month.

I have the option to work remotely but I take the 40 minute commute in,
because I get a lot better mileage off people by reading their body language,
faces, where they are looking, holding their arms, how far they stand from me,
et cetera. It's like running a program with the -debug flag, for me, and
remotely I have no access to it.

And I hate to say it, but I feel that you hope one level up the stack just by
being present. It's almost a digital caste system. Some useless kid texting
his friends in the conference room has equal clout as the seasoned principal
dialed in on the phone.

Also - since we're in this thread - is it just me, or does a time delay on a
conference call make the speaker seem less intelligent? I get embarrassed when
I learn I am on a 1.5 second audio delay. I will often dial in over PSTN to
get that second back.

I agree with OP about letting results be the message, but it is a frustrating
way to communicate technical ability because there is no short term payoff.
Team members that give impressive, meaningless, daily updates fall flat at the
end of a development sprint during a demonstration. Make that the time for
your results to speak for you to the people you want to impress, because that
is the only time during the sprint that they are probably paying attention to
you.

To try and round out my claims above, I've also been the person being annoyed
by a chatty remote coworker. Being gracious to them in times of duress is the
same game triggered by callback.

------
marmaduke
When I was working remote my commits would show up on the issue tracker, which
is great. Deployments to staging or prod would notify a log channel on Slack
which is another good one.

I don’t see how one can do better than that, since anyone can lie/rationalize
under pressure of a Skype session; it’s better to see concrete progress, but
this requires trust in both directions.

------
jgalvez
I was a terrible developer for many years because of my inability to properly
communicate progress. Because there wasn't any for the most part. Parkinson's
Law is REAL. Beware! I ended it by religiously adhering to a rule to commit
every little bit of progress, as I go. There's only one deadline: today. It
completely changed my career.

~~~
jgalvez
Keep your commit stream going. If you're starting something from scratch, do a
commit with a message like "Something (1)" and then increment the index and
commit every iteration. You can merge these commits down the road for a
cleaner history, but pushing soon and often is KEY to building momentum.

------
Tade0
I'm "lucky" to be bound by our process which is: we estimate the workload of
each task beforehand.

As long as I don't go over the estimates too much everything is okay.

Of course these are never accurate, but with the right granulation(max. 2d per
task or subtask) they help with communicating what is it that you do.

------
stinos
Jira/Hipchat depending on relevance, pointing to gitlab instance for code and
to the build server's drop box for end results. Simple yet effective though I
reckon it might not work for all types of software, let alone non-software
projects.

------
sidcool
Any task tracking apps like Trello, Jira or Mingle. And relates GitLab commits
with hooks.

------
INTPenis
In my case project managers and service managers. It's their job to ensure
that something gets done according to their or the clients specification.

It's my job to work out how it gets done and to abstract the necessary
information for the SM/PMs.

------
viach
It depends on the project's phase/team specialization. If it's new features
then daily or weekly meetings, if support and bugfixing - you usually create
many chats, specific to a particular issue.

------
clueless123
Exactly as I would do if I was on the office: Jira (or whatever task manager
you use), GroupChat, Git PR's and so on.. And if you are doing some sort of
Agile, a 15 minute morning stand-up call.

------
emerged
I've had to actively downplay my work because my productivity is too high
without all the meetings and other distractions. Coworkers get jealous and
begin causing problems otherwise.

~~~
oscii
Sounds weird. Can you elaborate, please? What kind of problems did the
coworkers caused, how exactly did you downplay your work, etc.?

------
ruairidhwm
Usually just an update on each scrum meeting and hitting my deadlines. Either
the work has been done or it hasn't.

------
k__
Since I work on front-end stuff, I always have something to show.

