Build “performant anywhere”​ teams

Over the past 10 years I’ve become increasingly interested in remote working, both the benefits and drawbacks.

I’ve worked fully remotely as a developer for companies like Upwork with hundreds of remote engineers, through to managing mixed teams of co-located and remote developers at SMEs.

I know first hand the benefits of remote working, particularly for software development teams in SMEs. Developing great code requires periods of intense focus which can be difficult to achieve in the open plan offices found in many small or growing businesses. Remote working can help, and as a manager, I’ve achieved measurable code production improvements by introducing it.

At the same time fully remote developers are more isolated, which can lead to a variety of issues (see below).

In this post, I want to explore effective remote working for technology teams in SMEs (and specifically not companies like Google with vast resources).

Performance & Transparency

We’re in a new world when it comes to where people work. Web based tools allow people to work anywhere, we have high quality 4G mobile networks and low cost airlines if we must travel.

Improved connectivity means that, as employers, we’re no longer stuck recruiting from the pool of people who live within travel distance of the office. We can work with the best people we can find (I prefer +- 4 hours unless I need a specific location for another reason). That’s a huge talent pool.

As a team manager supporting a global customer base, I recognise that diversity improves outcomes, and global developer distribution enables better customer support and 24x7 coverage. If I’m patient, I can also find great people, for significantly lower cost.

These benefits offer a competitive advantage assuming performance is not degraded.

Before we progress, I want to highlight a distinction that I make in this article. When I talk about WFH (work from home), I mean office based staff who can work remotely (for a variety of reasons). When I refer to a remote worker, I’m talking about fully remote staff who may come to the office occasionally.

Let’s start with WFH

A common scenario is that management allow office based staff to “work from home” (WFH), often for work/life flexibility. The idea being that people can WFH if they have a delivery or doctor’s appointment. A common process for managing this is that people post “WFH today” in the company chat channel.

This is a high risk approach.

Lifestyle benefits are certainly part of the remote working mix. They allow companies to offer flexibility to attract the best employees, but they shouldn’t be the driving force behind adopting the practice.

If you have good staff and a good culture, then when people need flexibility they should know they can simply ask for it. Asking to be allowed to work from home for a specific reason is completely different to being able to WFH in general. The problem with the latter is that it lacks transparency and can degrade rapidly until management kill the endeavour.

Consider also, that allowing office staff to WFH will normally have no cost advantage (i.e. you will need to pay an office based salary and desk space).

A better reason to allow office based employees to WFH is performance improvement. Once we start thinking about remote work in terms of performance and output, then many obvious questions emerge.

For example,

1. How do we know performance is improved?
2. Will outcomes improve for all roles or teams?
3. What sort of tasks benefit from being done remotely?
4. How do we measure success?
5. How do we capture & communicate performance data related to WFH?

Through trying to answer these questions I’ve realised there are three distinct aspects to successful WFH initiatives:

1. performance measurement
2. communication & transparency
3. top level management buy-in.

If any one of these things is lacking, introducing WFH has a high risk of failure.

What about fully remote workers?

Here there should be a cost or skill advantage (preferably both). Location and languages may also be a factor, for example if you have an important client in some other part of the world and wish to have local support.

Time zone is important. If you have staff on very different time zones (greater than 4 hours difference), then some rules apply.

1. Make sure your sprint rituals are well run. That is, you should be holding effective grooming using personas, the PO and dev team should be comfortable discussing requirements in your ticket system, and pull requests must be well managed. Clearly you want this anyway, however timezone difference increase the feedback loop for questions (potentially to the next working day). Running tight sprints reduces the number of questions that need to be asked.
2. Staff separated by timezone should have a high level in the common language.
3. Team managers must be prepared to travel to the remote team regularly to ensure consistent practices and to strengthen bonds.
4. I don’t recommend recruiting junior staff past +- 3 hrs of difference (unless they’re happy to sync their work hours with the main team).
5. No matter what timezone staff are in, it should be a requirement that there is at least 4 hours of overlap per day.

Performant anywhere

If we’re introducing WFH and recruiting remote developers to improve performance then a clear implication is that teams must be “performant anywhere”. That is, people should perform at their best, no matter where in the world they find themselves, and we should know that they’re performing.

Once this is achieved, where we work becomes a question of “where can we work best for a given problem?” (and let’s be clear, some situations are better face to face. I personally don’t love working with fully remote designers. I’m very happy if they’re often remote, but the collaborative sessions are better in person).

The first problem to resolve is how to ensure that a team is performant regardless of location.

Performance Measurement

There’s plenty of literature on improving team performance and remote teams benefit from the same strategies. We still focus on output (i.e. is what they produce great), improving developer communication, technical skills, engagement levels, and ensuring problem ownership — all normal stuff which relates to both remote and co-located workers.

When people are working remotely our window into their work day is provided by the data we can analyse (e.g. via Github, Jira, monitoring), and communications (e.g. their chat, and regular 1:1s). This provides a wealth of management information if it’s used effectively.

Once we have effective communications coupled with data based performance management, we can largely ignore work location and either embrace WFH or recruit fully remote staff where optimal.

Doing this changes the conversation. For office staff, it’s no longer “WFH today” but “Now the design is done, I need to focus on coding and I’ll be working from home for the next 3 days”. For remote staff, it’s “I’m coming into the office Monday to work with the designer on the UX for…)”.

That is, staff self organise location to improve outcomes, and it becomes a cultural norm that doesn’t cause worry.

For example, from the data I collect I know that developer keyboard activity increases by 10–15% when they’re working away from the office and there’s an equivalent increase in velocity. Does that mean quality is improved? Not necessarily, however, when used with other data and from chats in 1:1s with developers, I know that they suffer less distractions, can get into the zone and code faster. Therefore, my developers WFH to better focus, and I have data that gives the business confidence that remote work practices are improving outcomes.

