How to Transition to a Remote Engineering Team: The CTO’s Cheat Sheet

transition in-house dev team to remote engineering team
Summary:

Is your engineering team suddenly forced to work remotely? From what to cover in your kick-off meeting, to how to work remotely, here’s what you need to know.

Are you thinking of making the transition to a remote engineering team?

With fast internet, better video conferencing solutions, and modern management philosophies that are often far more flexible than traditional ones, remote working is becoming more and more popular.

However, even with advanced communication tooling, video calls are not the same as in-person conversations.

If you’re about to make the jump from managing an onsite, co-located team to managing a fully or partly remote team, you’ll need to think in advance about the many changes this transition to remote will bring.

Looking for top talent fast? See how Arc can help you:

⚡️ Find developers, designers, marketers, and more
⚡️ Freelance or full-time remote + fully vetted

⚡️ Save up to 80% with global hires

Hire top talent with Arc risk-free →

The Different Kinds of Remote Work

Remote work is a broad term that covers many similar — but fundamentally different — set-ups. Some common ways to describe and use remote working, especially in tech teams include:

  • Working from home days: employees sometimes work from home
  • Partially-remote: some employees are remote while others are co-located at some kind of HQ
  • Fully remote: There is no HQ and all employees work from anywhere

We’ll briefly cover exactly how these work with some pointers on how to avoid common pitfalls in each setup.

Using Working From Home Days

Working from home (WFH) days can be a great way to help your employees handle stress and achieve work-life balance. Even if it’s only one day a week, WFH can provide the employee with a break from the office.

They don’t need to deal with a commute, know they can be available to pick up a home delivery, and can have lunch with their family. If you have an open-plan office, WFH days can also provide time for someone to focus and do deep work that requires little collaboration with distant colleagues.

Once you’ve decided to try out allowing people to work remotely, you need to make some big decisions. One important aspect of the WFH setup is choosing whether each employee decides which day or days they want to work from home, or if the entire team takes their WFH day at the same time.

Although the flexibility of letting people choose is nice, you might find that with medium-sized and large teams it becomes difficult to find a day when everyone is in the office. If your team relies on all-hands meetings to share information, this could be a problem.

It’s also possible to find a compromise: allow people to choose when to work from home, but block out a specific day of the week where employees should be at the office for meetings.

Read More: Why Employee Development is Good for Business and Your Dev Team

A Partially Remote Setup

A structure where most people share a central office but some employees work remotely is possibly the most common structure — and the most tricky to get right. Especially if only one or two people are remote, it’s easy for them to miss out on important information that might be shared informally at the office.

The remote employees can also come to feel isolated, not understanding “in” jokes made during conference calls, and not being able to take part in team activities, outings, or lunches.

Trying to make life easier for your remote employees is a great way to prepare your entire team to go remote. Some small shifts that you’ll want to experiment with include the following suggestions.

Encourage people to communicate over chat, even if they’re in the same room

This can often feel awkward at first – for many people it’s far more natural to resolve a quick question or issue with a “Hey John, do you know how to…” shouted across the room than it is to type that out as a chat message, but written communication starts to feel natural very quickly with a bit of practice.

Having people get into this habit also means that the office remains quieter and more productive in general (not everyone is disturbed by every conversation). Further, a record of the conversation is preserved, and over time a company knowledge base can be built up, where newcomers can search chat history for answers to common questions.

Encourage people to share information in relevant groups rather than in private messages

Often people will naturally gravitate to directly messaging the person who they think can help them directly. Encourage your team to share information more widely, in the team chat or in a relevant channel.

Often, someone else might have a different or better answer, and they can easily chime in to help in a group chat.

Read More: On-Site vs Remote vs Distributed Engineering Teams: How to Choose?

Start preparing more detailed agendas, minutes, and documentation

Instead of resolving larger matters with “quick chats” or impromptu meetings (it’s hard for remote employees to participate in either), spend more effort up front in defining meetings, as well as sharing an agenda in advance and a summary of decisions made afterwards.

It sounds like more work, but often preparation can turn an hour-long discussion into a 20 minute conversation as people have had time to think about things beforehand. Remote employees can also easily read these documents (and dial into a meeting, if it has been scheduled).

Similarly, if someone asks how the ancient system most people have forgotten about but now half the business relies on works, the fastest way is often to describe or demonstrate it. The new person can then “carry the torch” and describe it to the next person who needs to know.

A slower — but often better — solution is to write a shared document, create a wiki page, or even make a screencast, and share that instead. This can also be shared with remote employees. Although it takes more time upfront, it will show great returns as onboarding new people to the system is now as easy as sending them a link.

You might have noticed a pattern above. Generally, remote work favors asynchronous communication vs synchronous communication. This often feels inefficient at first, as a face-to-face conversation is nearly always the fastest and easiest way to get something done.

Over time, however, asynchronous communication can often be more efficient as it is more deliberate and can be reused as often as necessary.

Read More: The Journey to Product-Market Fit: From POC to MVP to Prototype to PMF

You can also try Arc, your shortcut to the world’s best remote talent:

⚡️ Access 450,000 top developers, designers, and marketers
⚡️ Vetted and ready to interview
⚡️ Freelance or full-time

Try Arc and hire top talent now →

Abandoning HQ and Going Fully Remote

If you’ve had some remote employees and have attempted to treat them as first-class citizens of your company, leading a fully remote team should be fairly straightforward. However, if you have no facetime at all with your employees (except maybe for that annual retreat) some things can be problematic.

Getting the right tools and using asynchronous communication nearly all the time is even more important than with a partially-remote setup (especially if your team is distributed globally and working across different time zones) and learning how to trust people absolutely becomes fundamental.

In a co-located office, you can easily look up and see who’s sitting at their desk. This already provides some indication that work is probably being done. With slightly more effort, you can move around and see who’s actually watching cat videos on YouTube instead pulling tickets off a queue or writing up that report.

You can get a general feel for what time people arrive in the morning, what time they leave, and how they communicate with you and their peers. Once everyone is working remotely, you lose all of this and you usually have to rely far more on trust.

The alternative to trust is to use invasive monitoring tools that allow you to turn on your remote workers’ webcam on at will and to see what is on their screen. However, there is research that suggests invasive monitoring can “incentivize untrustworthy behavior” — that is, monitoring people removes trust from the equation and employees will often feel more justified in evading the monitoring and slacking off.

Let’s stick with trust for now!

Many would argue for a balance between trust and monitoring, and depending on your team and the culture of your company, this might be necessary. In an ideal world, your hiring processes would ensure that only trustworthy employees get through the door, and monitoring would not be necessary. In reality, you might have to deal with untrustworthy employees who want to take advantage of the system.

Trust is interesting in that it is often a self-supporting social construct. If you make it clear that you trust someone (which usually involves not monitoring them at all), it is common for someone to enjoy the feeling of being trusted and to have an intuitive desire to preserve the given trust. Therefore, circular as it sounds, it is possible for someone to be trustworthy simply because they were trusted.

Even if you don’t believe that all of your remote workers will be completely trustworthy, it’s likely that your employees who are trustworthy are more valuable to you than those that are not. Apart from being trustworthy, these are probably your team members that are able to work more independently, make better decisions, and work with more dedication.

The result: any monitoring that you put in place to protect you from untrustworthy employees is likely to have a negative impact on your trustworthy employees. Sometimes it’s best to make peace with the fact that one of your employees is working at 10% productivity (and possibly start to transition them out) in order to allow another six employees to work at 90% productivity.

The other option, implementing monitoring, may just cause in all of your employees working at 60% productivity — and that’s not a result you want!

Read More: Are Personal User Manuals Useful for Managing Remote Teams?

How to Transition from Co-Located Office to Remote Work

Once you understand the different kinds of remote work, why asynchronous communication is more important in remote contexts, and how trust fits into the picture, it’s time to actually make the transition.

As with any change, it’s probably not going to be a straight and smooth ride, and it’s important to find processes that work for you and the rest of the team.

