This post is a continuation of a multipart blog series about Technology Leadership Spectrums. The values of technology leaders fall on a spectrum much like the beliefs of politicians fall on the left or the right of the political spectrum. In this installment, I’ll evaluate the opinions related to the means of team communication, the importance of efficient communication, and the value of on-site employees.

Means of Communication

Since the Vulcan Mind Meld is currently beyond our capabilities, let’s start this analysis with the “Face-to-Face” side of the spectrum. Advocates in this camp believe that in-person communication is the most effective means of communication. They also believe that removing communication barriers and promoting creative collaboration is paramount to building a successful company.

On the opposite end of the spectrum, proponents favor tools like chat/instant messaging. Advocates in this camp typically acknowledge that face-to-face communication is the most effective means of communication; however, these advocates don’t place a high value on communication, and/or these advocates don’t think that face-to-face communication is significantly better than that of other mechanisms such as chat.

Slack is the most popular chat tool amongst engineers. It’s so popular in fact that it has become a verb as in, “I’ll slack you the link to the details.”; however, Slack is not without its drawbacks as Dan Kador pointed out in the following interview:

All forms of communication aside from speaking to somebody in-person… are inherently flawed but are appropriate for certain kinds of communication. Slack is wonderful, but we have a habit of treating Slack as [a tool to] communicate everything… and that’s definitely not true because it is impossible to communicate tone and intention. It also has the downside of being realtime, so as a composer of text, you are at the disadvantage of not being able to go back and edit. It’s such an easy way to inflame a situation… when a simple voice communication wouldn’t have caused a problem to begin with… People get addicted to the realtime nature and notifications of these things… and don’t turn them off as much as they should… I also think [Slack] has a real problem with threading. One of the good things about email is that you can at least keep threads going. The worst [Slack] channels are the ones with five concurrent conversations going on. (CTO Connection Podcast — min 33:00)

As mentioned in the following interview, Scott Carleton also has mixed feelings about Slack:

[Slack] is a tool like any other tool, and I have now seen people really abuse it… Chat allows us this always-on meeting in its worst form or at best, an asynchronous tool to keep everyone apprised and stop the one-to-one-to-one… conversations. ChatOps, as a development technique, is fantastic because you hit “hubot deploy…” and everyone knows that that deploy is happening. But at its worst, nothing is explicit, nothing is defined, and action items aren’t carried forward. I am big fan of using chat as a way to hash out issues, but in distributed teams, it has to live in an explicit place [more on this in a bit]. (CTO Connection — min 13:30)

Besides the communication challenges of Slack, the following list includes other drawbacks. However, all that being said, Slack is wildly popular with engineers, so exclude it at your own talent risk. ;-)

Corporate data living on yet another cloud platform (InfoSec & audit concerns)
Additional cost (for legal ediscovery)
Segmented users (e.g. it’s hard to keep users from using Google Chat that comes with G Suite)

One communication mechanism not depicted in the diagram is a tool such as Jira. I left it out of the diagram because it’s a bit hard to classify as it can be called many different things — an issue tracker, a task tracker, a story tracker, etc. Popular tools in this category include Jira, Asana, Trello, Basecamp, etc. The fact that I left a “story tracker” out of the diagram should not undermine its importance. As Scott Carleton pointed out in the previously mentioned interview:

Friction rises in communication when information doesn’t have a place to settle. A Github issue is a good example. Once an issue is created, it’s really easy to collaborate on a focused conversation on that issue. You need a tool or a place to put information when that information is getting lost or that conversation is coming up again and again. Which is why Trello is a good [one]… so that action items, fears, and issues are not lost… making sure that support requests have a place to live and are getting communicated to the right people… [so that we can] distill that information into something actionable and not forget about it. (CTO Connection — min 11:50)

Local vs. Remote

The “Local vs. Remote” spectrum is closely related to the “Means of Communication” one. Typically, those who put high importance on face-to-face communication favor on-site teams, while those who put low importance on such communication favor distributed teams.

“Local” proponents believe that a team functions best when its members collaborate during the same hours from the same location. They believe that the in-person interactions at the water cooler and in huddles are essential to building team culture and camaraderie. The advocates also believe that staff and offices should be organized to maximize face-to-face collaboration. As Eric Schmidt and his co-authors put it:

Offices should be designed to maximize energy and interactions… When you can reach out and tap someone on the shoulder, there is nothing to get in the way of communications and the flow of ideas.
Working from home kills innovation. Make sure your offices have everything employees need to be happy, healthy, and productive. Then expect them to work there. (How Google Works: 50 Ideas)

As portrayed in the following interview, Cai GoGwilt has a similar perspective:

[Peter Bell — interviewer] Do you primarily hire in the Bay area, or do you have distributed engineering?
[Cai] That’s another place where we take a pretty hard stance... Our entire product design and engineering team is based in San Francisco. We do not have any hidden team of contractors on any part of our future development. We also don’t really do remote work. We’d love for someone else to figure out how to do remote work or mixed remote and in-office culture correctly. I have seen a lot of people struggle with it. I have seen a lot people try it and maybe have some success with it, but we’ve taken a pretty hard stance on creating and emphasizing in-person communication and both capitalizing on the cross-functional communication that you get and the context sharing that you get from that while also eating the cost of not being able to bring on people who really do want to have a remote work culture.(CTO Connection — min 34:30)

On the other end of the spectrum, “Remote” proponents usually have one of two goals in mind — either they want to minimize labor costs, or they want to access talent that they can’t find locally. In the following interview, Nick Caldwell points out the importance of distributed talent:

Engineering talent exists everywhere. I am a huge fan of supporting remote work. In terms of distributed teams, every place that I have worked for as long as I can remember has had some sort of combination of either fully remote teams or a hybrid model. Technology is increasingly pushing us in that direction. We are on Zoom right now. Increasingly, you’ll walk into an office and see that every room is wired for Zoom… Within this decade, we have turned an inflection point where if you are a manager, it is no longer acceptable to say that we are not going to have remote work. It has to be a part of your growth strategy… There is so much more talent springing up in other parts of the world and the country, you’ve gotta think about a way to incorporate that into growing your organization. (CTO Connection — min 21:50)

When “Remote” advocates want to minimize labor costs, they typically do so by offshoring. Offshoring that involves timezone, language, and/or cultural barriers has at least some impact on productivity; however, “Remote” proponents think that the labor savings outweigh the productivity impact. Proponents in this camp might even completely ignore the productivity impact and compare the cost of local vs. remote engineers on a one-to-one basis.

If you are trying to minimize labor costs while building a great company, you might want to take a page from PayPal’s playbook. Reid Hoffman, one of PayPal’s founders, attributed their meteoric success to hiring talented employees with little experience as opposed to the classic wisdom of hiring people with 10–20 years of experience (This Week in Startups — min 57:25). You could even take that one step further by hiring from coding boot camps (e.g. Galvanize) instead of traditional universities.

Another alternative to offshoring is nearshoring either in Mexico or Costa Rica (assuming that you are in the US). This option might be appealing to cost-conscious proponents who believe that real-time communication is crucial to building a great company.

Consensus on “Local vs. Remote” is difficult to pin down, especially since there are different flavors of remote (e.g. home office vs. satellite office). In general, though, I think consensus lies on the “Remote” side.

For other philosophies related to technology leadership, please check out the parent post as well as the following posts: