Every now and then a fellow founder approaches me looking for advice. The topics range from pricing, positioning products, to building and growing teams. Or in this case, they are questions about what to consider when you’re looking to go remote.
A founder building a startup in Europe recently asked me for advice on building a remote team.
I’ve been working in distributed teams for ten years now. Those teams have spanned from Europe to the US west coast. Sometimes they went beyond that, covering almost 24 hours of timezones.
Here I focus on those downsides more than I do on the general advantages of working in a remote team. They tend to be things that founders and business don’t really focus on when building remote teams. For instance, thinking about how it impacts the individuals in your team and their personal and work lives.
I’ve been personally affected by burnout through late evening meetings, loneliness, feeling disconnected and unproductive. So some of these answers draw from my personal experience. That experience may be very different for others.
How do you deal with timezones?
Knowing what I know now, I would limit time zones in which to hire as much as possible. If you can avoid it, don’t expand further from Europe to the US east coast. The US west coast adds a whole new level of coordination of the team’s work and communication. Especially for a company in Europe and when meetings and in-person conversations are your prime mode of communicating.
It’s a source of burnout for you as the person to manage it all. You likely have to be present for more meetings than folks from your staff do. These may span into your evenings (or someone else’s early mornings) and into time you’d spend recharging, or with your family.
So to answer that question about how to deal with time zones, my advice is to avoid or limit them as much as you can. As long as you can, try to find other ways to solve the problem instead.
Solutions could involve having folks (or yourself) travel every now and then to do the same kind of work. For instance, to visit customers, to give conference talks, or interact with partner companies. Travel brings its own personal cost but can be controlled easier as the travel times can be limited to a few times per year.
Having folks only in European and adjacent timezones can work nicely, as there’s sufficient overhead. US east coast can also still work. The overlap here is still a few hours.
US west coast is just very difficult for everyone involved. Meetings seep into early mornings or late evenings if you’re not deliberate about timing.
There’s a risk of someone feeling isolated, disconnected and not properly supported for those folks you have over there. This is especially true when you hire one or two people and leave it at that.
From personal experience, I’d recommend hiring at least two folks in a similar timezone around the same time. That way they have at least one other person they can have regular human interactions with.
Do you do standup meetings of any kind? Are they even useful in remote teams?
I don’t do any standups in general. As soon as you span more than one or two time zones they tend to become meaningless. I’ve found it more effective to do these asynchronously, e.g. by having everyone send weekly updates of what they’re working on. Or daily if they need to.
Having an in-person standup in a distributed team can be awkward too. Maybe you have someone who’s just starting their day, while others are already in the middle or end of it.
When somebody needs help, asynchronous mediums should allow for those things to bubble up much sooner. People shouldn’t have to wait until the standup for that.
It’s worth asking why you want a stand-up meeting in the first place. Is it to keep tabs on what your team is up to? For a young startup, this can make sense. But that information could also be typed into a chat or text window somewhere and be stored for everyone to see.
Have you found a documentation structure that really works?
There’s no one structure that just works. There’s only what works at the moment, for the next couple of months, for a particular team or company. The aim here should be to start simple, e.g. by having a baseline structure like this:
- Company
- Engineering
- Operations
- Customer Support
- Product
I tend to start with a simple structure and let things grow organically. Then you adjust and readjusting based on what’s evolved in the previous months. I found that a lot less stressful than poring over what’s the right kind of structure before you even know what goes into the documentation.
The key thing really is that documenting as a key means of communication needs to be at the front of everyone’s minds. That’s the most important thing for me, not the structure.
Have you experienced loneliness or other psychological issues among coworkers? If so, what helped to remedy that?
Yes, I’ve experienced this and also had coworkers experience this. It’s one of the great trade-offs of remote work, which is why I asked why you want to go remote. You should be really certain that this is a trade-off worth making for the benefits you’re getting in return. It’s why I had left a job years ago because I felt so disconnected and not really as a part of my team.
Things that have been known to work and that I’ve experienced with as well:
- Weekly donut meetings where random folks got together 1:1 to chat for a half-hour and get to know each other better. This wasn’t necessarily about work but more a personal thing.
- Getting the group together via video weekly should also help, especially when the team is still small (less than 20 poeople). You could have people chat over coffee and donuts, have everyone present what they’ve worked on that week, or give talks on interesting topics. Or all of the above. Having kids and pets as part of those video calls can help loosen the structure.
- Encourage them to meet in person. That could be via travelling to a place where a coworker is, or by meeting up with folks in the industry in their area. Not everyone will be able to travel but pretty much everyone needs a feeling of being connected. If someone’s alone in their location, you could give them a time and money budget to go meet folks and have coffee.
How do you deal with micromanagement vs. being too laid back in folks managing their work hours?
Remote teams mean that you need to trust your team to do the work. You need to focus on the outcomes and that they get their work done.
Focusing on work hours is where micromanagement quickly intrudes on your team’s freedom to set their own working hours. It can also be a pointer of their manager or the founder struggling with remote work.
What I prefer focusing on is to set weekly goals with team members and to focus on whether they achieve them or not. And if not, we discuss what got in their way.
Time is an elusive concept to focus on, just like e.g. commits or comments on pull requests as a measure of output. Both are meaningless and won’t tell you anything about whether or not your team and its individuals got their work done.
Remote work tends to go in hand with letting your team set their own working hours. You gotta be comfortable with that because the simple truth is that you can’t control it when you’re not seeing folks at their desks all the time in an office. And even when you’re in the same location, focusing on working hours is meaningless as a measure.
For you, the most important questions should be: is my team getting the work done (without burning themselves out and working overtime)? And if not, what’s in their way and how can I help them remove that obstacle?
How do you onboard people in a remote team?
Onboarding folks in a remote location and team requires good preparation upfront. When they come in on their first day it should be crystal clear what they’re going to do.
This can include:
- A buddy who is their first point of contact and will guide them through the first one or two weeks of the new job. This can be their manager or anyone from the team really. Onboarding buddy is a role that’s best rotated.
- As founder or through their manager, schedule an orientation meeting where you walk them through the most important things.
- All important accounts should be prepared ahead of their first day.
- Make sure that hardware is ordered ahead of time and shipped directly to their location so that’s it’s ready on their first day. Same for any onboarding items, merchandise, multi-factor keys, and other things that you want to provide new employees with.
- A schedule for when they have 1:1 conversations with people from the team. In these conversations, you could have every team member lead the new person through a certain aspect of the company, codebase, tech stack, etc.
- A list of resources they should be reading to get an overview of the company, its culture and its processes.
- A list of work items they could dive into. Especially for engineers, the feeling of value increases significantly when they get a chance to contribute something of value early on.
In the past, I’ve had good experience keeping this entire list of action items for someone’s first two weeks in a shared place. This could be a GitHub issue, a Jira ticket, or a Trello board. As long as everyone involved has access to it, folks can document status and tick off action items. They can also leave comments on things that they’ve noticed in their first couple of weeks.
Conclusion
There are plenty of reasons to build a remote team, especially for a young startup. Going remote from the ground up is the easier way to create a culture and processes around asynchronous communication. Business-wise it can make a lot of sense to have people in different locations to build, sell, and support your products.
But there are plenty of trade-offs to make. I’ve only touched on a few in the answers above. There are plenty more. As you consider going remote, please do ponder what it means for the individuals on your team.
Remote work has a lot of potential for the individual’s flexibility in how and where they work. For some, maybe not all, it comes at a price. Not everyone can afford to join late-night meetings without sacrificing family time. It’s also hard for some folks to be fully present at the end of their day.
Keep those things in mind as you consider building a remote team.
Got any questions for me, whether on building remote teams or on other topics? Get in touch!