Helping our developers stay productive while working remotely

Since Microsoft made the move to remote work two weeks ago, we’re discovering so much as a company. Last week, my colleague on our internal IT team, Nathalie D’Hers, shared nine ways her team enables tens of thousands of employees to work remotely. In her post, D’Hers mentions the unique challenges that development teams face when moving to remote work. This piqued my interest in what engineering teams at Microsoft are doing to enable remote work for devs, so I asked Aleš Holeček, Corporate Vice President of the Office Experience Organization Engineering team, to share his top tips and insights. I think you’ll find them as interesting and helpful as I did. Take it away, Aleš.

Keeping our team productive is key to making our services work for our customers. As so much work goes online, we’re mobilizing to continue to be able to respond quickly and effectively. Here, I’ll share some of the ways we’re working to make this as seamless as possible, including early learnings on how the switch to remote work has impacted our productivity so far.

The impact of remote work on people

Encouraging team culture

Software development is a team sport, in which engineers need to work together to solve complex problems. At Microsoft, that usually means working together in collaborative environments. When we work remotely, we lose the ability to pop over to someone’s desk, walk the halls, and gather for group lunches. This makes it all too easy for team members to become disconnected. To retain a collaborative team environment, we have established team practices, including:

• A culture channel in Microsoft Teams to use for virtual “water cooler” hangouts.
• Virtual lunches and coffee breaks.
• Outdoor walks during check-in calls with teammates.
• A conference call bingo board, with things like “dog barking,” “kid wanders in,” etc.

Staying informed

Keeping employees informed is a key aspect of remote work. Our team created an online list of helpful information—from remote-work pointers and company-wide guidance to current hardware and tips for self-hosting. It’s updated daily, if not hourly, with the latest information as we get it.

Resources

There are many great articles out there that can help your people work remotely. We recommend this post from Scott Hanselman in our Developer Division. He’s worked remotely for the last 13 years and just dusted off his best practices to share with people making the shift. (Scott also kicked off a great Twitter thread showcasing home-office setups for developers.)

Remote-friendly tools and processes

Our work no longer stops while we’re at home. Here are a few ways we optimize our engineers for remote work.

Tech setup

We start with their tech setup, making sure they have the right hardware and network connections. Most of our engineers already have a Microsoft-provided laptop to enable them to perform their duties remotely. We’ve also encouraged employees to bring monitors, hardware, and peripherals to mimic their work configurations in the office. This is especially important for developers who use two- or three-monitor configurations.

Last week, we shared The top 9 ways Microsoft IT is enabling remote work, which covers IT scenarios in depth. Here are three key remote-access learnings for development teams.

1. Developers who work exclusively on desktops should be given corporate laptops with a Windows Virtual Desktop solution that allows them to remote into their dev environment.
2. If that’s not feasible, then we recommend setting up a Hyper-V virtual machine (VM) on their home machine and having the VM managed for direct VPN and remote work.
3. For those who don’t need direct access to remote resources, or have the hardware to support VMs, cloud services can help. Visual Studio Online is a service that creates cloud-hosted dev environments from any hosted Git repo. You can connect to these environments directly from Visual Studio Code, which provides an experience that looks and feels local. For tasks that require access to specialized hardware, devs can link their existing machine to Visual Studio Online.

Shipping

Next, we need to maintain our well-established rhythms for shipping software. Our engineering teams rely on regular team stand-up and ship-room meetings to keep everyone moving forward. These meetings can’t—and don’t—stop. Instead, we’ve moved them exclusively to Microsoft Teams. In addition to being the hub for remote meetings, Teams has apps specific to software development, such as Azure Boards for planning and tracking work, and Microsoft Whiteboard, which lets meeting participants sketch out flows and map ideas. These tools help bring our team members together as though they were in the office.

Peer learning

Working remotely can be a challenge for developers who participate in peer reviews or pair programming, where they would normally sit side by side and learn from one another. Our developers use Visual Studio Live Share for joint debugging sessions and peer learning. Live Share allows developers to work both together and independently, and feels a lot like in-person collaboration.

Hiring

Hiring is another essential process that can’t be put on hold while we work remotely. We’ve found it helpful to use Live Share for technical interviews, allowing us to engage and communicate with candidates using tools they’re already comfortable with.

Developers collaborating in real time, between Visual Studio and Visual Studio Code.

What we’ve learned so far

Like you, we’re learning as we go. However, we are heartened by an early look at the numbers relating to engineering productivity during this period of remote-first work. Across Microsoft, we are tracking the number of times engineers submitted changes to the computer code the company uses—a proxy for productivity. The chart below shows completed pull requests by week, starting at the beginning of the year. Measuring completed pull requests is a good indicator of whether we’re maintaining our developer velocity:

Trend of completed pull requests company-wide.

Across work items, commits, and pull requests, we’re not seeing any declines. If anything has changed, it’s a shift in activity during the day, with activity starting earlier and finishing later, and with lower “peaks” in the middle of the day. The chart below shows builds by engineer per hour in Office Engineering:

Builds per engineer per hour—Office Engineering organization.

Enabling a team to work remotely is an ongoing challenge, and we understand that this challenge is different for every organization. We have found that maintaining a collaborative and productive culture, empowering devs with remote-friendly tools, and watching the numbers to ensure we stay productive are all effective ways to help our engineering team move to remote work. As more organizations transition to remote work, we will keep sharing best practices, success stories, and tips to help make it a seamless, successful experience for everyone.