Four ways to create a successful distributed company

The technology industry has embraced geographically diverse teams; with easy access to the latest tools, it’s no surprise. But tools aren’t enough to make a distributed company productive. You have to use those tools wisely in order to create a high functioning team that ships the right features efficiently. Along with the tools, you need to get the human elements right.

When I asked about distributed teams on Twitter, the response was overwhelming. The responses were universally thoughtful about providing a conducive and respectful work environment for each team member. All had spent significant time thinking about distributed organizations, a few had written articles or podcasted about it and one is even writing a book on the topic. Many of those I spoke with highly advocated for distributed companies, seeing advantages not just for the team, but for the product itself.

“Having a distributed team means you can go home and know that someone is always online helping people out in the community or looking out for issues. Being distributed also gives you information on how to build your product.” says Guillermo Rauch, CEO of ZEIT. For example, if your team is in Denver, you test there, which may unduly influence the product direction. When your company is located in diverse geographic locations, you’re more likely to avoid locality biases which ultimately improves your product.

Even though it may be counter-intuitive, distributed companies can be incredibly cohesive. "When done right, distributed teams end up being closer together than those working in an office.” says Nickolas Means, VP  of Engineering at Muve Health.

Here are four tips to help you create a high functioning distributed organization. 

1) Start with culture

Just like co-located companies, all cultures of remote companies aren’t alike. There’s a big difference between a remote-friendly and remote-first culture. A remote-friendly team describes a company culture is open to flexible to members being located in another city from the company’s main office. These teams lean more heavily on traditional work environments which tend to favor face time, ad hoc decision making and  less defined use of collaboration tools. Unless you put in conscious effort, remote-friendly companies will actually have to work harder to create an inclusive environment where geographically diverse and co-located team members alike can flourish.

A distributed team or remote-first team consciously creates processes designed around a geographically diverse team. These company cultures are more likely to build structures that support multiple time zones and various work styles rather than assuming all team members act uniformly. At their best, distributed teams master asynchronous work by not only accepting difference, but by making it the norm.

Though some argue that remote-first and distributed are the same term, others advocate for the term distributed.  "Using the distributed team terminology is a useful way to remind people that we’re all on the same team. No one is remote when everyone is distributed. Everyone buying into it is important.” John Wulff, SVP Software Development at CUSO Financial Services. For some, the use of the term distributed  is about fairness to all team members, regardless of location.  

“Once you have one remote member you become a distributed organization. You can’t think about being partially distributed. It’s binary or someone will be left out. If you embrace one or the other you start getting exceptions.You need to be conscious about both. You can’t burden people in office when you think “remote first” or exclude those outside. It’s more about having parity for both.” says Juan Pablo Buriticá, VP of Engineering at Splice.

When it comes to distributed teams, you can't let culture get created by default; you have to take an active role in crafting it.

2) Use tools mindfully

Just because you have a slack channel doesn’t mean you’ve created effective communication channels; you have to create structures and spaces to help people be their most productive. This is where distributed teams have an edge over remote-friendly and co-located teams. Unable to rely on informal ways of working, distributed teams are forced to create processes and use tools mindfully in order to be effective.

"The biggest mistake companies make is not properly managing communication expectations. Where should communication happen and where does information live? Not getting that right could mean that your organization is set up for failure. Every time you add a person the lines of communication grow exponentially and new members may not know who to ask for what.” says Buriticá.

Make sure your people know where the work gets done, where the socializing gets done and where the general business chatter news occurs. At Splice, the team sets clear expectations about where communication happens so there are boundaries, hand-offs are clear and information is easily accessible. For the team at Splice, Slack is for gifs. Team members can miss anything that happens in Slack but email is important. Everything important they need to know will happen in email or Google Docs. Work happens in Bitbucket and Google Docs while bug management is handled in Clubhouse. The task doesn’t exist if there isn’t a ticket. “It’s easier for team members to understand scoping when there is a membrane or a barrier, projects materialize only when they exist in task tracking software.” says Buriticá

Distributed software teams also need to teach the rest of the organization how to interact with them. "Having a dedicated chat channel isn’t enough. You have to set standards for the rest of the company.” says Brandon Dimcheff, engineering manager at Olark.  Dimcheff set standards after other teams frequently jumped into the main development channel to report issues. Even if there was a designated person on call, the team found it distracting, interrupting their focus. To minimize distractions, Dimcheff created a dedicated on-call channel where interruptions are expected and only the engineering manager and the on-call person at the time actively monitor the channel.

