While proficient engineering managers possess coding skills, exceptional ones excel in communication as well.
Written communication, in particular, is crucial for managing and expanding engineering teams, according to Juan Pablo Buritica, who has spearheaded numerous successful engineering teams, most notably as VP of Engineering at Splice, a music company.
Experts like Buritica recognize that as engineering teams grow, their workflows, processes, decision-making rhythms—even project strategies—must adapt. Systems effective for a two-person team may not suit a team of 40, and processes efficient for a co-located team might falter in a distributed setting.
To effectively grow and scale engineering teams, Buritica recommends establishing a repository of practices, documented and stored accessibly for all, whether it’s a Google Drive or a knowledge management platform like Confluence or Guru.
By generating these documents and encouraging team members to contribute their insights, Buritica not only expanded his team at Splice from five to 50 members in 18 months but also slashed product delivery time from six months to a mere six weeks.
Here’s his three-pronged approach to leveraging written communication for enhanced engineering team performance:
1. Establish Communication and Decision-making Frameworks Early On
Communication and decision-making frameworks are essentially blueprints outlining a team’s operational procedures. Their complexity can range from simple to intricate, depending on the issue at hand. Documents concerning communication might be straightforward, while those outlining strategy could be more elaborate. Regardless, their creation is vital, no matter the team’s size, ensuring processes and guidelines are documented before the group becomes too large.
One fundamental document Buritica emphasizes is what he terms a communication architecture: a set of rules dictating how the team communicates—be it through Slack, Microsoft Teams, email, phone calls, or Zoom—along with expectations regarding response times.
For instance, imagine an engineering team finding late-night Slack messages disruptive. In the communication architecture, Buritica would specify how engineers should respond to after-hours pings. They might agree that Slack messages after 6 PM don’t warrant immediate responses, reserving texts or calls for emergencies.
To reach such a solution, Buritica starts by surveying the team: “How should we communicate with each other? How do we convey our availability? What isn’t working? What can we improve? How should we handle emergencies?”
“Everyone can offer suggestions, which I then consolidate into a draft proposal,” he explains. “As a team, we discuss, implement, and pilot it.”
Following the initial draft’s publication, the team operates within the proposed framework for several weeks to assess its effectiveness. Over time, they integrate necessary adjustments into the document until it accurately reflects their standard operating procedure.
As another example, Buritica implemented a strategy document at Splice to define how the engineering team would achieve its business objectives. Their goal was to expedite product delivery by shipping software faster, which necessitated reducing friction. The strategy document outlined the necessary steps, “and we began piloting, testing, reporting, and discussing our ideas,” he says. “Everyone contributed to the document and became truly motivated.” Ultimately, they attained their goal, shrinking delivery time from six months to six weeks.
The process of documenting these procedures mirrors that of creating other types of documentation, except it tends to be less formal. “I find that English can become unnecessarily complicated with formal communication,” he observes. “Clarity is lost. Processes should be written in a very accessible manner: simple language, short words, bullet points, outlines, and lists.” Most importantly, these documents are collaborative, allowing anyone to propose changes and access them at any time.
How does he foster trust in these documents? “I use them myself,” he states. “I live by the processes I outline. If I don’t utilize them, how can I expect anyone else to?”
2. Empower Team Ownership of the Documents
The team’s involvement shouldn’t end with the documents’ creation; they should also participate in their evolution. “The engineers are the ones who utilize these processes and information,” he points out. “The more closely they work with a document, the greater ownership they should have over it.”
This requires managers to be comfortable with teams challenging the information presented. Empowering the team to make changes fosters trust and enhances problem-solving. “For instance, if the decision-making process isn’t functioning as intended, we need to debug it collectively,” he explains. “As the manager, I can’t simply instruct them to ‘start making better decisions.’”
Relinquishing authority for authority’s sake and being receptive to the team’s ideas is paramount. “I appreciate those who challenge me in meetings, pose tough questions, and encourage others to do the same,” he says. “For example, in one document, I stipulated that pull requests should be merged within 36 hours. One engineer questioned the reasoning behind the 36-hour timeframe and presented a compelling case for adjustment.”
While the team collaborates on each document, one individual should be designated as the steward, responsible for maintaining its clarity of purpose and vision. For instance, a document outlining recruitment practices would have the team member in charge of recruitment as its steward. The remaining team members would be welcome to collaborate and suggest updates as needed.
For smaller teams, Buritica grants editing rights to everyone. In larger groups, he limits editing privileges to a select few, though suggestions remain open to all. Should conflicts or disagreements arise, the manager makes the final call. “These documents are not meant to be democratic or driven by consensus,” he clarifies. “Unanimity isn’t the goal.”
“If someone proposes we only work two hours a day, the engineering manager should obviously veto that. It’s absurd,” he states. “While the creation and maintenance of these documents are collaborative processes that encourage participation, they are not democracies. Ultimately, the engineering manager bears the responsibility for the team’s productivity, well-being, and smooth operation. The final decision rests with them.”
3. Enhance Existing Frameworks to Facilitate Team Scaling
Decision-making frameworks become even more crucial in distributed team settings.
“When you’ve mastered remote collaboration—whether due to physical or cultural distance—and know how to leverage these frameworks, scaling becomes smoother, even when hiring globally,” Buritica asserts. These documents can be instrumental in onboarding new members swiftly and replicating success.
“Back when we were a five-person team and I was hiring, I had an informal document outlining first and second-stage interviews,” he recalls. “It wasn’t very detailed since I conducted the interviews personally. However, when I needed another manager to take over, I had to clearly define the interview’s purpose and what constituted success.”
Consequently, he elaborated on the document. “The manager then used it, conducted interviews, and eventually modified it based on what worked and what didn’t. Over time, it transitioned from being my document to becoming the team’s document. It’s an ongoing evolution.”
Today, with a team of 50, that document has expanded to encompass processes for screening, technical discussions, and introductions to existing team members. “It now includes a rubric, blind reviews, and greater refinement,” he notes. “It’s reached the next level, making it easier for those outside the process to comprehend.”
The Future of Work Is Written
For all these reasons, Buritica prioritizes written communication skills when leading a team.
“Can you communicate effectively in writing? I’m not assessing grammar skills—English isn’t even my first language. I want to gauge a candidate’s ability to convey their message and exert influence,” he explains. Every team member should hone their writing skills to contribute effectively to communication frameworks.
“Beyond the future of work being remote, I believe it will be heavily reliant on writing, regardless of physical location,” he affirms. “I encourage every engineering team to embrace writing. It fosters collective thinking, group decision-making, learning, and growth.”