A reflection of how we work and grow as a fully remote team

last updated 2020-02-05

The team on a Zoom meeting

There are plenty of lists of tools for remote teams, and some fantastic examples of documented processes (ex {^Gitlab}). I'm spending some time this weekend writing about how we work at Upstream Tech. The tools, yes, but also the fabric, connections and culture of our remote work.

A lot has changed since the write-up I did 2 years ago. We've gone from 3 employees to almost 20! With team growth like that, it's probably obvious that we had to adjust and refine our processes to enable collaboration, productivity, and well-being.

The content include excerpts from the documents we keep internally to track our processes and onboard new folks joining the team.

Why Remote?

A raised eyebrow is the most common response I get when I tell someone our team is “remote, yes entirely. There is no office. Spread across the whole country, 4 time zones.” The amplitude of the raised eyebrow is typically related to the industry that person inhabits. “How do you get anything done?” they usually ask.

Where we are located across NA This is where we are, as of 2020. With the majority in the Northeast.

But first, before we dive into the "what," allow me to outline the "why" of remote work. For us, the most important reasons are:

Not bad! It's worth touching on potential "why nots": There are surely more benefits, and some trade-offs as well. Below, I'll highlight the details on how we organize and collaborate to achieve these benefits while minimizing the negative impact of the downsides (and I'd be foolish to claim there were none).


Organization

The composition of our team is two-thirds engineering and data science (we call it Product), and one-third business development and marketing (we call this Growth & Partnerships / GP). The former, inhabiting the digital world by default, lends itself more to remote collaboration.

Although Product and GP roles respectively have different responsibilities, which result in different workflows, tools and processes, we try as much as possible to keep the majority of the tools and processes common across our organization. Why? Well, product development doesn't operate in a bubble. If anything, it is informed first and foremost by the conversations had with external parties: customers, collaborators, and partners. More often than not, we include folks from the product team on our calls with prospective and active relationships.

The second and more important reason is because we are one team! To lack cohesion in our day-to-day processes, especially as a remote team, will result in a lack of cohesion as a team. Dividing lines in process are akin to cracks in a team's foundation.

We organize ourselves into Product Teams, one for each active product effort. For example, as of February 2020, we have the following product teams:

  1. Lens
  2. HydroForecast
  3. AgTrends
The teams vary in size and composition, depending on needs at any given time. Some folks share time across teams. Alden (our CTO) and Emily (our Engineering Manager) coordinate product team members to the different product teams on a weekly basis.

Getting Together

Team retreat Abby is our resident tree expert; in no small part because she graduated from the Yale School of Forestry. She teaches us about trees and our plants, both when we are together and when we are remote.

The most obvious trade-off that's pointed to by team in-person is that "sometimes you just have to get in a room and hash stuff out." We agree! And it isn't mutually exclusive with working remotely most of the time.

Team retreat When we were a wee company, hiking in the Berkshires. February 2018.

Twice a year we gather as a team. Two folks lead the organization of the gathering: wrangling a date, picking a location, and soliciting topics for an agenda (although it is left partially unstructured so that we can hang out). Most of the time is spent cooking, outdoors, discussing goals, and brainstorming.

We select a location with the following criteria:

Team retreat A bit bigger, with three of our favorite interns, in Somerville! July 2018.

We typically convene for 3-4 weekdays, which has been enough time to have downtime while still being possible for folks who have obligations back at home to join. And to be sensitive to such things, we don't require that folks come to every gathering; only that they do when it works well with their personal life schedule.

Topics and activities in the past have included:

Team retreat Bigger still! This time in Alameda, CA. October 2018.

Team retreat Kevin's Mole is a primary fixture of our gatherings. This time in Pawling, NY. April 2019.

Team retreat The latest gathering. September 2019.

1-on-1s

Getting together in-person is an important facet of building cohesion, trust, and empathy within a team. But for the time where a team is remote, regular 1-on-1 meetings help create space to chat about non-tactical work stuff, or perhaps not work stuff at all. Some opt to do them over the phone while going on a walk, others do it over video. Recent topics for me have ranged from talking about getting solar panels, to a great book I read recently, to lamenting how easy it is to procrastinate when taking an online self-paced course. Sometimes folks want to talk about high level work strategy, but most of the time it's like catching up with a friend.

I choose to do them weekly with the folks I work closest with and less frequently across the team.

Cross-Org Tools

Before I start talking about our workflows and processes, it's worth briefly outlining our tools:

Google Drive and GSuite

We use Google Drive for all of our internal and external documents. Internally, that includes documents for planning, brainstorms, call notes, pricing spreadsheets, etc. Externally: proposals, conference presentations, report deliverables, and more. We invested time to translate our design system to a set of professional document templates for anything external. We have a folder structure on a Team Drive that helps keep things organized.

We use Google Meet (part of GSuite) to do meetings, both internal and external. If the groups gets larger than about 10 people, we use Zoom.

Slack

Love it or hate it, it's good for discussing tactical stuff (#upstream-[product]), sharing resources like articles (#upstream-articles), notifying the team to feature releases (#upstream-release-notes), and generally sharing life stuff (#upstream-watercooler).

#upstream-watercooler has been an awesome place to share stuff that doesn't fit elsewhere: book recommendations, questions about plants for our resident botany expert Abby, photos from a vacation, progress of knitting projects... you get the idea.

Slack has its issues, but with careful tuning of the notifications (Notifications → "Notify me about..." → "Direct messages, mentions & keywords") and culling of sidebar madness ( Sidebar → Appearance → "Unreads and starred conversations") is imperative. Setting "Do Not Disturb" during focused blocks during the workday has been a technique that has worked well for our team to do deep dive writing, proposal preparation, and coding.

We also urge folks to first consider posting messages in public rooms if they have the potential to benefit other folks on the teams. For that reason, we created #upstream-qs and #upstream-eng-qs for general and engineering questions respectively. It has helped create a culture unafraid to ask questions. In my early jobs, I felt nervous to ask a question that made me look inexperienced. I make a point to ask all of my questions in these rooms as well, so that everyone, from Alden to our interns, feel comfortable asking anything.

We have one room worth noting called #upstream-intentions. Every morning, folks post “intentions” for the day. As the day goes on, we edit our intentions to show that something is done.

Our #upstream-intentions room

It’s a very simple, low friction to-do list that drive self-accountability for the day, makes progress transparent, and helps call out cross-team dependencies first thing in the morning.

GitLab

As described on {^GitLab}:

GitLab is a web-based DevOps lifecycle tool that provides a Git-repository manager providing wiki, issue-tracking and CI/CD pipeline[7] features, using an open-source license, developed by GitLab Inc.

Woah, that's quite a bit of functionality. When remote teams say "ah yes, we use GitLab" the thing I wonder is "how do you use it?" What are the processes in place to keep things moving?

Our GitLab board

Below is a combination of terminology and processes we use around GitLab's issue tracking system, which we use as the primary location of our current, imminent, and near future tasks across teams:

A note about backlog issues: We use the {^1-3-6 document} as our way to track work that is longer term (six months in startup land is like 3 years in big company land). We try to keep GitLab issues very fresh, meaning issues that fall outside of the “this month” in the 1-3-6 document should likely {^not exist} in GitLab.

15Five

Being a remote team makes it all the more important to regularly take the pulse of the team. Frankly, anxiety, uncertainty, excitement, and high-fiving isn't as recognizable over a screen as they are in person. We use 15Five to do two things: weekly pulse checks and biannual 360 review cycles.

The pulse-checks happen every Friday. We ask that each teammate takes 15 minutes to answer 5 questions. It also provides an opportunity to call out other teammates for being awesome. The virtual answer to an in-person high-five.

Product Tools

Figma

A small cohort of us use Figma to produce design, although we often opt to go from paper sketches straight to code. Figma has been a useful resource too when conducting market research: we create mocks of future functionality to gather feedback and spark conversation.

Intercom

We use intercom to interact with the customers on our website. We don't yet do anything particularly sophisticated outside of some automated emails, some lightweight help documentation, and triaging of inbound questions via a chat widget.

Growth and Partnership Tools

Streak

{^Stream} is a lightweight CRM that lives inside of Gmail to track pipelines and processes related to sales activities. It's fantastic because it doesn't require cumbersome BCC-ing to share emails related to the CRM entities - emails can be shared by default, and are properly associated with the CRM entities automatically based on domain name or email address. We use a Task feature for follow-ups (since they'd otherwise clog up our Kanban board in GitLab). We make sure all of these tasks have a deadline, because we all know how easy it is to kick a "follow up" can down the road. # Everyone's Responsibilities

We have three responsibilities we ask everyone on the team to adhere to

  1. Keep customers happy and excited! By forming real relationships, building high quality products, by listening to customers, and by keeping our system stable.
  2. Keep your work visible; and keep tracking tools up-to-date.
  3. Self-organization and autonomy: if you don’t have something to work on, look for an open issue with your team’s label. If you’re not sure, ask the DRIs.

DRIs

Each team has two Directly Responsible Individuals, one for Product and one for G&P. The responsibility has overlaps in some regards, especially when it comes to translating customer feedback into product decisions. In other ways, we see a distinct separation in the responsibilities of the DRIs. The DRI role is not a "manager" role nor is it an "official" or permanent one. The DRI role is a leadership role. It is about pushing the project forward and making sure nothing falls through the cracks. Being a DRI doesn't mean I have to do all of the work, instead I should be resourceful to delegate and work with the right people on the team that will help me deliver the best result.

Shared responsibilities include:

Planning and Coordination

Daily Sync

One aspect of office life is that after the commute, you inhabit the same space as your coworkers. You chat while coffee trickles into the already-emptied carafe. Remote work doesn't afford the same sense of "showing up" and "seeing everyone arrive at their desks." We add a daily touchpoint of our own in the form of a daily, brief meeting at 11:30 am ET. We all hop into Zoom (we use zoom here because it allows the "gallery view," where you get to see everyone's face at once) and run through

Daily sync from early 2019 A rare gif of a morning sync from late 2018

We rotate who leads the daily sync every week, running through the team alphabetically. Similarly, some product teams rotate who gives the day's update, and others' delivery is via the DRIs. Rotating who leads and gives updates is a great way to hear everyone on the team, and it gives a great sense of ownership over the process to the whole team.

1-3-6

One of the more concrete responsibilities of the DRIs is to maintain what we call the 1/3/6, which highlights a product team’s plan for one month, three months, and six months in a decreasing level of detail. The decreasing level of detail allows us to see where we’re going without getting caught up in little planning details for something a few months away (which will probably need to change anyway).These documents serve as a center-point for team syncs, and work moving in the one month category is created as issues in the GitLab backlog.

Product teams have a meeting each week to plan their work for the coming week. Those meetings have nuances across the different teams, but here’s the agenda's gist:

1. Review the GitLab board, filtered with the product team's label. Go through each card and make sure it's in the right place, and make sure there are no cards missing for work in progress. 2. Go to your team’s 1/3/6 month planning doc and look at what your current goal(s) are, what’s in our 1 month plan, adjusting and updating if necessary. 3. Review upcoming customer deliverables/deadlines. 4. Create next week’s weekly goals and update Weekly Themes doc.

Your Turn!

There is a lot to consider when embarking to create and grow a remote team. It won't work for everyone. Some people find energy in physical nearness to their coworkers. Others may not have the autonomy necessary to thrive in a more independent work style. But for those teams that desire flexibility, and are inherently autonomous and asynchronous, I hope this document gives a window into the how and why of remote teams. Why remote work can be a powerful design for a team, especially a software or digital one, and some of the strategic and tactical steps we've taken to implement it successfully. At Upstream Tech, we are still learning a lot - and we will always make time at our in-person gatherings to discuss and adjust our processes and tools. But so far, we've been able use these concepts to scale our team's growth, build technologies for the environment, and counter climate change.

If you have a remote team and want to chat, or if you're looking to create a remote team within your organization, send me a message at {^@marsh}. I'd love to hear about what works well for your team or challenges you've encountered.

Remote work is a big part of what is to come for great teams!