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!

Tags: remote, startups

During the first weeks in a new role, one of the things I’ve most recently focused on is to assess the direction of the engineering department as a whole. Will Larson has written at length about the first ninety days in a senior engineering leadership role. He also mentions documenting the existing strategy as one of the key milestones to take care of.

At the time I started there was no explicit strategy in place. Which is also not an unusual thing for a young company, just to be clear. So I set out to draft one.

As a remote CTO I considered a documented engineering strategy one of the key tools to provide direction and context. Especially when I’m not around during discussions, a frequent occurrence when you’re to nine time zones away from everyone.

Unfortunately examples of engineering strategies are far and few in between. There’s plenty of examples on the importance of having a vision and strategy in place though.

For instance, Cate Huston wrote about the importance of having a vision, mission and a strategy as the corner stones of communication in a team.

Daniel Schauenberg wrote about learning to have an engineering vision in place.

The missing piece for me was how to put together a strategy and come up with a compelling one for my team. That’s the process I’m documenting here.

This post is based on a Slack thread in the eng-managers Slack where I wrote about my approach. Do note that this is only one approach of many. Approaches vary depending on the organisation, its stage, or where the team is at in its own trajectory.

Prerequisites

When I started out there was no explicit direction place for the engineering department. There also were no OKRs or similar tools that may have provided a foundation for such a strategy.

I had a blank slate in front of me. This was both exciting and also required extra care to get a strategy in place. The only influence I had was the business strategy as well as a product manifesto. These proved to be useful to have in place as it provided context for everything the engineering department would focus on.

My goal was to come up with a strategy that features several elements:

  • A mission for the engineering department that outlines the overall direction and focus.
  • A number of objectives to steer the technical direction for the next 12 to 18 months.
  • A list of process refinements that make explicit changes in approach or structure.

I didn’t want to have this entire document to come from the top. Nor did I want to shift the entire team into a whole new direction as sometimes can be the case. This can be necessary depending on what stage a team is in. But it wasn’t in my case.

So I started talking to key folks from the team.

Gathering Perspectives and Input

I spent quite some time listening to folks. I read slews of documents, meeting notes, roadmaps, to understand what trajectory the team has been on so far.

Listening proved to the most fruitful here. Here are some questions that proved useful to explore:

  • Is there a technology currently being removed from the stack?
  • Is there a new technology that the team is keen to try out? Or a technology that is worth implementing to support a larger business initiative?
  • Is there a process or structure that’s not working or that’s getting in the way?
  • Are there any places where the team is understaffed (or overstaffed) or missing key experience?

It was also helpful to understand how these decisions have been made and how folks have arrived at their own conclusions.

The goal here is to assess where the team is at as of the moment that you’ve joined them. You may find gaps in joint understanding of where the team should go, what technologies should be adopted (or cast aside), or what it should focus more (or less) on. These gaps are useful to uncover as you now have a chance to close them!

The process will likely last over multiple conversations. Don’t force this within just two weeks. It’s worth exploring and looking for nuggets in the conversations to dig deeper into subsequently.

These questions help you craft a strategy that documents the current approaches (that are working) and that includes new approaches and goals.

Having the business strategy helps in these conversations. It allows you to ask folks questions like: “How do you think this ties into our business goal of achieving X?”

You may not always come to a compelling answer. In that case it may be up to you to connect the dots or discard the idea.

What if there is no Business Strategy?

Especially earlier stage companies don’t yet have a business strategy in place. In this case it can be a struggle to connect your engineering strategy to the larger business goals.

What can help is talking to the other teams and departments around you. Ideally you focus on those where your team has the largest contact surface.

Ask them about what’s most important to them, what their own measures of success, their OKRs, or their longer term goals are. This doesn’t need to be stuff that’s directly related to your team’s work (depending on what level in the organization you craft the strategy). But it can give you clues on what’s important to the departments around you.

This can be any part of the business that is impacted by your team’s work. For instance, other engineering teams, product management, marketing, customer success, and so on.

Do make sure to make the learnings and assumptions derived from these conversations explicit. This will help everyone understand the context.

Drafting Objectives

An objective is a longer term goal that requires multiple steps and likely a longer stretch of work to get it implemented fully.

