Successfully running a remote first software team

In this post, we are going to explore what it’s like to operate a software team that is “remote first” the pros and cons, some of the tricks and tools that I have found to be effective while managing the (remote first) software engineering team at CanYa.

So let’s set the scene, firstly CanYa ‘s engineering team has been as large as eight engineers, all working on our various products, but the bulk of our effort is focused on our freelance platform CanWork. Almost all of the team is located in different countries and time zones.

Each team member has various strengths, weaknesses and preferences as you might expect. And a key part of my role as Principal Software Engineer is to balance getting the best result from each individual and the collective team as a whole.

Not all organisations would necessarily agree on what the “best result” is exactly, or how the various aspects might be weighted. At CanYa, it’s a somewhat even balance of:

Quality software (architecture and code)

Productivity

Work/life balance

Satisfaction from crafting software and seeing results

Creative thought and innovation

Ongoing maintenance and upgrades of skills

But the fact our team is remote has certainly presented some interesting challenges, hopefully, this post will help you short cut some of those challenges, and get to the business of building great software!

Remote first, what is it and why?

Over the past decade or so we have seen more and more professionals “working from home” and recently here in Australia where I am based, we have seen large enterprises such as Telstra (the main telco) introduce concepts like FWOW (future ways of working) which is essentially the reduction in offices and desks and the increase in staff working from home.

While I am pleased to see a trend in this direction, that is not what remote first means.

Remote first means the majority of the team or indeed all team members are remotely located.

Here are some key differences:

All meetings take place over video conferencing as opposed to a meeting room with the odd person dialling in

There are no emails saying “I’m working from home today” you always work from home

Everyone is in the same boat, so your remoteness doesn’t make you feel like an outsider

Before we go into the challenges this model presents, let's take a look at the reasons why you might consider a remote first team:

You have access to the global talent pool

Some locations have very low living costs and are therefore able to offer very competitive salaries

You don’t have to rent a large office with desks, internet, coffee making facilities for everyone

You don’t need to supply equipment

You may be able to offer your clients or products 24/7 support because of your staff’s timezone diversity

Staff can maintain a superior work/life/ family balance

Your carbon footprint is reduced because staff do not waste precious resources travelling

The ability for staff to obtain a state of “deep focus” is heightened dramatically

The day can be arranged in a traditional or more dynamic structure according to everyone's needs

Remote first, what about the challenges?

While the benefits are numerous, there are also a number of aspects that make managing and indeed working within a remote team challenging. But certainly not insurmountable.

How do we communicate with each other?

These days, there are many tools that assist with communication. Perhaps even too many.

Here are the communication tools we use:

Messaging (Group, direct and topical)

Slack. This is a great tool that really needs very little introduction. And some of its automation capabilities that we will discuss later, are what really sets it apart from many alternatives.

Of course, we also use email. In our case, it’s very convenient because we use G Suite which gives us a business version of Gmail & Google Calendar

Video Conferencing

Because we already have a G Suitesubscription, we get access to "Meet" which is excellent video conferencing software. And because Gmail, Meet and Google Calendar are all integrated, setting a remote meeting is very easy and timezone confusion is avoided.

Voice Call

Most staff who need to have a quick verbal conversation simply call each other on WhatsApp. It costs nothing and is easy. In our case, everyone has WhatsApp on their phones anyway.

Are your staff actually doing productive work?

This one is my favourite. As an advocate for remote first, and working from home scenarios, I am asked this question a lot.

In software, we generally work using an Agile methodology. But regardless of your approach, staff productivity has always been something that needs close attention.

My answer to this question is simply this: You use the same methods of measuring staff performance as you do with co-located teams. In other words, if you do not know what your staff are doing, and whether they are being productive or not then you have much bigger problems.

Having worked for many years in an office I have seen plenty of staff that have the “you just need to turn up” attitude. And sadly, a lot of organisations accept this. Being present and being productive are vastly different and unrelated items. I will never forget one organisation I worked at, we had a guy that used to regularly sleep at his desk, with his head in an upright position directed at his monitor. A real talent no doubt, but certainly not productive and a terrible example, not to mention unfair to his diligent coworkers.

