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.


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!

Tags: remote, startups

Remote work is at the core of our little company. I've written about how we improve our tool set to foster and improve communication in our team and about our company values as a distributed team.

Working in a distributed team poses personal challenges too, and by jolly, I've been busy working through my fair share of them.

I've been working from home for all of last year, and I've done a few mistakes along the way that caused me frustration and decreased my productivity.

Embrace the solitude

The best part about working from home is that there are no distractions. We have a lot more room, compared to an office, to get work done.

The downside is that as attention-seeking humans, we tend to look for distractions if we don't have any.

If you follow me on Twitter (which you should, you'll know that tweets come in bursts. These bursts tend to represent times of boredom, times where I can't find any mental room to concentrate on working.

When you're alone at home, you look for contact with other people. The internet is a great place for that. There are things happening on certain news websites, on Twitter, Facebook, in IRC, in our team chat.

Of course, the worst offender of them all is email. Are you opening your email client first thing in the morning? Are you excited about seeing 50 unread emails waiting to be processed and replied to?

Me neither.

It's a weird reflex that we turn to email first, well knowing that what's expecting us commonly isn't urgent and drains creative fluids before any creative work gets done.

This has been the most frustrating to me in the last couple of months.

Cut out unnecessary distractions

I've started forcing myself to not open email before noon. I tend to be the most creative in the morning hours, and with the team slowly waking up throughout the day, the amount of other distractions increases too.

I've also found myself frustrated and mentally drained going through emails before doing anything else.

It took me a year to be fully aware of this.

So I started postponing email. It takes getting used to changing this habit, that's why forcing yourself to do it is all the more important. I also make my team aware of this, but expectations commonly aren't that replies should be sent within hours. All communication is asynchronous, and so is email. If there's something urgent, there's always the phone.

I've started doing the same with Twitter too. I love reading what's going on with the people I follow, but it sucks away concentration too.

For being in a creative workline, we have a curious tendency of actively looking for distractions where we could put the energy to much better use.

Avoid email and Twitter, anything distracting before work.

As Jason Rudolph put it, create before consuming. This way is much more fulfilling than trying to muster up energy to get something done after you've consumed Twitter, email and other distractions.

I've stopped reading emails on weekends too. I found my weekends much more relaxing since then.

Make small commitments

I went for months without having any specific goals. It was very frustrating as I didn't really feel I got anything done during a day. I probably did, but I forgot what it was at the end of it.

I usually keep a daily list of tasks around. Just a piece of paper and a pencil is sufficient.

Takes a few minutes in the morning to think about what I want to get done, but taking that time to think about it already gives you the feeling of having goals.

Being able to cross them off a list with a physical activity, like violently striking through the tasks, can be rewarding.

At the end of the day, you'll have a list of tasks you got done.

If you didn't get one of them done, maybe it needs to be broken down into smaller steps?

Big tasks kill productivity, as they appear to never be fully done.

Break them down.

I've started tracking things I've committed doing every single day with a little iPhone app called Commit. It's quite handy to track daily walks, writing and doing pushups every day. You'll be surprised how quickly you can ramp up the number of pushups you can do when you do them daily.

Escape the solitude

I love working in a remote team.

But just as much, I love being with and talking to people, even if it's just listening to their problems, listening to what news they have.

I've gone a month or so without meeting other people, which was rather depressing. I've gone for months just sitting down at the kitchen table, never getting up until 10 hours later. These habits are so easy to slip into, and they need conscious efforts to get out of.

Since then, I've started forcing myself to go for a walk or a bike ride every day.

Not only does this help with the overall fitness and well-being, it gives the mind time to breeze. When you don't focus on anything else, your mind can regenerate. It appears this is even scientifically proven.

I've went for months without ever leaving the house, other than to drop off my daughter at the kindergarten. Believe me, those months I've felt miserable.

Go for a walk, every day.

Working from home is hard. I've been doing it for more than a year now, but I'm still struggling to get it right.

Being more productive standing up, I got a new standing desk rig set up in my little home office. You'd be surprised how much dancing while working can lift your spirits.

I've been reading a lot of articles and posts on working from home, and I agree on their general premise. You need to push yourself harder to focus on getting work done.

The line between work and life gets thinner working from home, and working in a company with lots of customers from overseas, calling it a day is even harder.

But I've learned to trust my team, which is distributed across the globe.

I'm starting to learn to disconnect.

Tags: remote