“Swap out the WYSIWYG editor for that new thing from Basecamp” is more of a project than it is a strategic initiative. It doesn’t work well as an objective. It’s also more descriptive and doesn’t leave much decision making power with your team. Which in the end, is one of the goals to have a strategy in place.

“Migrate core functionality pieces (including authentication, user data, shopping cart) to a micro services architecture that’s running independently of our main application” works much better. This is a long term commitment and also provides enough freedom for the teams to discover and decide on how they’ll achieve this goal.

It can be helpful to outline for each objective to include a short description on how it supports the business strategy. This is useful context to make this connection clear to everyone. If it’s not the strategy then it could be a case of how it supports the business as a whole.

What’s important to you?

While this whole approach is supposed to gather as much input as possible from the team, there’s also room to add your own improvement ideas. Ideally those are bought in from the team as well of course.

A few examples of what I focused on here is making explicit a new structure for how the engineering teams are working together on specific projects. Or a focus on continuous delivery by doing more regular releases.

These can be process improvements like preferring early prototypes over late feedback. Or maybe you want your team ship every day. Or there needs to be a better way for making decisions in the team. This list can include anything that you think helps the engineering department support the business more effectively.

That per-final step

Before making it official the strategy was open for feedback. The subsequent discussion helped uncover some possible conflicts and misinterpretations. So it was helpful to spend that time to get a crisper strategy.

This process also helps increase buy-in for the document across the team.

Putting it all together

What I had at the end was a strategy document that outlined:

  • The engineering team’s mission and how it relates to the business’ overall mission.
  • Seven objectives that steer larger technical decisions and direction over the next 12 to 18 months. Seven is not a magic number here, but it helps to keep this list below ten.
  • Three process improvements to help the engineering team support the business better.

The exact number of items in each isn’t as important. What’s key is to keep the strategy concise. Each item included an objective and a wee bit of context. The entire document had 500 words.

For deeper inspiration on how to draft crisp and actionable strategies, I recommend the book “Good Strategy, Bad Strategy.”

Good luck on your journey of drafting a strategy for your team.

One thing I wanted to a better job at as I took on a new role last year is to be more deliberate in giving feedback. As a German, I tend to fall on the side of only focusing on negative, or constructive feedback. I tend to focus on pointing out what I think should be improved, or what isn’t conclusive. This is quite ingrained in the German work culture.

Over the years I’ve come to appreciate positive feedback more and more. Getting affirmation or appreciation shows us that we’re doing something right. That we should keep going down the path we’re on.

Constructive feedback tells us where we should course-correct. Together they give us a compass for our own personal and professional development.

In the daily shuffle of work, feedback used to fall off my radar. It still does from time to time. So I was looking for a means to be more deliberate about feedback. And a means that helps me track and plan the feedback I distribute.

Meet the feedback log. It’s not a complicated thing. It’s a text file. It has two sections:

  • History: a timeline of feedback I’ve given, to whom and when.
  • Future log: a list of feedback I intend to give at the next occasion, indexed by person.

It could like this:

  • 2019-07-25, Virginia: The presentation you gave last week was great I thought. The subject matter was well researched and presented. The conclusion you got to made sense to me. You built consensus with your team on the final decision and gathered input in the presentation, which helps us and you make better decisions.
  • 2019-07-23, Max: Last Tuesday you posted a comment in Slack that could be taken the wrong way by some folks. It used language that could make some folks feel excluded. For the future, I’d suggest that you avoid this particular language.

For the future log, I either leave out the date or include the date of our next conversation.

Why is this useful? It helps me keep track of feedback when I observe a situation worthy of it. I can go back to my future log before every 1:1 and see if there’s something I should bring up.

The timeline helps me be more balanced in my feedback. I can ensure that I give both affirmative and constructive feedback in equal measure.

Lastly, it serves as a record of all feedback I’ve given. This can be useful to go back to in the future to see the progression over time for an individual. Should there be a dispute over what kind of feedback I’ve given in the past, I can go back to the list too to verify.

It’s a little thing but sticking to it with some discipline has helped me build up a better habit of giving feedback.

Inspiration for this log came from the Decision Log in Oren Ellenbogen’s book “Leading Snowflakes.”