“Build More Roads” is Often the Wrong Answer

The Power Broker, Robert Caro’s masterful biography of Robert Moses, tells the story of how modern New York City came to be. Moses and his team were responsible for some of the most important public infrastructure interventions in and around New York City during a span of four decades starting in the mid-1920s. Under Moses’s leadership, the city gained new parks, playgrounds, bridges, and especially roads — sometimes at the expense of beloved neighborhoods and the disruption of countless lives. An unelected official, Moses became incredibly powerful; you can see his influence in New York even today.

The core of Moses’s power lay in the Triborough Bridge Commission, which controlled the flow of traffic between Manhattan, The Bronx, and Queens. Tolls from vehicles driving across the Commission’s bridges generated immense revenues that paid for other projects, which in turn generated more revenues. For Moses, vehicular flow in New York City’s streets translated directly to more power. Thus, when considering means for transporting the city’s inhabitants, Moses’s team would gravitate towards more roads — even when it’d become clear that building more roads only increased congestion. The result was the defacement of major parts of the city with highways and roads that were constantly jammed with traffic.

You gotta watch incentives.

This comes to mind because of something that Jessica Ivins said on her interview for The Informed Life podcast:

So not everybody has the detail-oriented mind that I do, or not everybody works the same way I do. And because we’re small and I’ve been working here for almost 5 years, I have a sense of what works well for my co-workers. So for example, my coworker Thomas, I will assign him a to-do in Basecamp and he’ll get an email notification, but I’ll also send him a notice on Slack. And I’ll say, “Hey Thomas, I signed you this to-do on Basecamp, please review it by this date and see the to-do for details.” And that Slack message really helps him because he… I guess some people are really good at wrangling their inbox, other people really struggle with it. And I think that’s really typical.

It is typical. I’ve faced similar situations in other projects: Someone new joins the team, and you don’t yet know their communications preferences. Are they an email person? Do they prefer Slack? Or maybe iMessage? It’s not unusual to get a message in Slack followed by an email asking, “Did you see the message I put in Slack?” And of course, people’s preferences vary depending on other factors. For example, perhaps they only use Slack on their computers and find it easier to respond via SMS when they’re on the road.

Proprietary communications systems like Slack and Basecamp set out to solve the problems with older systems like email (and there are many!), but like Moses’s roads they can end up creating other problems. Now instead of one or two places to check your communications, you have five. You get reminders on one system (e.g., email) to check messages sent to you on another (e.g., Basecamp.) I’ve gotten messages on Slack to check something that was posted in Basecamp; later that evening I’ll also get an email reminder from Basecamp of all the things that were posted there during the day. The signal-to-noise ratio goes through the floor. And of course, now you have to keep track of where you saw the message or file if you ever need to get back to it. (“Did you send that document over email, or was it in Slack?”) As far as I know, it isn’t possible to search across all of these systems; it’s up to you to keep track of where things are. This is difficult, given the challenge I mentioned above. (I.e., different people have different communications preferences.)

The added complexity would be worthwhile if these systems enabled amazing new ways of working, but these proprietary communications systems bring little new to the table; most of the functionality they enable has been around for a while. Check out Jon Udell’s book Practical Internet Groupware for the state of the art twenty years ago; you’ll find lots that is familiar. It’s worth noting that that book advocated for building these communications systems atop existing open standard technologies. In this sense at least, the current state represents a regression from where things were in the late 90s.

I’m cranky about this stuff because in the past month I’ve joined three new Slacks and one Basecamp project. This is part of the job when you’re an independent consultant who works on several projects with different teams throughout the year. But I don’t enter these spaces casually. As someone who thinks about the longevity and resilience of information ecosystems, I’m concerned about my ability to find and keep track of stuff — especially in the long term. I dislike the proliferation of disconnected, single-purpose silos of information. While the discussions that happen in these places can be rich, vibrant, and productive (that is, when they’re not generating more noise in other channels), they’re locked away, inaccessible for future (even near-future) reference.

In the long term, building more roads isn’t the solution to the challenge of moving lots of people from one point to another. Past a certain volume, individual vehicles are inherently inefficient; one needs to re-think the structure of the transportation system from the ground up. This is more challenging if the people charged with the stewardship of these systems are incentivized to get more cars on the road. I sense similar problems with the communications challenges we face in organizations. When what you’re selling is access to Slack, your incentive​ is to get more people using Slack. That’s a different goal than getting people to communicate effectively. Yes, there is some overlap there — up to a point. How does the system scale?​