The key here is measuring results. Which means having an upfront expectation of what those expected results actually are.

You can review committed source code, but this is only one aspect of a software engineers day. If as a manager you are engaged with your team, you will very quickly understand who is being productive, and who is not. From there I consider it my job to understand why, and remove any obstacles that may be causing a loss in productivity.

A frequently used method of tracking what everyone is doing is the “the daily standup”

Agile Ceremonies - The daily standup

Teams that work using an agile methodology typically have a number of regular ceremonies, including “the daily standup”. Everyone in the team (very briefly) speaks about what they did yesterday, what they are doing today and if they are facing any blocking issues.

I won’t go into any discussion about the strengths and weaknesses of these “stand-ups”, but the obvious question instantly arises: what if my team are remote, and are in different timezones?

This was something that was initially a stumbling block for us. At first, we tried a video conference every day. But with the usual human movements of staff, I found that attendance wasn’t great. And some staff with enough time differences were still in their Sunday evening while in Melbourne, it was Monday morning.

We also have some staff who are very talented engineers, but not as comfortable with English or speaking in a group format.

After a few unsuccessful attempts at adjusting the time, I ultimately had to find an alternative solution. And what works (very well) for us now is the following format:

A standup over slack on Mondays, Wednesdays and Fridays using a fantastic tool called standuply. The great thing about this tool is that works as a bot within Slack.

Standuply will prompt you and ask for your standup responses (what you did yesterday, what you are doing today, any issues), and once it has collected everyone’s stand up details, it posts a report into a Slack channel of your choosing. Very awesome.

To cater to the timezone differences, Standuply can be set run at a time that covers all staff, and wait for a long enough period to ensure everyone gets a chance to respond. In our case, we have a 3-hour window to complete our standup.

On Tuesday’s and Thursday’s, we run our video conferencing meetings, which reduces the burden and therefore increases attendance. I also find these meetings have a higher value. It allows the engineers to discuss things in greater technical detail and recognise opportunities to collaborate with each other. We also refer back to our sprint goals and make sure we are on track.

Workshopping

One of my favourite activities as a software engineer is workshopping a concept or architecture on a whiteboard. A recent addition to the G Suite family of products is Jamboard. It’s a great way for everyone to basically share an electronic whiteboard and nut out the next piece of the decentralised architecture we are working on.

Pair Programming & Code Collaboration

One very important aspect of being a senior engineer is mentoring. And of course, no one person can know everything! So we all do coding sessions together and get each other to help when we hit problems.

The awesome Visual Studio Codehas a live share feature that really makes this a breeze. In fact, trying to pair program in person can be a bit awkward, both of you cramped in together trying to share a keyboard and mouse on an operating system and configuration you are probably not familiar with.

The great thing about live share is that multiple people can see and edit the same code in the shared project. And VS Code’s integrated terminal is also accessible to those you are sharing with. From a pure software engineering collaboration point of view, this is the single greatest feature to advance pair programming I have ever seen and is arguably better in a remote setting than being co-located with your peer.

What else?

At the end of the day we are still human, and there is, of course, no substitute for one on one interaction. What I have found is that once you have had an opportunity to work together and build a relationship with someone in person, the remote element becomes easy.

To that end, at CanYa we recently bought our team together for a ten-day Developer Summit, and the results were fantastic. And now that the team have had that chance to understand each other better and form a closer bond, we are getting even better collaboration results.

So if your team is just being formed, I highly recommend this type of activity.

Conclusion

As I hope you can see, with a little bit of creative problem solving and some cool tech, running a remote first team can actually be very effective. I hope my experiences are able to help you on your journey to building an awesome team and the products that follow, remote first.

Promo Codes

If you are not using G Suite and would like to, you can save yourself some money with these promo codes:

G Suite Basic Plan: F3VNFA663UARDE7

G Suite Business Plan: M4Y7WC4XMMLEWPH
Information source:
https://www.publish0x.com/software-of-all-things/successfully-running-remote-first-software-team-xolev