Thinking Outside the Cube: Layer

Layer’s VP of Engineering’s three rules to rock distributed

Thinking Outside the Cubeis a series of posts that introduce unique insights from CTOs and other tech leaders at companies who have successfully implemented distributed models—a more thorough version of remote work—into their workforce policies.—Like many of its counterparts and competitors in the startup realm, Layer calls San Francisco home. Since 2013 the company has steadily been leading the charge in providing intuitive, UI-focused toolkits that companies can use to customize how they interact with their client base to provide engaging experiences.But unlike the many counterparts and competitors it shares a zip code with, Layer doesn’t worry about landing top tech talent — with 50% of its software developers working across other cities in the U.S., across Europe, and across Africa, the company has found that deprioritizing geography as a mandatory employment element has opened them up to some of the best talents around the world.Partially driven by fierce local competition, partially driven by an understanding of the often overlooked business benefits of geographical diversity, Layer has been remote since it started. Scaling the model has been relatively pain-free — from his time managing remote workers out of Paris at Salesforce, the company’s VP of Engineering, Kevin Schraith, brings the management experience, process knowledge, and cultural appreciation required to make distributed work.“It can be intimidating because people have had bad experiences with outsourcing,” Schraith says, acknowledging the knee-jerk reluctance of his colleagues that refuse to not have talent work in office because remote reminds them of offshoring. “But, look, if you have the right mindset and you take a concentrated approach to executing it, you can reap the benefits of looking outside of just your immediate area to find talent.”Specifically, Schraith’s approach includes three fundamental rules:

1. Select for cultural fit, not just for skill and experience.

Perhaps the most important element of a successful remote venture is how dedicated the team is to the mission, Schraith notes. For Layer — and for any company who truly wants to embrace distributed — this means integrating all new hires, especially distributed ones, into the broader company culture.“It’s so easy to dismiss, but cohesion — cultural fit — is imperative,” he says. “Many people have poor experiences with outsourcing or remote work because they skip the cultural alignment step and select from resume line-items, which can result in detached developers who only care about the money and don’t care about the quality of the product.”Schraith admits that sometimes quantifying cultural fit can be difficult without first really knowing the developer. But when it’s right, he says, it tends to “You tend to know it when you see it,” he says, “And in those moments you can tell you’ve got the right distributed developer.”Schraith explains how Wale, Layer’s Andela Developer, proved this early on. “We had a team-wide stand-up on Fridays, and some of our engineers decided to make it a Hawaiian shirt day in the office. Wale noticed and the next Friday joined the call wearing a Hawaiian shirt. Everyone loved it.”“It might seem elementary, but it signaled that he cared about the company and cared about fitting into the team. And that kind of thing is reflected in the work.”

2. Onboard them like they’re there.

Finding the right developer for the company culture is just the first step to fostering a good distributed relationship, Schraith explains. “The onboarding part is important to establish good impressions of each other off the bat — to set the tone for the work, the expectations, and generally just to familiarize yourself with them and them with you — something many people take for granted.”Schraith’s belief in onboarding echoes Andela’s, which provides its partners with access to an entire support staff and flies their developers out to their headquarters first. “Andela’s onboarding execution is great because we actually get to meet them face-to-face for a few weeks before kicking off the work,” he says. “Something like that is important — if you can’t meet them face-to-face, at least spending a lot of time talking about more than just work helps you develop a good relationship with one another, which goes a long way in really building out that motivation.”

3. Communicate. Communicate again. And then communicate again.

Finally, committing to good communication is another component Schraith finds necessary for an effective distributed workforce.Poor communication practices threaten traditional workforces as much as remote workforces — it’s a myth that distributed workforces are exclusively disrupted by poor communications. In fact, the assumption that remote communications are bad by default is an advantage for the policy — it forces managers to preemptively over-communicate to compensate the perceived failure, which is exactly what Schraith thinks is necessary to make any kind of policy work well.“Young developers might be reluctant to admit when they don’t know something — especially if they feel out of place because they’re not in the office,” he notes as an example. “Instead of speaking up, they might keep things to themselves and just try to muddle through — this can be a problem, as any manager with people under them can tell you.”Schraith’s advice for solving this is over-communication. He suggests a borderline barrage of messages and follow-ups. “As long as they’re through the appropriate channels — asynchronous ones in the case of over-communication — they’ll be interpreted as guidance, advice, and clarity: Not as inbox clutter.”And the importance of the over-communication doctrine is a shared by more than just Schraith and Layer — many other teams that have embraced remote or distributed work have found the value in keeping the message channels active.“The best part is that it’s so easy to do it, we have the technology and the infrastructure that really ends all excuses for poor communication,” he says.Following Schraith’s advice can help companies go distributed, but for him, all of it comes down to one key element.“Honestly,” he says, recapping what it takes to do distributed right, “it just comes down to good alignment.”“A lot of people who experiment with distributed — or who have had bad experiences with outsourcing — have had those because they’ve taken the wrong approach. They’ve figured that since the developers aren’t in the office, they’re anonymous, and they’re just a collection of skills to be used as a tool to get work done. If you want to make it work, make sure they’re aligned with the company — the mission, the vision — and everything else will follow.”