Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Remote workers, how do you show your work?
105 points by csytan on Jan 21, 2018 | hide | past | favorite | 45 comments
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.

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.

How do you share your day to day with your team? What tools, methods, or habits do you use to solve this problem?




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?


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.


Security firm here, we do weekly meetings solely because our tempo is different. An individual researcher, analyst or pentester might have his own engagement to take care of that is relatively independent.

For us, weekly meetings are more of a phoning home than a game plan meeting. I can see situations in which stand up meeting might be useful, -> when there is mutual overlap between engagements.

In answering your question though, the need for stand up meetings, imo, is dictated by the size of the group working on the same project.


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


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.


Yep I don't feel comfortable with that one too - I much prefer the idea of virtually attending scrums (just make sure they are brief!)


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.


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.


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.


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

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


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.


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.


What do you use to generate them?


I'd like to recommend https://getsharex.com/. To take gifs with shareX you need to update the video capture settings. This is a gif I recorded with shareX with the steps to update the video settings: https://i.imgur.com/LOlP4ts.gifv


I do the same and use LICEcap: https://www.cockos.com/licecap/

Some teammates use https://github.com/phw/peek.


Why this over a browser extension?


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


The two I'd recommend are: 1. https://giphy.com/apps/giphycapture 2. https://getkap.co/


At a bare minimum include before/after screenshots (CMD + SHIFT + 4 in MacOS) in PRs.

For GIFs/videos, my company has a CloudApp account which makes it super easy to record screen captures.


This makes sense as a product / application best practice. I would it would be helpful (especially for new team members) to see the evolution of the UX visually, not simply as text commit messages.


This is an excellent idea I'm going to start telling people about.


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.


A few ways:

- Asynchronous standups with Geekbot in Slack (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)


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.


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.


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.


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


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...). 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.


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.


terrible


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.


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.


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.


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.


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.


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.


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


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.


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.


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.


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.


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


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


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: