The pandemic in 2020 changed the world of software development forever, with teams forced to work remotely.

At LifeWorks, when the pandemic hit we were in the middle of delivering a large and complex multi-team architecture change which was closely tied to a client obligation. The financial implications of missing our deadline were too high. We needed to make remote working work.

More recently teams have been moving back toward office working - usually in a hybrid situation. There is certainly something for face-to-face time and getting to know your team, and in the early stages of a startup where time is critical being able to make quick decisions.

The Remote-First Mindset

Having a large team working remotely means you need to pay far closer attention to the ways of working and the culture of the team. It's very easy for someone to feel disconnected from the business decisions that may affect them.

Documentation is king

I'm a big evangelist for having great documentation. New starters should feel supported from the start, and everyone should know where or who to go to if they need help or support. Taking extra time to make sure your systems are explained can help save a lot of time later on.

• Keep a decision log which documents the choices that have been made whilst building your system. This can help future team mates understand the why a architectural or technical choice was made, and it also gives an opportunity to document what the potential technical debt issues would be with such a choice.
• Ensure your onboarding documentation is clear and guides team mates on how to set up their systems to get up and running quickly.
• Keep an easy to access document on table stakes knowledge - such as how your servers are configured, what the responsibilities are of each service or repository and keep high level architecture diagrams and technical roadmap decisions.
• Keep a glossary of terms that are internal to your business or specialist knowledge for your subject domain.

Async

Asynchronous communication is where one team member asks for, or provides some information, and then there is a time lag before the recipients take in the information and offer their responses. Usual examples of this are Slack or email.

As a designer, developer or other do-er there are lots of benefits to this approach - you can plan your day to ensure you have good chunks of focus time and pick up correspondence at set intervals.

Asynchronous video is also another great tool for communicating more effectively with your team. Sometimes our messages get misunderstood in text, but we can clearly convey what we want and map our words to pictures with a video. Your team mates can find a time that works well for them to watch it.

In the development world, we also found having an agreed time where pull requests would be reviewed helped us ensure work did not get blocked and set expectations around how quickly code changes would happen.

Managing Time Zones

Timezones (and by extension country-specific bank holidays) can add an extra complication to the way you manage remote teams.

At LifeWorks, most of my 100+ engineering team were located in the UK or Europe and we worked in way where hours were adjusted around a set of base times (between 10am - 4pm UTC). We agreed that during the base times we would run standups and any important meetings so everyone could attend.

For managers and developers that are outside of Europe, there were additional challenges - async communication massively helped here and aligning check-in meetings to a time where you both were working was important. Having team members working completely different hours can actually be really useful if you have a time-sensitive issue as you can have a team working on the issue round the clock to help with a resolution, and this certainly helped with some of our incident availability issues. For example, if an issue occurred late in the day in the UK, our US, Canadian and Australian counterparts could continue the investigation with the UK/Europe team remaining on-call.

Trust

A remote-first culture requires a level of trust among employees. You have to trust your team to be able to plan out their time and be accountable for their outputs. For us, this meant weekly sprint commitments that engineers owned completely. We measured progress by completed work, not hours logged. When someone consistently under-delivered, we had specific conversations about planning accuracy and communicating issues early rather than questioning their work ethic. As a leader, you can guide and set expectations of what this should be and you need to be transparent and prompt with letting them know when your expectations are not being met.

Keeping Connected

It seems like a really trivial and simple thing, but at both LifeWorks and Bloom I set a tradition of saying "good morning" on an Engineering Slack channel when we first logged on for the day. It meant that every day, people had at least some connection with their team and kept small talk alive. It helped to remove a sense of loneliness or isolation.

I also ran a couple of sessions to help with team building - we used a tool called Brightful to organise fortnightly Friday fun, and I had a drop-in "ask me anything" session where people could drop in and chat about questions or problems they were having.

1-1s

I've written about 1-1s before so I won't go in to much detail here - other than to say they are critical in a remote-first environment.

Outsourcing

With outsourcing, the biggest mistake I see is treating offshore teams like an external vendor instead of integral team members. At LifeWorks, we used a number of outsourcing partners to help bolster our team and deliver our roadmap. For me personally, I wanted to ensure that outsourced developers were treated like full-time employees. We worked with our partners to set expectations of the skills and experience we were looking for and we interviewed our outsourced developers with the same standards we used for internal hires. As we'd hired competent outsourced developers, we ensured they were also part of our decision making processes and felt included in our sprint rituals. Working with a team that is fully remote actually made this easier as with everyone on a video call the playing field is even.

Conclusion

What started as a pandemic necessity became a competitive advantage - and these principles helped us not just survive that deadline, but grow and scale successfully through acquisition. There's a lot to talk about with remote-first working but this hopefully gives you an idea of how you can make it successful.