Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Remote vs. in-office software teams: Which is better?

Dave Fecak Principal, Fecak Inc.
Working on a porch

The increased acceptance of remote versus co-located teams and the availability of effective tools that enable it are among the most significant trends affecting technology industry employment today. The effect of these changes ranges from changes to the lifestyles of individual workers to potential disruption in the global economy.

As with most things in business, productivity and cost are the dominant factors when choosing between remote and co-located workplaces. But there's no one answer—what works for some firms doesn't work for others. 

Which is the better fit for your teams: fully or partially remote teams? Before delving into the research regarding remote vs. co-located decision, here's a review of the issues more broadly, as well as a look at how peers in the industry are dealing with the modern workplace.

Collaboration versus distraction

As companies transitioned from closed-door offices to open workspaces designed to foster collaboration (with the added benefit of being cheaper), it soon became evident that some types of work were less conducive to open office environments. While an office door can be viewed as a barrier to communication (or an aid in goofing off), they are also a reliable defense against distraction from noise and co-worker interruptions. 

Today’s discussions regarding the perceived value of face-to-face collaboration are typically met with rebuttals related to open-office environments, and the tradeoffs between collaboration and distraction.

Recently, Yahoo and Reddit made headlines for banning remote work, but the overall movement towards remote work has remained largely unaffected, and both firms were careful not to repudiate the practice when announcing the policy change.

While Yahoo's leaked announcement cited a need for better communication, stating that "some of the best decisions and insights come from hallway and cafeteria discussions," Reddit's then CEO took to Quora to explain that remote didn't work simply because "there were too many times when we just needed to be able to walk over and tap someone on the shoulder and discuss a complex issue in-depth, right away."

Neither announcement cited any data or research, and some people speculated that the decisions by both companies may have been more about layoffs than a desire to co-locate team members.

Of course, comparing the productivity of remote and co-located teams as a yes-or-no proposition ignores many other contributing factors. Where the work is done matters little if your development team is not equipped with solid requirements, proper tools, sound practices, and skilled workers. 

Remote vs. co-location: The data

Remote work is still an emerging field of study, and data on the effectiveness of distributed teams is largely anecdotal. But there's a substantial amount of research on open offices, which is the usual alternative to working remotely. Studies on open offices have ranged from the health and productivity impact of noise, to how noise may impair arithmetic ability, to basic employee satisfaction. However, those studies don't directly relate to software developers and other professionals in the software development lifecycle.

In his 2013 blog post, Programmer Interrupted, then Georgia Tech PhD candidate Chris Parnin cited a host of studies on how interrupted tasks lead to poor outcomes. After studying data from 10,000 recorded programming sessions, Parnin concluded that a programmer "takes between 10-15 minutes to start editing code after resuming work from an interruption."

"[And they are] likely to get just one uninterrupted 2-hour session in a day," he noted. Coders need to stay focused. But when you combine these two results, it's easy to see that the number of productive man-hours lost to largely avoidable distractions imposes a significant cost on a software engineer's productivity.

The irony of working remotely

In their book, “REMOTE: Office Not Required,” Basecamp founders Jason Fried and David Heinemeier Hansson evangelize the merits of remote work and offer actionable advice to managers considering a change. The authors practice what they preach, having scaled Basecamp's remote workforce to more than 50 employees since founding the company in 1999. The book identifies risks that managers of co-located teams would be unlikely to consider.

Conventional wisdom suggests that remote workers will work less, due to their freedom from oversight and monitoring, but REMOTE warns managers that the bigger concern should be the inability to recognize burnout and overworking when the employee is not on-site. Fried calls this "the great irony of allowing passionate people to work from home". The authors suggest that managers set reasonable expectations for hours while asking employees to measure their productivity by asking themselves, "Have I done a good day's work?" Some studies suggest that workers are actually more productive when unsupervised.

Considerations regarding the relative productivity of remote developers often center around the effective use of collaboration tools and development methodologies, but there could be more obvious factors at play. Remote work is not always without distraction.

Commuting hours reclaimed  

Michael Swierczek, a remote software developer for Diio, says working from home “trades the distraction of being at home for the distraction of noise or intrusions at an office, and once you consider giving up your commute it's well worth it.”

Professionals living in congested regions where long commutes are common may be willing to extend their work hours in exchange for the greater convenience of working at home. In much of the country, a forty hour office-based work week may require being away from home for fifty or more hours. Removing that extra time burden could result in more productive hours.

Companies that evangelize remote work often promote the practice as a way to boost employee morale. "The Remote Manifesto," published by GitLab, lists eight principles for working remotely, starting with ,"Working remotely allows you to be there for the ones you love, and be more available for them."

Drew Blessing is a GitLab engineer living in Nebraska who would face a four-hour round-trip drive to big cities where he might have the best chance of finding work. He says he appreciates the company's commitment to its employees. "GitLab encourages work/life balance and family", Blessing says. "Most people work around 40 hours and we all try to keep a good balance." 

Remote productivity: Individuals vs. teams

ThoughtWorks’ Martin Fowler adds a wealth of anecdotal evidence to the debate. He believes that individuals are more productive in a co-located environment, but remote teams are often more productive than co-located teams. This seems counterintuitive, but Fowler argues that remote team have the advantage of hiring without geographic boundaries, and that enables employers to assemble world-class groups.

In theory, a team consisting of the best local talent available can’t compete when the filter of location is removed, unless that local talent has better chemistry. But logically, finding candidates more likely to have good chemistry with the team is also easier when you widen the net.

Zaarly, a Kansas City firm that built an online marketplace that connects local small businesses to customers, offers employees a "work from anywhere at any time" policy that values production over hours logged or attendance. However, the company's handbook also avows the importance of co-worker communication, and goes so far as to rank the company's preferred methods—with face-to-face communication listed highest, and email dead last.

Zaarly puts its money where its mouth is, adding they are "very happy to pay for plane tickets." Their attitude toward remote work is encapsulated in the handbook's final bullet point, which states: "Work happens anywhere, collaboration happens here, in the office we call home." 

There's an art to working from home

David Tate, a software consultant and writer living outside of Atlanta, is developing a personal guide for remote workers, The Art of Working From Home, that explains how to remain effective and overcome the unique challenges that accompany remote work.

Among the potential obstacles Tate identifies are social isolation, decreased collaboration, and a potential invisibility to co-workers and management that can negatively affect promotions and professional networking opportunities.

In-person conversations can "cover up many communication problems," Tate says. "A remote team has to work to establish clear, written methods of communication to prevent people drifting to their own misinterpretations of what should be done."

Stack Exchange (the people behind Stack Overflow) offers private offices to its co-located developers, and advocates and evangelizes remote work with a somewhat unique hybrid model that would likely be considered the best of both worlds, based on most programmer sentiments.

The new reality: Remote-first

The voices against open offices today are mostly drowning out those in favor, and the growing number of remote jobs has created a new remote jobs economy that consists of websites and marketplaces that connect employers to people in slippers and sweatpants.

The transparency surrounding the practices and policies of many remote-first employers now serves as a template by which established firms can transition to and startups can adopt. Hybrid office spaces that combine private areas for tasks that require concentration with airy zones for collaboration, are in vogue, and the digital nomad lifestyle has taken remote work to a new level.

What's next? What should your organization do? Well, the answer differs for every company, but these stories and trends should give you a framework to start thinking about the question.  The answer often isn't binary—remote-only or co-located only—but somewhere in between. 

Are your development teams mainly remote or co-located? What works for your organization? Share your experiences in the comments section below.

Keep learning

Read more articles about: App Dev & TestingApp Dev