Engineering Management
6 minute read

The Importance of Written Communication for Engineering Teams

Stephanie Emma Pfeffer
Stephanie is a sought-after writer for bestselling publications, including New York Magazine.

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

Written communication, specifically, is integral to the management and scaling of engineering teams, says Juan Pablo Buritica, who has led several successful teams of engineers, most recently as VP of Engineering at the music company Splice.

Experts like Buritica know that as engineering teams grow, the workflows, processes, decision-making cadences—even the project strategies—also change. The systems that work for a team of two people do not necessarily work for a team of 40, and the processes that are efficient for a co-located team may not work for a distributed team.

To grow and scale engineering teams successfully, Buritica suggests creating a library of practices, written and stored somewhere accessible by all, whether a Google Drive or a knowledge management tool like Confluence or Guru.

By creating these documents—and encouraging his team members to add their own ideas—Buritica was able to not only grow his team at Splice from five people to 50 in 18 months but to cut his product delivery time from six months to six weeks.

Here’s his three-step strategy for using written communication to improve engineering team performance:

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

Communication and decision-making frameworks are documents that specify how a team is going to operate. They can be simple or complex, depending on the nature of the issue. Documents about how to communicate may be straightforward, for example, but those outlining a strategy might be more elaborate. In all cases, they’re important to create no matter how small the team so that the processes and guidelines are recorded before the group gets too large.

One of the foundational documents is what Buritica calls a communication architecture: rules about how the team communicates—whether via Slack, Microsoft Teams, email, phone calls, and/or Zoom—and expectations around response times.

For example, say an engineering team finds late-night messages on Slack disruptive. In the communication architecture, Buritica would detail how engineers should respond if someone pings them after-hours. Perhaps it’s agreed that no one is expected to answer a Slack message after 6 PM. If a situation is an emergency, the protocol may recommend a text or phone call.

To arrive at this solution, says Buritica, the first step is to survey the team about the issue: “How should we talk to each other? How should we communicate our availability? What isn’t working? What can work better? How should we deal with emergencies?”

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

After he publishes the first draft, the team operates within the suggested framework for a few weeks to evaluate how the new process is working. Over time they integrate other necessary changes into the document until it defines standard operation.

As another example, Buritica created a strategy document at Splice to describe how the engineering team was going to satisfy its business objectives. The goal was to accelerate product delivery by shipping software faster, which meant the team needed to reduce friction. The strategy document outlined the necessary steps, “and we began piloting, testing, reporting, and talking about our ideas,” he says. “Everyone started contributing to the document and became really motivated.” Eventually the team achieved its goal, reducing delivery time from six months to six weeks.

Writing these processes is not so different from creating other types of documentation, except they tend to be less stilted. “I think English sometimes gets overly complicated when you start using formal communication,” he says. “It loses clarity. Processes should be written in a very usable way: simple language and short-syllable words, with bullet points, outlines, and lists.” Most importantly, they are collaborative documents that enable everyone to suggest changes and are available to anyone at any time.

How does he get people to trust the documents? “I use them,” he says. “I live through my own process. 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

The team has to have a hand in not only the creation of the documents but also in their evolution. “The engineers are the ones that use the processes and information,” he says. “The closer they are to the document, the more they should take ownership of it.”

That means managers have to get comfortable with teams questioning the information. Allowing the team to make changes empowers them, builds trust, and enhances problem-solving. “For example, if the decision-making process isn’t functioning, then we need to debug it collectively,” he says. “As the manager, I can’t just say, ‘Please start making better decisions.’”

It’s crucial to ease up on authority for the sake of authority and to be open to the team’s ideas. “I appreciate people who challenge me in meetings, ask difficult questions, and encourage others to do the same,” he says. “For example, in one document I wrote that we should be merging pull requests in 36 hours. One of my engineers asked, ‘Why 36 hours?’ and he built a case for changing that.”

While the team collaborates on each document, one person should be the steward whose job is to maintain a clear purpose and vision for that document. A document that outlines recruiting practices would have as its steward the team member who is responsible for recruiting, for example. The rest of the team would be invited to collaborate and suggest updates, as needed.

If it’s a small team, Buritica gives edit rights to everyone. If it’s a larger group, he keeps edit privileges to only a few team members, though anyone can make suggestions. Should conflicts or contradicting opinions arise, the manager decides. “The document isn’t intended to be democratic or a consensus,” he says. “Not everyone has to agree.”

“If someone suggests we only work two hours a day, the engineering manager should obviously say no. That’s ridiculous,” he says. “The creation and maintenance of these documents is a collaborative process that gives participation to people, but it is not democracy. Ultimately the engineering manager is responsible for the productivity of the team, its well-being, and proper functioning. They have the final say.”

3. Increase the Sophistication of Existing Frameworks to Scale Teams

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

“If you learn how to work at a distance—whether it’s physical or cultural—and you know how to use these frameworks, it’s easier to grow faster, even if you’re hiring people all over the world,” Buritica says. 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, I had an informal document with information about a first-stage interview and a second-stage interview,” he says “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, I had to better define the purpose of that interview and what success would look like.”

So, he made his document more detailed. “Then that manager went through the process and tried the interview, and she eventually modified what I’d written, noting what was working and what wasn’t. Over time, it stopped being my document and started being the team’s document. And it continues to evolve.”

Today, as a team of 50, that document has grown to include processes around screening, having technical conversations, and meeting existing team members. “There’s a rubric, blind reviews, and more polish,” he says. “It’s next-level. People who are external to the process can understand it better.”

The Future of Work Is Written

For all of these reasons, Buritica prioritizes written communication skills when he leads a team.

“Can you communicate well in a written medium? I’m not assessing someone’s ability to be grammatically correct. English isn’t even my first language. I want to know if a candidate can get their point across and have influence,” he says. Every team member should hone their writing abilities so they can effectively contribute to communication frameworks.

“More than the future of work being remote, I think the future of work is written, whether you’re in the same physical location or not,” he says. “I would encourage every engineering team to write more. It can help your team think collectively, decide as a group, learn, and grow.”

Understanding the basics

To grow and scale teams successfully, create a library of practices, written and stored somewhere accessible by all, whether on a Google Drive or in a knowledge management tool like Confluence or Guru.

As teams grow, the workflows, processes, decision-making cadences—even project strategies—also change. Communication systems that work for a team of two people do not necessarily work for a team of 40, and the processes that are efficient for a co-located team may not work for a distributed team.

To improve written communication skills, use simple language and short-syllable words, with bullet points, outlines, and lists.

To effectively communicate as a team, use collaborative documents that enable everyone to suggest changes and that are available to anyone at any time

Teamwork communication, especially written communication, is integral to the management and scaling of workplace teams.

Written communication can help your team think collectively, decide as a group, learn, and grow.

Good written communication skills in the workplace include the ability to convey a point and have influence. Every team member should hone their writing abilities so they can contribute to communication frameworks effectively.