Bear in mind I’m talking about smaller companies that may not have the budget to build amazing offices with quiet zones and calming, sound deadening, recycled cork walls. In these companies strategies such as this can really help.

Performance measurement requires data, and to get that I use monitoring tools (you can’t improve something without measurement), but monitoring staff can cause concern. Not only can staff find it invasive, current monitoring services are not focused on developer performance so much as developer tracking (Hubstaff and Upwork both provide tracking tools, RescueTime provides useful performance data for individuals but I don’t find it particularly useful for teams).

Let’s be clear, typical metrics such as hours worked, keyboard activity, commits, velocity, lines of code are individually not great. For example, there is no correlation between activity and quality. They become useful in aggregate, when incorporated into retrospectives and 1:1s with a view to improving performance.

This is an agile approach, we use data captured through working with our systems, coupled with regular introspection to make small adjustments that improve outcomes. Doing this we can see that we get longer working hours and better activity for certain tasks when working away from the office.

To make staff more comfortable I always run the same monitoring software myself and make the data available to my team members. I review data before our monthly 1:1s and use it to try and improve performance, output and happiness.

I’ve now introduced developer monitoring at two companies. I’ve always been upfront about my reasons and that I know people may be uncomfortable. In both cases, many people have come to regard the data as useful (particularly my direct reports).

What should be monitored and reported on?

In my current role there is a mix of permanent and contract staff. Therefore we track:

1. Hours (contract staff use these to get paid)
2. Velocity
3. Keyboard activity
4. Story points by developer
5. Pull request resolution time
6. Contribution by developer

We’re currently pre-alpha, but in the future we will track:

1. Production bugs
2. Production downtime
3. Support tickets

We then work to make this data available on a company wide dashboard as part of our drive for greater transparency (more on this in another post).

Communication & Transparency

Allowing team members to work anywhere will have profound cultural implications. For one thing, others can perceive a team as lazy, wandering into work as they please, eroding trust.

The solution to this is transparent communication.

Capturing data allows us to determine when working remotely is more productive, for specific types of work. By communicating the data, we can also provide visibility of performance to the wider business, building confidence that teams are managed & performing.

Producing data is relatively easy, having people absorb & understand it can be difficult. The data needs to be published in a form that can be easily digested by others, and in addition to a dashboard a variety of other communication formats may be worth considering. For example, it can be useful for teams to periodically undertake short (90 second) demos of their work to a wide audience.

Transparency about location on a day-to-day basis is also essential. People must say when they’re working out of office and how they can be contacted. Depending on your specific culture, you may wish remote staff to post when they’re going for lunch or finishing for the day. Small strategies like this help ensure visibility across the enterprise.

As I’ve touched on above, scrum team communication needs constant attention. We’re striving for focused communications not waffle. We use the data we capture to provide that focus.

This transparent communications of data and output to the wider business has a profound and positive impact on the confidence of scrum teams.

Management buy-in

There’s no point in any of the above if there isn’t buy in from the CEO down, because once you start focusing on building performant anywhere teams, you’ll find that some staff often perform better out of the office. This is particularly true for developers and designers.

A well implemented remote work strategy will give management the necessary data to have confidence work is being done.

Implications and things to consider

As your performant anywhere culture emerges other changes will become obvious, like the need for fewer desks and more meeting rooms (for when the troops do need to gather).

Recruitment and on-boarding processes should change to work better for remote staff.

My team has found that remote paired programming has real benefit over co-located pairing. Not only is the developer experience improved (we find a better separation between driver and navigator and improved focus) but it’s also an effective approach for on-boarding and interviews.

Meetings

Remote meetings definitely need attention. People have to turn up on time because invariably the remote team members do. If office based staff wander in 5 mins late, it’s frustrating for those waiting. Meeting technology also needs to work and I’ve mainly used Hangouts and Zoom (I find Skype painful for multiple people).

Whatever you use, it’s important that these tools are integrated with your calendar app so people can easily connect to the meeting when it happens.

Mixed meetings where some people are remote and others are gathered around a computer are the most difficult, primarily because the sound is bad from the co-located staff. If this is a common scenario, invest in some wireless mics that can be passed around.

Serendipity & Isolation

Remote people lose the benefit of serendipity, those meetings that occur in corridors or over lunch that provide information about a huge array of company happenings (including the ability to gauge their relative contribution).

To help combat this, fully remote staff should travel to their main office periodically. If the company has no office, people must physically get together at least once a year but preferably twice. There should be regular social video hookups (I’d recommend once per week), where people can chat about what they’re working on.

Isolation can be difficult particularly if a remote worker is having difficulties. Their remoteness can make them feel vulnerable and exacerbate problems they’re having. For this reason 1:1s should be run monthly and include a review of their performance and the teams. Managers must look for signs that developers are suffering isolation stress and where this occurs, get them working in the office (or remotely paired) a couple of days a week or perhaps for a month full time, until the stress resolves.

Summary

There are many articles talking about how a “going remote” experiment failed and was eventually scrapped.

In my experience the issue isn’t working from home or remote working, it’s in implementing a change that has significant cultural impact without sufficient thought.

If instead of simply introducing WFH we build the processes, monitoring and transparency to ensure teams are performant anywhere, we can use location to broaden resource pool, lower cost, and gain competitive advantage.

I’m very interested in people’s thoughts on this subject so please let me know of your remote successes and failures in the comments below, or connect with me if you wish to discuss directly. I’d finally like to thank Sarah Gargett for all her help with editing.