GitPrime elevates engineering leadership with objective data. In this interview series, Engineering Leaders talk about how to build high performing teams.

Communication appears easy when your entire company fits in a single room. When you can grab a drink at the end of a day. When you don’t even have to label your lunch in the communal fridge.

But it’s a challenging beast to keep a development team communicating efficiently (or at all) as it scales beyond its garage-band origins.

We chatted with Allan MacGregor for some strategies for promoting communication in a scaling company. Allan joined forces with Demac Media when they were less than ten people. Now, the agency employs more than 100, almost doubling in size from just two years ago.

As Director of Engineering, MacGregor facilitates the communications between almost 60 engineers on a daily basis. Some of his strategies work all the time, and others require constant evolution as his team continues to scale.

Here, he shares his takes on opening channels of communication between engineers, and ensuring fluid communication between management and development—what works, what doesn’t, and what has had to change.

That small-team feel

When Demac cleared 20 people, MacGregor noticed that sharing between team members became a logistical problem.

So as part of the company’s growth strategy, they developed a methodology for sharing knowledge with a small-team feel.

“First we divided our development and engineering teams into small groups that we call ‘stacks,’” MacGregor says. These smaller working units enable stack members to draw on each other’s knowledge without having to navigate a larger company structure, and each stack gets to specialize in a specific aspect of product development.

These stacks work well—to a point. “Unfortunately,” MacGregor says, “in the last year we’ve seen the drawback: you start to unintentionally build silos in your teams.”

Because these stacks insulated from each other, Stack A may end up handling problems differently than Stack B. When there’s only two stacks, those differences can be pretty simply communicated. But when Stacks C through J each develop their own mini-culture, you end up with a communication breakdown between teams.

Good thing that MacGregor is unafraid of trying new approaches. “Right now,” he says, “we’re breaking away from that style to share more information.”

Essentially, these stacks have adopted a methodology from EOS called the “Level 10 Meeting” (PDF). The idea here is to focus on the teams’ main priorities and address any issues that arise—in other words, to open a consistent and collective channel of communication. MacGregor has weekly group check-ins with the senior developers from both the front-end and back-end teams.

“The advantage at the director level is that I get the ability to understand the day-to-day of those teams,” MacGregor says. “As a whole, the team gets to share a lot of their problems—and they get to solve them together.”

With this setup, the knowledge transfer between team leads happens effectively. MacGregor’s challenge is to provide the channels and the opportunity for resolution-driven dialogue to occur naturally between teams, rather than having to assign problems to people.

The other side of the tracks

Another long-running problem with the specialization within teams was that engineers got bored working with the same platform for several years. And while a developer’s linear progression on a single platform might lead to promotions, it doesn’t lead to innovation in design.

Now, the goal for MacGregor’s teams is to learn a second platform. The individual engineers have the chance to add specialties, and they are encouraged with milestones that offer a clear path to success.

“From the developer’s side and the area plan development, it’s great,” MacGregor says. “You open so many opportunities up for everyone.”

Depending on your existing culture, this shift from technology development to skills development may be jarring. He recommends rolling it out using a badge-oriented model. “The way you explain this thing internally is, ‘You’re no longer only a back-end Magento developer. Your badge goal is now Software Developer,’” he suggests. “Think about it like you’re a scout. We’re going to keep adding badges and specialties.”

And there’s a bonus—as your wider team gains fluency in multiple platforms, communication between stacks becomes ever easier.

Powerful feedback loops

The key to effective communication in MacGregor’s world is having engaged engineers. As he puts it, “Team members who are challenged to grow are happier, perform more efficiently, and integrate more fully with their peers.”

He relies on several feedback loops to stay up-to-date on individual developers’ performance and satisfaction as the company continues to scale. (Spoiler alert—these all hinge upon open and honest communication.)

Monthly one-on-ones. “In these, I ask, ‘Hey, are they are any issues? Anything you want to scale?’ They’re basically check-ins,” MacGregor says.

Six-month performance reviews. These entail a more complete, 360-degree view than the monthly one-on-ones. “These include information about quality performance and peer reviews,” he says. With these get-togethers, both MacGregor and the individual engineers can be certain they’re still contributing positively as the company scales.

Career development. Also on a six-month schedule—MacGregor incorporates this aspect into the performance reviews —developers set goals that align with their career path development, their interests, and what the company needs from them. That way, everyone involved can touch base on how the company/employee relationship benefits both sides, from a broader perspective than evaluating single projects.

Weekly feedback. MacGregor uses a tool called Officevibe. “Essentially, every employee in the company, at all levels, gets asked how they are feeling once a week,” he explains. “Are you satisfied? Do you have a good relationship with your manager? So, it’s more on the HR side than the technical side, but we have it broken down by departments. We can say, hey for whatever reason this week, my back-end developers are now unhappy. Did something happen? Did a project go sideways? Whatever might be the case, we can go back and look into that.”

The specific time frames of these confabs are perhaps less important than establishing the dialogue with individual engineers on a reliable and recurring basis. It’s important for them to know that their input will be heard and their personal interests taken into account. Done reliably, these frank conversations become part of your culture.

And that’s why it’s never too early to initiate these recurring sessions. “I would like to say that we formalized that stuff right from the get-go,” MacGregor says. “That only happened in the last year. But we’re already seeing a lot of progress, a lot of better communication and organization across departments.”