“As teams and companies grow, what processes and systems break down that often don’t get addressed quickly enough?”

That’s the question I posed to leaders from Dropbox, Facebook, Stripe, and Lyft at a recent panel on Engineering for High Growth. And one after another, the panelists all responded with variations of the same theme: communication is often the first casualty of growth. As a team grows, it gets harder to share ideas and to make sure that everyone is on the same page. Patterns and conventions for communication that used to work start to break.

Stories of communication failures surface often when I work with engineers to help them be more effective. A product team might be ready to deliver a high-priority feature to a customer and decide to solicit input from the infrastructure team, only for someone to discover a last-minute latency issue that blocks the launch. Or a platform team might upgrade the code behind a service, only to break clients who relied on undocumented assumptions in the behavior of the old API. Or one team might update a configuration file, unaware that a certain setting was specified for historical reasons, and cause a spate of errors or pager duty alerts to fire for their product.

The incidents might seem isolated, but they all follow a common pattern: knowledge gaps stemming from a lapse in communication hurt a team’s ability to execute. Companies like the ones on the panel that experience hyper-growth — where the employee base grows by 2-3x consistently year over year — see this breakdown occur more rapidly. But the same breakdown still happens at a more gradual pace at other companies. The results range from wasted engineering effort and increased stress to reduced software quality and unhappy customers.

Why Communication Breaks Down

Back when I first started working at Quora, Ooyala, and Quip, the startups consisted of only one or two dozen employees. I could walk over to someone’s desk, or sometimes even just turn around in my chair, to discuss a design or to make a decision with a teammate. I knew who on the team was the expert for any given piece of the product or codebase. Moreover, every engineer could hold a reasonable fraction of the product and the code in their heads, and that knowledge provided a shared context that made it easy to ask questions and hold discussions. During those early days, the cost of communication was low.

That luxury erodes away as a company grows, for two reasons.

First, the total number of people you need to communicate with increases. Frederick Brooks discusses this effect in The Mythical Man-Month, where he points out that the number of pairwise interactions between people grows quadratically with team size. ¹ (That’s a major reason why adding more people to a project oftentimes doesn’t help make it finish faster.) Sharing information may no longer mean just giving someone else a quick heads up during a break; it might actually require a formally scheduled meeting with a large group of people.

Second, the cost of communicating with a given person also increases. As a team grows, the average familiarity with the product and the codebase decreases. New hires don’t have the same historical context for past decisions, and even the more senior teammates have to expend more effort to keep abreast of everything going on. You’ll have less shared rapport with others on the team, and so you might hesitate to informally ask questions as they arise. Instead, you might batch them and only ask them during scheduled meetings.

Questions also become harder to formulate: What history do I need to know about this project? What are all the related projects that this might impact? Who actually knows about these things? Who are the stakeholders who would have strong opinions about future changes?

Those little inconveniences add up. Conversations and discussions become costlier. As a result, individuals need to devote more time to communicating, which leaves less time to getting things done.

The drop in per-person efficiency, in turn, often increases the pressure to grow the team and hire more people as a means to meet business goals. Hiring more people implies spending more time recruiting, interviewing, and debriefing on candidates as well as onboarding new engineers — all of those activities are critically important, but they also represent time not building out the product. And, of course, once those new hires join, the upward pressure on communication costs increases even further.

By the time I left Quora and Ooyala, they had both grown to over 70 employees. Like most other companies their size, responsibilities had been divvied across more people and more teams. While some local decisions could still be made quickly, larger ones often required meetings to coordinate with multiple stakeholders.

At larger companies, the costs of communication spiral even further. You might have to coordinate available times for multiple teams to make progress on a project. You might have to walk over to a different office building for a meeting. Or you might even have to fly to a different city or video conference with remote teammates.

The increased friction of communication means that sometimes, communication that should’ve happened — and that would’ve happened when the company was smaller — fails to happen. Michael Lopp, the Head of Engineering at Pinterest, makes a similar observation in his book, Managing Humans, “At an organizational size that varies for every team, natural cross-pollination and communication activities that used to happen organically, that allowed for cultural and strategic work to get done, and that allows for big decisions to be made, can no longer occur.” ²

Reducing the costs of communication

As a company’s ambitions and opportunities grow, so too does its team in order to meet the challenge. Google and Facebook are able to tackle problems at a scope and scale that a small startup can’t, partly because of their size and resources.

But given the high costs of communication, anything that we can do to reduce those costs is extremely high-leverage. So how might we reduce our communication costs? Here are some strategies:

• Hire high-performers. If you can hire fewer engineers, each of whom is a high performer, the total amount of communication required to coordinate projects stays lower. Each person can spend a greater fraction of his or her time getting things done. The leaner that you can keep your team while still having enough resources to face your key problems, the more effective each engineer will be.

• Invest in onboarding. To the extent that you’re growing your team, onboarding represents a powerful leverage point for providing new hires with the context they need to get things done and make the right decisions. Ensure that every new engineer gets exposed to core abstractions, development tools, operational processes, and business goals so that you can reuse that context for later decisions and conversations.

• Invest in tooling to reduce the friction of communication. When it comes to tooling, speed and ease of use matters — the easier it is to communicate, the more people will use it. Make sure you have good tools to share status updates, exchange feedback on code reviews, follow up on bugs and customer issues, and communicate other information. I’m personally excited now to be working at Quip because we’re building a new class of productivity tool that actually makes it easy (and delightful) for teams to communicate and share information. We power thousands of companies, including Facebook, Pinterest, Stripe, Quora, New Relic, Instacart, and others — go check it out if you’re looking for good communication tools.

• Replace in-person meetings with asynchronous communication when possible. Some amount of face time during 1:1s and in-person meetings will always be necessary, but oftentimes meetings get scheduled with ill-defined agendas. Or they recur every week and the information exchanged could’ve easily been replaced with a collaborative document shared with the team. Asynchronous discussions are less disruptive, have less overhead, and allow teammates to stay focused in flow for longer periods of time. Reserve your meetings for high-bandwidth discussions where synchronous, in-person conversations actually matter.

• Make use of lightweight and informal design documents to share information. Writing a short design document is a great way to convey information and solicit feedback. It often consumes less total time and energy than holding an informational meeting, and it can be a much shorter route to feedback than requesting feedback after you build something. The design documents also end up being a valuable repository of knowledge for onboarding future team members. If communicating an idea or a plan can be lightweight and not involve a multi-person meeting, people are significantly more likely to share information as a normal part of their workflow.

• Build a culture of highly aligned, loosely coupled teams. Reed Hastings attributes this philosophy as one of the key aspects of Netflix’s culture that has allowed it to succeed. ³ When strategies and goals are well-defined and understood, you can reduce cross-functional meetings and trust that teams still remain aligned. One way to do this is to identify the core business metric that everyone should be focusing on. It’s when team alignment is off that people end up expending their energy negotiating priorities with other teams, trying to get others to unblock their projects, and keeping tabs on progress.

At every stage of a team’s growth, lower communication costs mean that you’ll spend less time and energy on coordinating efforts and more time actually getting things done. Don’t let those costs get out of hand.