GitPrime elevates engineering leadership with objective data. In this interview series, Engineering Leaders talk about how to build high performing teams.

When your organization has a split between in-house and remote employees, it’s no secret who the red-headed stepchildren are. They’re the ones who can’t grab drinks with you on Friday, or bring doughnuts on Monday.

But your remote workforce can actually improve your org the whole way through if you learn to recognize what it enables differently than your on-site teams.

As a prime example, GitHub is famous for hiring remote employees. As well it should be — over 60 percent of its workforce is outside of San Francisco HQ.

“Remote work is new to me,” Joel Califa, Senior Product Designer at GitHub, says. “And it’s pretty incredible. But it’s made me realize how important it is to have the right people and right systems in place—especially when you or someone you work with have a completely different schedule.”

Califa knows that trickiness as well as anyone. He’s currently traveling to Israel, with a ten-hour time difference from the West Coast. That’s why we talked with him about how a conscientiously constructed remote workforce can send benefits rippling throughout your company.

Source: diversity.github.com

Develop empathy; build trust

With any remote workforce—particularly one spread across numerous time zones—your work will become asynchronous. There’s no good way to avoid it when you have people working ten hours apart, on their own schedules to boot. And that disconnect can really flare up when you need to rely on your teammates.

“If you’re blocked, you’ll sometimes have to wait for twenty-four hours. You don’t always have that ability to say, ‘let’s solve this thing right now,’” Califa says.

When Califa gets blocked, he could sit on his thumbs until a teammate rescues him. But that’s not how he operates. Instead of waiting, he jumps in to jury rig a solution.

“Knowing how to code really helps,” he says. “I’ve learned just enough GraphQL to make a template work. Maybe it’s messy, but as long as I’m not doing any serious damage, it gets the idea across and moves the team forward. And in the meantime, at least I’m not blocked.”

“You don’t always have that synchronous ability to say, ‘Let’s solve this thing right now.’”

Califa doesn’t expect any of his quick-fixes to make it to production—the engineers are there to create the beautiful code. “But I don’t ever want an engineer I’m working with to be spending a large chunk of their time focusing on things that will unblock me,” he says.

This approach does more than bail Califa out of jams. By learning a bit of this and that and exercising his coding skills, he develops empathy for what everyone else on his team is doing. He can better appreciate their expertise, and rather than showing neediness, he demonstrates trust that they’ll remedy his patchwork jobs.

The point here isn’t to take over your teammates’ roles. “Sometimes designers get a bit too far into the weeds,” Califa acknowledges. Instead, it’s to develop empathy (and consequently, trust) without stomping on your partners’ toes.

GitHub has done well to hire people that are outcome focused and have high EQs. These employees are more than willing to go out of their way to make it easier on each other and take risks when it means getting the job done.

Do what you’re good at; create symbiosis

The flip side of being able to do a bit of everyone’s job is that you can perform better in your job—by expanding upon the skills and perspective you bring to the table.

At GitHub, product designers are typically paired with a product manager and an engineering manager to roadmap what they’re building. Pretty standard setup, right? But “standard” doesn’t always mean “effective.”

“Every PM and product designer will have different skill sets, different strengths and weaknesses, that can either work well together or not,” he says. “When two people are a good match, you’ll typically see that one person is very strong where the other is not, and vice versa. Obviously, this is not always the case, but it usually is in areas where it really matters. The most important ability that each employee should have is an understanding of what their strengths and weaknesses are.”

“The most important ability that each employee should have is an understanding of what their strengths and weaknesses are.”

Therefore, Califa prefers not to delineate strictly what a product designer does versus what a product manager does. Instead, he strives to ensure that the overlap between them makes sense. By having someone with experience and knowledge different than his own, he doesn’t have to build expertise in those areas—and he can continue focusing primarily on his own strengths.

The effects of building leadership tandems based on complementary skills rather than job titles are at least twofold. First, and most obviously, you improve your team by encouraging genuine expertise, instead of relying on the cargo cult method—calling someone a “product designer” does not a product designer make.

You also build collaborative relationships. In a remote workforce, where it’s simple to think of your coworker as an email address more than as a human being, building leadership teams based on complementary abilities encourages a kind of symbiosis.

“We hire people who are collaborative, humble, kind, and are less focused on who’s making which decisions. And because of that, we’re able to create an especially wonderful experience for our customers—quickly.” Califa says.

Write it all down; ease the process

Talking to Califa, it’s clear that the core of successful remote teams is building interpersonal connections, even when your crew is not in the same physical space. So how do you build camaraderie with hardly any time spent face-to-face?

If you think the answer is “video conferences,” you’re absolutely incorrect.

“There are almost zero meetings at GitHub,” Califa says. “I have maybe three hours of meetings a week.”

It’s not just that scheduling meetings across time zones are a logistical cluster, though that’s undoubtedly a factor. The lack of meetings also facilitates an entirely different course of communication and documentation, because practically everything happens in writing.

“Our design team functions differently than any design team I’ve ever seen,” Califa says. “Design reviews are mostly async. So you have scrolls of things like, ‘Here’s everything I’ve been thinking about. Here is all of the historical context of why we’re doing this. Here are links out to issues and PR’s and Dropbox Paper docs.’ And then, ‘Here is all of my exploration. Then, if you want to see previous design reviews of this same thing, here are all of the links to that.’”

Without hyperbole, Califa says that everything in GitHub is on GitHub. “Legal is on there, gear is on there,” he says. “Everything that’s ever happened at GitHub is documented and easily accessible.”

This thorough documentation process creates little room for misunderstandings. “Generally, when I don’t have product specs or when we don’t spend enough time thinking about them, it causes a pivot down the line, some level of damage,” he says.

This clarity is all the more critical with the asynchronous nature of remote work, where issues can take more time to address. And it also eases the onboarding process for new remote workers, who can read up on anything they want to know in lieu of absorbing the office culture.

That’s one thing to keep in mind: A remote workforce is its own kind of culture. It doesn’t have to be just an inconvenient necessity in the tech world. Done conscientiously, it can actually be an asset, with effects that ripple beyond its immediate job-specific impacts.