Bjorn Freeman-Benson: Three Challenges of Distributed Teams

Distributed teams. Are they the solution to our staffing problems, or an expensive fantasy? I had the opportunity to sit down with Bjorn Freeman-Benson earlier this month to explore these questions.

Bjorn is an experienced software leader. Highlights of his career include heading up engineering at New Relic as it grew from 3 developers to 330; growing Invision from 60 developers to 350 as its CTO; working on VisualAge Smalltalk at OTI (Object Technology International); and coordinating the open-source Eclipse developers at the Eclipse Organization.

Throughout his career, Bjorn has worked with many different types of teams, from fully co-located to fully distributed. New Relic’s developers all worked together, on several floors of an office building in downtown Portland. InVision was fully distributed, with everyone working remote. OTI had small offices all over the world. And the Eclipse Organization was semi-distributed, with contributions coming from a mix of on-site employees and remote volunteers.

When I heard Bjorn’s story, I knew I had to convince him to give me an interview. Two weeks ago, we sat down at a coffee shop in northeast Portland.

Bjorn described three challenges for distributed teams: the n+1 management problem, the junior people problem, and the friction of communication problem.

The N+1 Management Problem

“For an engineering manager role, you have to hire people with director-level skills.”

“In a distributed organization, managers must be n+1 good,” Bjorn said. In other words, for an engineering manager role, you have to hire people with director-level skills.

This is an astonishing claim. To understand it, you need to understand the difference between a manager’s skillset and a director’s skillset.

Manager Skills vs. Director Skills

To be a good manager, Bjorn says, you have to learn how to interact with people. In a co-located team, you can see the minute-to-minute behavior of a team just by walking around. This gives you... not “control,” exactly, but an understanding of the issues people are facing and what they need. It allows you to intervene without micromanaging.

As an example, Bjorn pointed to a woman sitting behind us at the coffee shop. “See that woman there?” he said. “I can tell she isn’t very engaged with her work because she keeps checking her phone.” If he were her manager, he could coach her about staying engaged.

To be a good director, on the other hand, you have to learn indirect management. You don’t have the same insight into people’s work that you do as a manager. Instead, you have to infer what’s happening based on the results you see.

Managing a Distributed Team

These indirect management skills are also needed in distributed teams. In a distributed team, you can’t see people working, so you have to infer what help they need from their output and questions.

Interpersonal interactions are also harder to manage in a distributed team. “If I piss you off but don’t realize it in a local office,” Bjorn said, “later on I’ll notice you glaring at me. You don’t usually do that. So we fix it.”

In a distributed team, “The chance of pissing you off is greater because we’re communicating via video. Then I don’t see you again, and the next thing I’ve heard is that you resigned.”

So instead, managers of distributed teams need to practice a remote version of management by walking around. You need to touch base with everyone on the team frequently, but you don’t want to appear to be micromanaging. Bjorn suggested ideas such as a virtual lunch with the team every day, calling up and chatting about football or some other shared interest, and project demo days every week. For the latter, Bjorn said he made a point of never providing negative feedback: the purpose of the demo was to give the team a chance to show off and reinforce interpersonal connections, not critique the team’s work.

The Junior People Problem

“It’s basically impossible to hire junior people in a distributed company.”

“It’s basically impossible to hire junior people in a distributed company,” Bjorn said. “I watched it work at [co-located] New Relic but not at [distributed] InVision.”

Bjorn didn’t mean that it was physically impossible to hire junior developers, of course. He meant that hiring junior people doesn’t pay off.

Bjorn explained it this way: When a developer is just starting, they have a lot of questions. They don’t know how to do the work. But at the same time, they’re at the bottom of the pecking order. They’re hesitant to interrupt and don’t want to be seen as a burden.

At New Relic, which had developers sitting next to each other, juniors could see what people were doing and ask questions at convenient times, when they knew they weren’t interrupting.

With InVision’s 100% remote teams, though, junior developers couldn’t see what other developers were doing. They were afraid to interrupt. “They froze and got stuck,” Bjorn said, “until much later when they were explicitly asked what they were doing.”

“Typically, we get much more from juniors than we pay them,” Bjorn said. That’s because junior developers aren’t paid much and they develop their skills quickly. At InVision, though, juniors “didn’t develop their skills and didn’t get much work done, so hiring juniors wasn’t a good use of money.”