In general, as with a large software project, changes to team structure, culture and setting should be made in small pieces and with tight iterations. If you’re able to do the transition slowly by introducing working-from-home days, then a partially remote setup, and finally abandoning the HQ, you can learn lessons at each stage and apply them along the way.

Even if you’re not, you can still try various things out and see if they work for your team. Some things to test out include:

  • Remote standups
  • Refactoring your decision-making processes
  • How to run general meetings

Let’s investigate these more deeply below.

How will you do standups, if at all?

It’s common, especially for developer teams, to hold a “stand up” meeting every morning. During this time, each team member gives a brief summary of what they’re working on and any blockers that they have.

Once working remotely, it’s still nice to have this quick daily chat to coordinate how team members can help each other, but there are different ways to go about it. Perhaps everyone gives a short written update by email or IM, either at a specified time, or whenever their morning is (again, especially if you’re split across time zones).

If you’re all in a similar time zone, you could still have a synchronous video call, which can make the process less formal and allow some time for a social catchup too. If you like video, but scheduling everyone at the same time is hard, people could leave video updates. Combinations of the above are definitely possible too.

Instead of picking one of the above options and pushing through, hoping people will get used to it, try them all out and decide together which one works best for everyone. It’s likely that you won’t find consensus, and you’ll need to trade-off some people’s preferences against others, but don’t be afraid to change your mind more than once if things aren’t working out!

Read More: Here’s How to Motivate & Reward a Remote Engineering Team Effectively

Decision-making and process

Balancing the amount of process and formal protocols a team needs to be effective is always difficult, but this will be challenging in new ways for teams adopting remote work. With more information being written down and shared more widely, it can be easier to have everyone in an organization pull together.

Defining clear processes for how work items are scheduled, how requests are made between various teams, and where concerns are raised is a good baseline. In general, it is good to err on the side of having too little process and adding more in as necessary — having processes that people have to follow, but don’t see the point of, is always demoralizing for the team.

Decision-making in remote teams is also often done more frequently by individuals (and less by multiple people in meetings). While scheduled team meetings can still be used for important decisions, you don’t want your remote team to be waiting around, blocked by a decision that needs to be made.

Pushing decision-making as far down any hierarchy as possible, and giving each individual the control to be productive on their own, is beneficial in many organizations, but it is more important in remote ones. This is because it is often more difficult for people to get quick access to decision-makers, especially if the team is split across time zones.

In software engineering, there is a principle of ‘single responsibility’, where each component of a system should be clearly responsible for specific functionality. It can often be tempting to have two individuals or teams be responsible for specific components, with the thought that if there is a problem with one, the other will catch it.

In reality, it is more common for things to ‘fall between’ the responsible parties — like beginners playing a doubles tennis match, and both thinking the other one will go for the ball.

For remote teams, this principle should be applied even more strongly than in co-located teams. Because it is more difficult to get quick clarifications on small issues, it needs to be crystal clear where the buck stops on any issue.

Read More: How to Manage Developers on a Remote Engineering Team

What about meetings?

With high quality video calling, meetings can be run very similarly to how you were used to when co-located. But you’ll still need to try out different products such as Zoom, Hangouts, Skype, Slack, and others to see what works best for you.

You’ll probably find that “watercooler conversations” are a missing part of smooth communications that you’re used to, and you might need to encourage people to set up impromptu calls. These kinds of calls help partially with forming and maintaining social bonds, and possibly with working through a specific issue where asynchronous communication has become too frustrating.

Whiteboarding and screen sharing might be more difficult without physical whiteboards — and because you can’t simply look at someone’s screen over their shoulder anymore. Collaborative document programs like Google Docs are a great way for two or more people to look at, and work on, the same thing at the same time. You might also need higher-tech solutions, like physical-digital whiteboards (or at least a shared online space for freeform drawing and diagrams).

Especially if you have to transition suddenly from co-location to remote, there will be more aspects, often specific to your office, that you might have not have thought of before making the jump. It’s important that the whole team is prepared for a bit of “organized chaos” — they should be ready to hit the bumps, try different solutions, talk through problems, and come up with solutions. Make sure everyone is comfortable with giving and receiving feedback!

Read More: 14 Essential Work From Home Tips for a Successful Remote Experience

Learning From Others

Luckily, you’re not alone. Many companies, large and small, have started earnestly exploring remote working. Perhaps the best known ones are Gitlab and Zapier, and both have published many articles on how to make remote work work.

Although many of the ideas are relatively new and still experimental, there’s a large and fast-growing body of research, podcasts, blog posts, and books detailing the experiences of people who have discovered the benefits of remote work. Take advantage of these shared lessons to streamline your own jump to remote!

Your goal right now is not to become a fully functional remote team overnight. Your first goal is to establish an emergency work-from-home setup that sustains your productivity.

Andreas Klinger

Recently thrown into managing a remote team? Where do you start?

I’ve previously written about some of the strategies for “going remote” in the article How to Transition your Engineering Team to Remote Work, but that piece assumed you had months or even years to make the transition. With recent events, many teams have had to make those same changes on a time frame of days or hours.

If you’re suddenly thrown into remote working or if you’re suddenly managing a newly-remote team, there will be some additional challenges to overcome. Here’s a cheat sheet to help smooth some of the rough edges:

1. Have A Transparent Kick-Off Meeting With Your Team

Everyone is going to have their own interpretation of what working remotely means. It’s your job to get everyone’s views as aligned as possible. Be open and honest about the challenges (don’t claim that it’s going to be smooth sailing if that’s unrealistic). Tell your team which aspects you’re most concerned about, and listen to their concerns too.

There will be some immediate topics to address in this meeting. Let’s go through these topics.

Equipment

If your team relies on company-provided desktop machines, secondary monitors, conferencing rooms, or any other equipment that is not going to be available from a home office, you’ll need to start by figuring out how to find substitutes for this.

The office ping-pong table might not be a critical factor. The physical whiteboard with the month’s goals in carefully arranged Sticky notes? You’ll probably have to take some photos quickly on the way out.

What to do before leaving the office: get everyone to do an audit of what equipment they need to be productive. Can they take it with them? Let this happen — and give assistance with moving fees/logistics. Next, consider what information is only available physically. Can this quickly be scanned?

Read More: Top Tech Gadgets and Gifts to Give Programmers, Coders, and Developers in Your Life

Home office setups

Hopefully everyone in your team will have an internet connection at home. Hopefully it will be reliable. Hopefully they’ll have a quiet place to take calls. More likely, everyone will have some combination of these things and there will be some gaps to fill.

See if you can set up a quick process for people to expense mobile data as a fallback. It’s better for the call to cost a few dollars than to spend an hour of your team’s time going “You’re breaking up, please say that again” over and over again.

What to do on the morning of day one remote: get your team members to fill out a quick spreadsheet regarding their must-haves for remote work, e.g. stability of internet connection, suitable desk and chair, etc. Where you are able to help with any problems that need troubleshooting, help your team out. Be sure to set reasonable expectations in the circumstances.

Network access

If you’re lucky, you’re already partially set up for working from home, and everyone can connect to internal company systems via a VPN. More likely, even if this is technically possible, it doesn’t work as well as the vendor advertised.

Think about what internal resources are absolutely critical for the next few weeks and find a way to ensure at least partial access. While you definitely shouldn’t do anything to put the company’s security or people’s privacy at risk, this might be a time where you have to make difficult tradeoffs between making a resource available and keeping it secure.

It’s also likely that you’ll have to take on some more risk. While this is a challenging area, many companies are making products available for free to help with this.

What to do before leaving the office: Scanning documents will be a lot easier while you still have access to a high-capacity scanner — so get the team working on any critical documents that are only available in written form.

Next, work through your internal systems, and ensure that the right people have the right access. Also check over your policies: are they relevant? Do you need to push some urgent instructions across to your team? Do this now.

Remote working tools

There will definitely be some gaps, mainly in communication. It is likely that different people will advocate for different tools. It might be tempting to let everyone use the remote work tools that work best for them, but when you get to team-based tools, you don’t want people to pull hard in different directions.

Err on the side of using fewer tools (no, you don’t need four different project management tools just because none of them quite work perfectly in all cases), and you don’t want communication to be split over half a dozen tools and have people going “Did you send that to me on Slack or Jira? I can’t find it in my email” all day.

Pick a chat app if you don’t have one already. Pick one Kanban-like tool if you use any form of board in the office. Pick a tool for video calling (preferably the same as your chat app). Try to stick to the choices even if they aren’t perfect (none of them are) rather than trying everything.

What to do on the morning of day one remote: Confirm to your team which remote working tool to use for each type of activity to reduce confusion down the line. While everyone on the team may have different tooling preferences, ask everyone to get on board with the choices that have been made. Ensure everyone is set up with access to all the different tools — and that they know who to talk to if not.

Read More: Effective Remote Communication Through Slack Emojis

2. Settle In For The Long Haul

You’re likely to be remote for more than a few days, so keep improving your ability to work remotely as a team. Here’s how.

Counter high latency

You’ll start to notice that remote communication has high latency. If people were used to going up to their teammates’ desks for a quick question or piece of advice, that same interaction now takes hours.

Coach your team on giving as much context as front as possible, and inverting social niceties. Instead of saying “hey” in a chat and waiting for a response, and then saying “How is it going?” and waiting for a response and then “I can’t find the latest widget you pushed. Is it on the staging server already?” your team will have to learn that remote communication seems blunt at first.

A better way is to send everything at once, like, “Hey, how’s it going? I’m looking for that widget you pushed, but I can’t find it. Is it on staging?”

Avoid people being blocked

Related to the increase in latency, your team will be blocked more, waiting for responses before they can be productive. To combat this, you’ll have to:

  • Give them more trust (to take on decisions by themselves instead of waiting for approval on something).
  • Share information more widely (include people who might need information later — it’s more difficult for them to ask you for it now and get it as soon as they need it). + Default to as much transparency as possible.
  • Make sure everyone has two to three projects to work on at any time, so if they’re blocked on one they can still switch to another. Also help them prioritise by writing down more context and larger goals wherever possible and sharing as widely as possible.

Ensure time for deep work

You might think that there are fewer distractions now that people are not in hearing distance of each other, but remember that a constant stream of IM notifications, or an increase in the number of meetings might hurt your programmers’ productivity.

Consider blocking off meeting-free days, and making it clear that it’s OK for people to not respond immediately to every Slack ping. Have a clear conversation around what the expectations are for response timing in each different communication channel, and how team members can communicate their communication preferences to each other..

Account for different social dynamics

The quiet person in the office might now be the loud person on Slack. The confident person in standups might be the one who finds it harder to adjust to making themself heard remotely. Make sure that everyone is comfortable and has different ways of reaching out.

If you have a video calling system, see if it has a “Raise hand” function so that people can indicate that they want to talk without finding it difficult to find the right place to “jump in” (and don’t forget to ask everyone to turn their camera on). Your role as manager is to facilitate these conversations and meetings — ensure that everyone has a chance to be heard.

Read More: How Data Science Managers Can Effectively Lead the Team to Production

3. Adapt, Adapt, Adapt

No matter how much you prepare, things will not go as you expect. And advice that seems sound on paper might not apply to your case. Experiment as quickly as possible in the start, find what seems to be working, and double down on that. If something’s not working, don’t be afraid to admit it, discard it, and move on. Continue to encourage honesty and transparency about all challenges, as everyone will be facing their own.

Does your team have any tips for making the transition to a remote engineering team? Let us know in the comments below!

You can also try Arc, your shortcut to the world’s best remote talent:

⚡️ Access 450,000 top developers, designers, and marketers
⚡️ Vetted and ready to interview
⚡️ Freelance or full-time

Try Arc and hire top talent now →

Written by
Arc Team
Join the discussion