Burnout is a big problem in technology. While there are many factors at play, tools can inadvertently play a big role. For example, the expectation to always be available on a chat channel can contribute to burnout and is largely avoidable. "Never make the assumption that people are always online.” says Rauch. This is where asynchronous processes really help. But it’s more than that, it goes back to the work environment you create. “You have to make it culturally ok to turn off Slack or put it in do-not-disturb mode.” says Dimcheff.

3) Build it into the selection process

Being distributed widens the candidate pool considerably so companies don’t have to limit themselves to those in close proximity; they can hire the best from all over the world. Still, distributed work might not be for everyone. “Not everyone is good at it. It’s a skill unto itself. For example, if you’re the kind of person who waits around to be told what to do you’re going to have a hard time with remote.” Says Matt Sherman, Engineering Manager at Stack Overflow. So too, extroverts or those who need a ton of people interaction may not flourish without co-workers steps away.

Simulate the remote environment during the hiring process to suss out whether a candidate might be a good fit for it.. "We don’t meet anyone in person. It’s all done over video and take home assignments. We also make sure to talk about remote throughout the process.” says Katie Womersley of Buffer.

While having worked remotely in the past may be a good indicator, it shouldn’t be a requirement. Instead, look for signals that a candidate might do well in this kind of environment. For example, during the interview process, look for those who tend to be flexible, able to collaborate and have empathy. "You’re going to deal with some inconvenience when working remotely, communication is harder, it takes empathy to do that.” says Means.

Finally, be sure the candidate has a quiet place to work from on a daily basis. This is especially important if this is their first time working at a distributed company. Means has found this can be as simple as asking, “Do you have a good spot in your house to work that has a door you can close?” This question can weed out people who lack a conducive environment and help the candidate to think more deeply about their potential work environment  before taking the job.

4) People skills and technical skills are equally important

Companies that are successful at being distributed recognize that the code isn't everything. While the code is the tangible output, it’s all too easy to miss the people behind it—especially when you can’t see them every day, eating lunch or doing other everyday activities. But missing the people would be a mistake. “Our most important focus has to be on people,” says Matt Stauffer, CTO of Tighten. “The actual code we write is much less important than you might think.” And the people side of things can get a bit uncomfortable at times, especially if your preferred communication style is more indirect. “Direct communication styles serve remote really well,” says Stauffer. "Indirect is much harder to decipher when remote. That means I need to be willing to have healthy conflict. As a leader, it is a discipline I have to practice: to swallow my discomfort in order to allow the other person to grow. If not, I'm harming them for the sake of my comfort.” But when you take care of the people stuff, it makes the code much easier.

Leaders at successful distributed companies spend time leveling up their people skills, rather than focusing on staying up to date on the details of the latest technology. "Prior to becoming a leader, all my time was spent leveling up my tech skills. Since then it’s been about leveling up my emotional intelligence and leadership. Work on your emotional intelligence. As a leader of a distributed team, it will take you further than the latest framework or knowledge.” Michael Eaton, who leads a distributed team at Quicken Loans.

How Emotionally Intelligent Managers Lead Distributed Teams

Earlier this year IBM followed other big companies like Aetna in turning back to more traditional work arrangements. The tech giant drew criticismfor telling thousands of remote employees to re-acclimate to office life or else find work elsewhere. According to Gallup, the remote workforce is actually growing despite moves like these, with 43% of U.S. employees working remotely at least some of the time over the past year, up from 39% in 2012. Gallup researchers found not only that this trend is progressing across virtually all industries, but also that employees who spend three to four days a week working offsite tend to report higher “engagement” in their jobs.

But for remote work to pay off–both for employees and their employers–one crucial factor needs to hold true, and it’s a familiar one: teams need to have great working relationships with their direct supervisors. No amount of technological wizardry or personal autonomy negates the fact–which has long been true for office-bound workers as well–that job satisfaction is still closely tied to having an effective, emotionally intelligent boss. With that in mind, here are a few ways managers can continue to be the same thoughtful, compassionate leaders of remote teams as they’ve learned to be in the office.


Perhaps the biggest challenge managers face is a “mixed mode” team, with some in the office and others located remotely. That’s a really common circumstance, and it takes extra vigilance for managers to avoid playing favorites or accidentally making their remote folks feel like second-class citizens.

There are simple things you can do as a manager to avoid this trap, says John Wulff, SVP Software Development at CUSO Financial Services. “If there’s a meeting and even one person is remote, have everyone attend as if they’re remote using the same tool, so there’s no inequity in how people are participating.” This not only normalizes the remote experience, it also forces you to find an approach (technological as much as methodological) to remote meetings that isn’t disproportionately painful to the people offsite.

While staying informed is a day-to-day concern for remote employees, so is the fear of that their careers won’t progress. In one recent survey remote workers reported having 25% fewer conversations with their managers about career growth than their colleagues in the office. All it takes is a little empathy for managers to rectify that. Anticipate your remote team members’ anxieties about not being recognized and schedule a quarterly career-development meeting to check in and talk about their progress and professional goals.


Micromanaging your team is dangerously easy when you work in an office: You can simply walk around and look at their screens. But when you can’t physically see what your employees are doing at every moment, nervous managers may resort to other ways to look over their remote employees’ shoulders–none of which are likely to be terribly productive.

“Micromanagement comes from trust issues,” says David Haney, an engineering manager at Stack Overflow. “The biggest thing you can do is create trust. You can’t buy trust, you have to build it,” he points out. “If you don’t trust the people you’re working with, you have a much bigger issue than just people working remotely.”

This may sound obvious enough, but too many managers mistake delegating for trust. Just handing your direct report an assignment and saying, “hop to it” isn’t the same thing as entrusting them with a task they feel sufficiently supported to tackle on their own, and this mistake is one reason remote workers can sometimes feel adrift. On the flip side, moving from control to building trust can feel tricky for bosses who are used to playing an active role in their employees’ day-to-day work. Fortunately, a dose of emotional intelligence helps solve both problems.

The best starting point is simply to empathize with your team members. There's no videoconferencing platform more powerful than a dose of empathy. According to Guillermo Rauch, CEO of the mobile computing company Zeit, empathy means understanding “the context” of others’ work experience.

Rather than focusing on what your team is doing at every moment, ask yourself how they’re likely to feel about accomplishing the goals you’ve set for them: Will they be challenged? Empowered? Stressed out? Confused? Then self-reflect on your role in bringing about those reactions, Rauch suggests: “In a remote environment, as a leader, you have to be a lot more introspective.”

Rauch has found that by working to become more empathetic and introspective himself, his remote team has learned not only to trust him more but also one another–making everybody more productive. And since trust often starts with a personal connection, which virtual teams lack, it’s important for managers to set aside work and spend time just getting to know each other–including remotely.

A few years ago, tech founder Randy Rayess and his team “started holding personal check-ins rather than just discussing work on our usual calls,” he told Fast Company in 2015. “We made sure to talk about hobbies, interests, and family at least once a week” and quickly found that the habit built trust and led to stronger collaboration.


In a traditional office environment, it’s easy to rely on physical cues to sense when a team member is getting ready to quit. But when you lose that casual, in-person contact you can miss important clues. “You have to spend a lot of time drawing people’s feelings out of them. Otherwise you run the risk of someone getting detached, getting frustrated, and leaving,” explains Nickolas Means, VP of Engineering at Muve Health.

Listening is a skill that’s at the core of emotional intelligence, and great listeners are also effective questioners. As a manager of remote team members, that’s your ticket to filling in any missing information you’d otherwise get in person. Rather than just constrain your one-on-one meetings to being quick status reports, use those interactions as a time to connect and dig deeper with your remote employees. Ask your team members questions about what’s most important to them and the challenges they face–don’t just wait for them to bring up those issues themselves. You’ll not only better understand what motivates them, you’ll make them feel more valued, too.


Communication is harder when team aren’t co-located, especially when it comes to giving direct feedback and heading off conflict. Lack of daily, physical presence can make it easier to sidestep uncomfortable conversations, but that’s not exactly the most emotionally intelligent approach. According to Katie Womersley, director of Engineering at Buffer, the most successful leaders of remote teams embrace conflict. When managers “don’t want to hurt feelings or step on toes, artificial harmony can creep in,” she says.

Womersley prevents emotional gridlock by taking preventive measures. If there’s a new team or a new phase in a project, for instance, she calls a meeting whose sole purpose is to focus on conflict. Womersley asks her team members to take turns talking about their conflict styles, and designates one person in the meeting to look for potential areas where team members are likely to clash. This helps get everything out in the open, where people can discuss potential points of friction, before they encounter it unexpectedly later on, once everyone has hit the ground running.

As these four tips suggest, your own emotional intelligence as a manager is critical when you’re leading a team of remote workers. But that’s the key to developing those same skills attributes–empathy, trust, listening, and comfort unearthing disagreement–in every one of your team members, no matter how far-flung.

A version of this article originally appeared on Fast Company.

What Makes Your Best Developers Want to Leave

Everyone from college students to mid-career professionals looking for a job change have been told they need to learn how to code. And despite outright detractors and calls for moderation from inside the tech sector, a glut of coding schools has flooded the job market with junior developers.