Lack of junior developers is a problem in companies with more than fifty engineers, Bjorn says. “There’s some grunt work you can’t get [senior] people to do. They don’t want to do it.” You need people at all skill levels to take care of the work that exists at all levels.

The Friction of Communication Problem

“We had to overstaff to get the same amount of creativity.”

Due to communication friction, “we got much less creativity out of our [distributed teams] at InVision,” Bjorn said. “We had to overstaff to get the same amount of creativity. In other words, if communication was 80% as effective, we’d have to hire 30% more people.” Communication friction didn’t necessarily affect productivity, but it did affect creativity. And in InVision’s startup environment, creativity was key.

In a distributed team, Bjorn says, two thing keep occuring. First, the cost of establishing communication is much higher, even when the technology works perfectly.

  1. A: B, are you there?
  2. B: Yes I am
  3. A: Let’s chat
  4. B: OK
  5. A: (sets up video call)
  6. A: (waits)
  7. B: (joins call)

In comparison, in a co-located team, there’s no friction.

  1. A: (turns head) B, I have a question.

Theoretically, you could use always-on video links, but “people don’t want to do that. It’s uncomfortable.”

Second, in practice, video call technology doesn’t allow simultaneous conversation. Only one microphone picks up at once, and latency means you end up talking over each other.

This means that you can’t participate in the conversation like you would in person. In person, you’ll say “uh huh” and make small interjections that help guide the flow of the conversation into a proper collaboration. A video call, on the other hand, ends up being a series of short lectures.

This is especially bad for women, Bjorn says, who tend not to interrupt. It makes it harder to create a diverse team.

The end result is that you get much less creativity out of a distributed team. You have to overstaff to get the same amount of creativity you would get from a co-located team.

The Consequences of Distributed Work

“These purported benefits of fully distributed teams turn out to not be true at scale.”

Common wisdom is that distributed work makes some kinds of communication more difficult, but those downsides are compensated with decreased costs and greater hiring flexibility. But for Bjorn, it didn’t work out that way.

Expected BenefitsActual Result
More choice in hiringLess choice in hiring
Lower costsHigher costs
More work out of peopleMore work, but less creativity

For small organizations, Bjorn says, distributed teams do work effectively. Everyone knows each other and you don’t need multiple levels of indirection.

But beyond about 25 people, Bjorn says the problems he mentioned come into play. “These purported benefits of fully distributed teams turn out to not be true at scale.”

Less Choice in Hiring

Because of the N+1 management problem and the junior people problem, it’s actually harder to hire for distributed teams than co-located teams, Bjorn says. In addition, the people you really want to hire already live in one of the tech centers. “You don’t find a Kubernetes expert in Iowa,” Bjorn said. “You just don’t.”

Higher Costs

According to Bjorn, the ROI curve for developers looks like a bowl: high ROI for junior and senior developers, and closer to break-even for mid-career developers. That’s because junior developers are inexpensive and senior developers raise the capabilities of the people around them.

But in a distributed team, the ROI of junior developers is negative, so you end up hiring less cost-effective mid-career developers in their place. Additionally, Bjorn found that he had to hire more developers in order to get the amount of creativity he needed.

More Work, but Less Creativity

Because they didn’t have to commute, Bjorn did find that he got more hours out of people in his distributed teams. But, he said, “The key thing in any business I’ve worked in is the creative output. [In a distributed team,] you get less of it because of friction. You may even get more units of work, but Jira tickets don’t pay the bills.”

What works?

“My current belief is that there’s really only one structure that works.”

“My current belief is that there’s really only one [distributed] structure that works,” Bjorn said. That structure is the “Pod Remote” approach used by OTI.

OTI had a lot of small offices all over the world. Each office had about ten people who worked co-located. Each was built around a superstar developer, who recruited a mix of junior and senior people locally and was supported by the larger organization.

Each office specialized in a particular type of project. For example, “if you wanted to work on databases, you had to move to Sydney to work with Jeff’s team.”

This model allowed OTI to hire great people wherever they lived. Because teams were co-located, advanced management skills weren’t needed. In fact, one of these offices could be a star’s first management job. OTI still needed N+1 managers to run the distributed organization, but “you need that skill anyway from directors on up.”

The Pod Remote approach to distributed teams is the best of both worlds, Bjorn says. You can hire great people around the world, but still get the advantages of co-located work. “As I look to doing another startup,” Bjorn said, “it’s going to be Pod Remote.”

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.