Notes from Zoom call on “Problems & Solutions for Data Science Remote Work”

On Friday I held an open Zoom call to discuss the problems and solutions posed by remote work for data scientists. I put this together as I’ve observed from my teaching cohorts and from conversation with colleagues that for anyone “suddenly working remotely” the process has typically not been smooth. I invited folk to join and asked that they shared 1 pain and 1 tip via a GForm, some tips were also submitted via Twitter. We held a live video chat and I took notes, I’ve summarised these below.

Given that we’re likely to stay in this remote mode for a minimum of 3 months, possibly 6 months and to a greater & lesser extent over 1-2 years it’ll pay for your team to invest in building a good remote process.

This post by Chris Parsons at Gower covers a CTO’s view of collaboration in a tech org (including data scientists), I like the notion of relinquishing control and discouraging continual availability.

I was joined by Jon Markwell (@jot), founder of The Skiff co-working environment down in Brighton (he’s built a brilliant community of freelancers there who often work remotely). He helps companies with their remote transformations. He’s been working on a new tool for remote readiness prior to Coronavirus and I invited him to share his tech-focused remote practices on the call. He’s open to you reaching out via Twitter or LinkedIn if you’d like his advice.

We spoke at a high level on:

  • Well-being
  • Avoiding distactions and isolation
  • Team discussions
  • Whiteboarding, tools, knowledge sharing

Well-being came up frequently in my “share 1 problem and 1 tip”. Tips included:

  • Getting a manager to set the tone that “it is ok to work at a slower pace, take it easy, adapting takes time” is important to help folk reduce stress. Saying “I’m in” and “I’m out” in slack can indicate clear working hours for the team to help everyone know when folk are around or not, this helps when there are core-hours that everyone should maintain in distributed teams
  • Building up a back-log of tasks for lower priority but important work like back-filling tests, refactoring and reviewing untouched code is a good way to provide important but low-stress tasks that a colleague can take on when they’re feeling less productive such that a positive outcome is still achieved
  • Make a routine and stick to it. Maybe go for a walk first-thing prior to work to simulate a commute. Put on your “work clothes” rather than PJs.
  • Figuring out processes to keep morale up is a team-wide issue. Overwork should be watched for just like underworking. A “#wellbeing” slack channel at work might be a good place to share fun things, possibly with a “#covid19” channel kept separate to keep that news in 1 place (where it can also be avoided)
  • For teams that don’t know each other Federico suggested GeoGuessr as a simple game that all can play on Zoom to break the ice

Distractions and isolation was also a frequent issue:

  • Many of us on the call use the Pomodoro timed technique (working for 25 minutes via a timer then taking a short break), Sandrine suggested this physical timer and I use the countdown timer on my phone
  • To avoid websites Flipd was suggested for phone focus, Freedom (now banned by Apple apparently) and Bertil suggested SelfControl (Mac) to limit website interaction

Team communication was more tricky:

  • A frequently cited issued was the loss of ad-hoc in-person communication for discussion
  • Jon reminded everyone on the importance of over-communicating whilst the team adapted with a focus on transparency to avoid people feeling left out
  • Severin noted keeping core hours was helpful
  • I suggested that if team members and bosses were unsure about how a remote process might work to point them at large, decentralised and demonstrably-capable teams like those behind the open source scikit-learn, Pandas and Linux projects. The newsgroups, occasional calls and github-fueled process work very well
  • Calls need to be controlled – establish an agenda and a protocol for asking questions (perhaps using chat simultaneously)
  • Have an always-open video call where folk can just drop-in and natter might simulate some of the relaxed chat in an office


  • A kanban/scrum process will work fine in a remote scenario, Trello boards work well (if you don’t have a system yet – columns like “ideas”, “blocked”, “in process”, “done” where they move left->right is a sensible basic flow)
  • Tools noted include Miro (collaborative whiteboard), TandemChat (team chat), Slack or Microsoft Teams, Google suite during a video call
  • Jon gave us a demo of Retrium for remote retrospectives, this looks fairly powerful and has a free 30 day trial
  • Jon also showed us the output of his Remote Readiness tool which can help a team score where they’re good & bad for the move to remote – this will certainly help managers spot areas of weakness that they can avoid, given Jon’s prior experience (also – contact Jon if you’d like his advice!)

Home office setup (we didn’t get to discuss this):

  • A physical cable to the router is likely to be more stable than wifi if you’re a distance from your router (I use 15m of cat-5e cable)
  • I also have a Netgear EX6120 range extender but neighbours now have similar so I prefer to depend on the physical cable
  • I use a Logitech C920 HD camera (the C920S seems to be the newer version) which has auto-focus and “just works” with my Linux, it sits on top of my external monitor
  • I’ve also got a comfy wired headset with microphone (wired as having a battery fail during a call is less helpful)
  • Some people use a greenscreen as they hate having their home on display (this is discussed in his hackernews thread)

Thoughts on the format of the Zoom call:

  • This is the first time I’ve done a discussion like this, getting feedback from a group who don’t know each other was hard
  • Prior to the call I created an agenda, agreed with my co-presenter, based on the GForm feedback
  • At the start of the call everyone introduced themselves in the Zoom chat window (name, company, city) and I explained everyone should stay on mute unless they had a point to raise
  • The fact that I knew 50% of the participants is great, it would have been much more wooden I feel if the number had been smaller
  • Getting folk to contribute ideas was hard, maybe asking folk to physically raise a hand is a good indicator (for those with video on – about 1/3 of the attendees), maybe using Zoom’s “raise hand” is useful, or maybe reminding frequently that folk can share questions into the Zoom chat would help
  • Once you close the meeting your Chat history seems to be deleted – this is awful, I lost some of the notes I hadn’t copied over and I couldn’t see a way to retrieve them
  • Having Jon Markwell along was great, having a “guest co-presenter” is important and he’s got a ton of useful experience

Ian is a Chief Interim Data Scientist via his Mor Consulting. Sign-up for Data Science tutorials in London and to hear about his data science thoughts and jobs. He lives in London, is walked by his high energy Springer Spaniel and is a consumer of fine coffees.