Remote founding team

Pandemic restrictions and lockdowns made remote work a real possibility for a lot of people around the world. For those of us who have been working with distributed teams for years, it was nice to see so many people and so many companies making the transition to remote work. It was also frustrating to see the amount of resistance and the tone of some of that resistance. We should all admit that the circumstances of the past few years are unique and remote work within that context is likely different from remote work when there isn't a global health crisis. However, now that people have a taste of what is possible, more companies are making a permanent transition to some type of distributed work setup.

The founders of Yetto have been working remotely for years, and we have learned a lot along the way. When starting our own company we never considered working from a co-located office. For starters, it wouldn't be possible. The three of us live in Texas, New York, and Rome, so commuting was not an option. Beyond that, when it comes time to bring more people into the team we don't want to be limited by our location or theirs. Talent is distributed and so we will be too.

Given our combined experience with remote work and distributed teams, we thought it would be useful to share our setup - what tools we use and how we work. Our systems might not work for every team and every company (and remote work might not be the right move for every person, team, or company), but seeing how other teams operate can help people make decisions for their own teams and possibly spur some new ideas.

How we work

First, let's talk about processes. We're a small team of three people getting a new company and a new product off the ground. There is a lot to do and not a lot of people to do it, and there is some need to move quickly in order to not lose momentum or run out of money. When the team is distributed geographically and across multiple time zones, we need a way to know who is doing what, get timely updates, and get help from each other when we need it. To do all of this, we've settled into a habit of splitting up work so that nobody is holding anything up for anyone else. Each member of the team is responsible for one or more areas of work, with the other two helping whenever needed. We informally call these our "fiefdoms" within the company.

I handle most of the business and financial tasks (working with lawyers, setting up bank accounts, talking to investors, etc.). This also includes things that would fall under "sales" and "partnerships" in larger companies. All big decisions are run by the team so that everybody has a say in how the business is run, but nobody else needs to be directly involved with those lines of communication.

Garen is in charge of the app development. All three of us on the team have backgrounds in software development, and everyone chips in on development work and code review, but most architectural and technical process decisions are made and documented by one person so that we are all aligned on how we're building.

Nick leads our product development - what we're building and how people should interact with our app. The whole founding team is involved in discussions around this (as we should be at this stage), but the final say on user experience decisions comes from one person, which helps us avoid endless circular arguments.

It isn't a perfect setup, but it allows us to move fast without the need to discuss every decision at every step.

How we plan

Our project planning method is the other key to our momentum. Rather than think in two-week sprints, as developers often do these days, we break work out into 6 or 8 week chunks. We call them "passeggiata's" (from the Italian word for a leisurely stroll). Part of the point of this is that we want to emphasize that we aren't trying move fast so much as trying to keep moving. Another point, though, is that we can plan for a decent sized body of work every month or two and then go work on it. With two-week sprints I've found myself spending a day planning and a day reviewing, leaving 8 days instead of 10 for the work to get done. With 6 weeks to work, we can plan for a day or two in advance and then spend more time shipping products and features.

This is important because we don't have a lot of cross-over time as a team every day. With our distribution across time zones, we only have a few hours each day where we're all online together. We often spend some of that time in Slack chatting through some small problems or organizing some tasks or just chatting about our lives. The rest of the time, however, we spend working, which often includes a lot of reading and writing. As a remote team, most of our interactions are asynchronous and done in writing, often long form texts. We have spent years getting better at writing concisely, reading quickly, and absorbing information from a variety of written material. It's probably the key set of skills that make remote, asynchronous work work for us.

Not to say that we don't like talking to each other. We set aside an hour a week for a face-to-face chat over a Slack huddle. Half of this time is usually spent talking about our lives outside of Yetto. The other half is spent resolving unanswered questions from the past week (which we then write down somewhere) or showing off a demo of some recently completed work. The demos are the best part of the week, by far.

That's what working on the Yetto team looks like day-to-day and week-to-week. It's fun, but when describing it like this it can sound lonely. As if everyone is working alone and only popping up to see their teammates for an hour a day or an hour a week. But it doesn't feel that way. We feel like we "see" each other for hours a day, either in Slack channels, Slack huddles, or in all of the other places where we read each other's writing.

Where we work

Let's look at where all those places are. At Yetto, we use a couple of tools for tracking our work, tracking our decisions, communicating with each other, and building our product. And we have a (not so rigid) system for when to use which tools.

• Code - GitHub
• Deployments - Slack (Sisyphus our Slackbot)
• Draft ideas async - GitHub discussions
• Long-form permanent notes - GitHub repository using Foam
• Project planning - GitHub projects
• Synchronous chatter (work-related and fun) - Slack
• Decision making - GitHub pull requests (for code or narrow product decisions), GitHub discussions (for larger product or business decisions), or GitHub issues (for narrow product decisions around bug fixes)
• Weekly face-to-face video chats - Slack huddles (any decisions made here get documented in a pull request, discussion, issue, or repository after)

You'll notice that we use GitHub a lot. We all worked at GitHub together years ago, where we got in the habit of using GitHub for all of our daily work. However, we use it not only because we're familiar with it but also because we find a lot of value in consolidating tools. The "best tool for the job" is a difficult thing to pin down. In general, the best tool is going to be the one that gets the job done (whatever that job may be) and is easily accessible to everyone. Once you have everyone in the same tool, it's easier to communicate with each other asynchronously. You can all check your notifications in one place for all work-related updates, discussions, and decisions. For us, having as much of our work in GitHub as possible makes it easy for everyone to keep up with everything happening, which tends to be a lot even at very early stage companies.

What you should do on your team

All of this is how we work at Yetto. This is not a suggestion of how you or your team should work. The underlying principles, though, could be applied to any remote team.

• Document everything.
• Make the documented work easy to find.
• Everyone's role and responsibilities should be clear to everyone.
• It is more important to work at a consistent pace than it is to work fast.
• Use the best tools for the job - whatever that means for you and your team collectively.

When building a team from scratch, it's easy to implement all of this in one pass. If you're on a remote team already, or if you're on a team that is planning on going remote, it may be easier to implement some of these ideas little by little. Perhaps starting with internal documentation habits and role definitions. Maybe choosing a couple of tools to use to keep everyone organized and in sync. It depends on the people involved, the needs of the team and company, and the end goals you have in mind. Whatever you choose to do, hopefully seeing how other teams operate gives you some ideas.