While good engineering managers can code, great ones can also communicate.

书面交流, 具体地说, is integral to the management and scaling of engineering teams, 说 胡安·巴勃罗·布里蒂卡, who has led several successful teams of 工程师, most recently as VP of 工程 at the music company Splice.

Experts like Buritica know that as engineering teams grow, 工作流, 流程, decision-making cadences—even the project strategies—also change. 适用于两人团队的系统不一定适用于40人的团队, 而且，对于位于同一地点的团队有效的流程可能不适用于分布式团队.

To grow and scale engineering teams successfully, Buritica suggests creating a library of practices, written and stored somewhere accessible by all, 是否 谷歌驱动 或者一个知识管理工具，比如 融合 or 大师.

通过创建这些文件，并鼓励他的团队成员加入他们自己的想法，buritica不仅能够在18个月内将Splice的团队从5人扩大到50人，而且还能将产品交付时间从6个月缩短到6周.

以下是他使用书面沟通来提高工程团队绩效的三步策略:

1. Create Communication and Decision-making Frameworks From Day One

沟通和决策框架是指定团队将如何运作的文档. They can be simple or complex, depending on the nature of the issue. Documents about how to communicate may be straightforward, 例如, but those outlining a strategy might be more elaborate. 在所有情况下, 无论团队有多小，创建它们都很重要，以便在团队变得太大之前记录过程和指导方针.

One of the foundational documents is what Buritica calls a 通信体系结构: rules about how the team communicates—whether via Slack, 微软团队, 电子邮件, 电话, and/or Zoom—and expectations around response times.

例如，假设一个工程团队发现Slack上的深夜信息具有破坏性. 在通信体系结构中, 布里蒂卡将详细说明，如果有人在下班后发出信号，工程师应该如何回应. 也许大家都同意，在下午6点之后，任何人都不应该回复Slack的信息. If a situation is an emergency, the protocol may recommend a text or phone call.

得到这个解, 说Buritica, 第一步是就这个问题对团队进行调查:“我们应该如何相互交谈? 我们应该如何沟通我们的可用性? 什么不起作用? 怎样才能更好地工作? 我们应该如何处理紧急情况?”

“Everyone is given the ability to provide suggestions, and I will come back with a draft of consolidated proposals,他说. “n as a team we discuss it, roll it out, and pilot it.”

在他出版初稿之后, 团队在建议的框架内操作几周，以评估新流程的工作情况. 随着时间的推移，他们将其他必要的更改集成到文档中，直到它定义了标准操作.

作为另一个例子，Buritica创建了一个 战略文件 来描述工程团队将如何满足其业务目标. The goal was to accelerate product delivery by shipping software faster, which meant the team needed to reduce friction. The 战略文件 outlined the necessary steps, 我们开始驾驶, 测试, 报告, 谈论我们的想法,他说. “Everyone started contributing to the document and became really motivated.最终，该团队实现了目标，将交货时间从6个月缩短到6周.

编写这些过程与创建其他类型的文档没有太大的不同, 只不过他们往往不那么做作. “我认为，当你开始使用正式交流时，英语有时会变得过于复杂,他说. “它失去了清晰度。. 流程应该以一种非常有用的方式编写:简单的语言和短音节的单词, 用项目符号, 概述了, 和列表.最重要的是, 它们是协作文档，使每个人都可以提出更改建议，并且任何人都可以随时使用它们.

How does he get people to trust the documents? “我使用它们，”他说. “我活在自己的过程中. If I don’t use them, how else can I expect someone else to do so?”

2. Allow the Team to Take Ownership of the Documents

团队不仅要参与文档的创建，还要参与文档的发展. “ 工程师 are the ones that use the 流程 and information,他说. “ closer they are to the document, the more they should take ownership of it.”

这意味着管理者必须适应团队对信息的质疑. 允许团队进行变更，增强他们的能力，建立信任，并增强解决问题的能力. “例如, if the decision-making process isn’t functioning, 然后我们需要集体调试,他说. “As the manager, I can’t just say, ‘Please start making better decisions.’”

为了权威而放松权威，并对团队的想法持开放态度是至关重要的. “I appreciate people who challenge me in meetings, 问困难的问题, 并鼓励其他人也这样做,他说. “例如，我在一份文件中写道，我们应该在36小时内合并pull请求. 我的一位工程师问，‘为什么是36小时?他提出了一个改变现状的理由.”

While the team collaborates on each document, 应该有一个人作为管家，他的工作是维护该文档的明确目的和愿景. 一份概述招聘实践的文件将由负责招聘的团队成员作为其管家, 例如. 团队的其他成员将被邀请合作，并根据需要提出更新建议.

If it’s a small team, Buritica gives edit rights to everyone. 如果是一个更大的群体, he keeps edit privileges to only a few team members, 虽然任何人都可以提出建议. Should conflicts or contradicting opinions arise, the manager decides. “ document isn’t intended to be democratic or a consensus,他说. “不是每个人都必须同意.”

“如果有人建议我们每天只工作两小时，工程经理显然应该拒绝. 这太荒谬了，”他说. “这些文件的创建和维护是一个让人们参与的协作过程, 但这不是民主. 最终，工程经理对团队的生产力负责, 它的幸福, 正常运作. 他们有最终决定权.”

3. Increase the Sophistication of Existing Frameworks to Scale Teams

Decision-making frameworks are even more important when teams are distributed.

“如果你学会了如何远距离工作——无论是物理上的还是文化上的——你就知道如何使用这些框架, 这样更容易成长得更快, even if you’re hiring people all over the world,布里蒂卡说. The documents can be used to bring more people on quickly and replicate success.

“When we were a team of five and I was hiring someone, 我有一份非正式的文件，上面有第一阶段面试和第二阶段面试的信息,他说 “It didn’t have a lot of detail because I ran the interview myself. But when I needed a manager to take on those interviews, 我必须更好地定义面试的目的，以及成功的样子.”

所以，他把文件写得更详细了. “n that manager went through the process and tried the interview, and she eventually modified what I’d written, 注意到什么有效，什么无效. Over time, it stopped being my document and started being the team’s document. 它还在继续进化.”

今天, 作为一个50人的团队, that document has grown to include 流程 around screening, 进行技术对话, 和现有的团队成员见面. “re’s a rubric, blind reviews, and more polish,他说. “这是层次. 人 who are external to the process can understand it better.”

工作的未来已被书写

For all of these reasons, Buritica prioritizes written 沟通 他领导团队时的技巧.

“Can you communicate well in a written medium? I’m not assessing someone’s ability to be grammatically correct. 英语甚至不是我的母语. 我想知道的是，候选人是否能够表达自己的观点，并具有影响力。. 每个团队成员都应该磨练他们的写作能力，这样他们才能有效地为沟通框架做出贡献.

“不仅仅是未来的工作是遥不可及的, 我认为工作的未来是注定的, whether you’re in the same physical location or not,他说. “I would encourage every engineering team to write more. It can help your team think collectively, decide as a group, learn, and grow.”