You’d think that would be good news for tech companies, which now have their pick of newly minted talent. But in many cases it can actually make it harder to develop and maintain a deep bench of tech talent at the senior level–folks who actually stick around, mentor newcomers, and solve the really hairy technical problems more inexperienced coders often can’t.

Too often, the tech industry’s usual slate of perks doesn’t have as much impact when it comes to retaining the most top-shelf, experienced talent. As Stack Overflow COO Jeff Szczepanski wrote for Fast Company recently, “developers care about learning and growing,” but training and professional development aren’t exactly the first things hot new startups rush to talk about when asked about their cultures. In order to stick around, great developers need real career paths; in other words, not just a “hot” job. Here’s a look at a few reasons why your best tech talent might be contemplating an exit, and what it takes to prevent that.


The fun of solving problems and the joy of seeing something they’ve built come to life is what drives many software developers. Companies need to leave room for the best of them to keep conceiving of–and then executing–new ideas. “If someone who’s been coming to you with their ideas suddenly stops, it’s a huge sign they’re on the way out the door,” says technology consultant Jason Cole, who advises small businesses on their engineering teams. “If you have someone saying, ‘I’m bored’ and you don’t do something about it, expect them to leave for a place where they won’t be bored.”

These issues don’t usually crop up until somebody’s given their notice and you’re holding an exit interview. But that always means the information you could’ve used to get ahead of the problem arrives too late. That’s why tech leaders should consider holding “stay interviews” with their most valued developers. When the ideas stop flowing or productivity sinks, it’s usually a sign you need to have this type of proactive sit-down.

Diane Scarborough, most recently the interim VP for People and Culture at Sprint Connect, says she’s learned to spot these changes in behavior, however subtle, and unearth unspoken complaints before it’s too late. When talking with team members, she probes for a longing to work on newer technologies and listens for any mentions of friends at other companies working on different projects. Even if these remarks are only made off-handedly, she knows they can be red flags. “Don’t be afraid to ask people questions,” she advises: “Are you happy? What’s making you stay? What would make you leave?”

She adds, “Asking ‘Are you okay?’ isn’t illegal.”


The traditional career path is linear, which often means pushing top talent down a management track, supervising others. Leaders may notice that one of their people enjoys teaching others, and then assume that they’d enjoy managing others.

Mentoring and managing might seem similar, but they’re entirely different skills. Management is really about getting work done through others, which makes it highly people-focused. Mentoring or instructing–especially when it comes to software development–is more about a knowledge-transfer of technical skills.

Be careful not to mistake a technical expert who enjoys teaching for one who enjoys managing. Instead, offer your best senior engineers more than just one kind of leadership opportunity; carve out a separate path for technical experts to advance up the ranks based on how well they help their junior colleagues “skill up”–even if that doesn’t involve managing their work.


Be careful not allow your org chart to become a rigid, set-and-forget artifact–an especially acute risk when it comes to technical roles. Review and adjust your structure to match the expertise of your current team. In Cole’s experience, “the number-one reason technical people quit is because they don’t have the option to advance without going into management.” Szczepanski would likely agree; in his view, developers often get frustrated having to report to leaders who don’t have tech backgrounds themselves.

It’s a perennial problem, but circumventing it can be as simple as reviewing your reporting structure on a regular basis. No matter who leaves and who joins, you always have to make sure there are tech experts in the managerial ranks, and clear paths for other engineers to rise into them.


In an attempt to provide flexibility and empower employees, some companies are actually too hands-off–they wind up not giving enough career support. “It’s easy to tell people you’re in charge of your own career,” Scarborough points out, “but it doesn’t work if you don’t support them. Nobody wins if you don’t help them.”

That’s just as true for developers as it is for anyone else, but the risk may be higher when it comes to tech teams, whose expertise can automatically cordon them off from leaders who may not know exactly what they do–or what professional development they might need. On top of that, your engineering team might be so in the weeds with their work they may not be looking at their skills or figure out how they might be applied better.

So rather than making succession planning a once-a-year, check-the-box formality, it’s important to find career development opportunities on a regular basis. Your HR leaders don’t need to have all the answers themselves, either; one of the best ways to offer support is simply to get everyone in a room for an hour and brainstorm ideas for how they can get more of what they want from their work.

Ultimately, building a culture of continuous learning and improvement is what will keep your most valuable senior tech talent on board. And it all starts with having more conversations than you might be, more often. When people can use their talents to do what they love while expanding their skills, they won’t just stay put–they’ll tell their smartest friends to come join them.

A version of this article, this is Why Your Best Developers Keep Quitting originally appear on Fast Company.