Skip to content
Engineering Investment and Business Alignment

Scaling Engineering Teams: Learning from Others

At various points in a company lifecycle, businesses will require their teams to rapidly grow headcount. Whether you’re a part of a startup that has recently received funding or you’re an established team with an ambitious growth forecast, you’ll find yourself as an engineering leader needing to hire aggressively to keep pace with the business trajectory.

But not all growth challenges are solved by hiring alone. As teams hire more, they also need more structure put into place. As time goes on, the business might perceive its engineering team as working slower than it used to, even when your team is more efficient and productive than it’s ever been before. 

This is because scaling engineering teams is not just about managing people growth; it’s about finding ways to mature the people strategy, processes, and technologies through all the stages of a company’s lifecycle. In this post, we’ll examine a few top recommendations for how to scale effectively from highly respected technical leaders. 

Communicating with Engineering Teams Through Growth

Let’s consider the typical scenario of a head of engineering at a startup with ten engineers. When you are a team of less than ten, you meet with everyone regularly and know everything that is going on. Through regular meetings and casual conversations, you have all of the context needed to make leadership decisions. But as your team grows to twenty-five people, then fifty, and one hundred, you lose levels of detail very quickly. Evan Klein has written previously about the various stages of engineering teams and how they will impact the way you manage your teams. 

You still need to stay updated and communicate with your team, but you cannot be in every meeting. As you become more reliant on middle management, it becomes increasingly important to flag when communication is unclear. Zak Islam, VP of Engineering at Atlassian, discussed this last point in his recent conversation with Andrew Lau about scaling engineering teams at Plato Elevate. He detailed specific examples of why it’s important to always communicate why, not just what, work needs to be done.  

If your teams are not clear about “the why,” they’re never going to unlock their creativity. You end up seeing a bunch of symptoms. It could be seen as a lack of velocity, [or] it could be seen as your teams not aligned. But you know what it was? I wasn’t communicating the right things. I was telling the teams to ‘go.’ The teams didn’t know why they were going.

Zak Islam
VP of Engineering at Atlassian

(Watch the full presentation here)

The channels through which you communicate “the why” are also critically important. Whether through video or written communication, leaders like Zak agree that varying your communication methods ensures higher retention of messages.  

We always talk about people, process, and technologies to help scale across dimensions. Technology has played a huge role. The reality is not everyone consumes blogs. Not everybody is capable of consuming an asynchronous blog. Some people love watching videos. We’ve had to switch away from one method of communication to communicating the same message with our teams through all kinds of different channels. Not everybody can consume and retain information through the same medium.

Zak Islam
VP of Engineering at Atlassian

(Watch the full presentation here)

Once you identify what needs to be articulated more clearly, continuously repeat your message through your various channels. To summarize Zak’s concluding points on communication: Repeat your message, encourage questions, and reward curiosity.  

Scaling Engineering Team Processes 

A key question during the growth phase is what processes will need to change to scale engineering in the future. During an ELC event session, Naveen Gavini, Head of Design and UX at Pinterest, discussed the early days of Pinterest and the approach they took to identify process change requirements. 

Keep your process appropriate to scale. When done right it can make you very efficient but when done wrong it can cause a lot of hurdles. [W]hen your team is small and nimble, it’s better not to force these things, see what happens organically, and then as you kind of scale, start to standardize those processes across your teams. Forcing synergization early on actually has a lot of negative effects. It generally slows things down and causes a bit of rejection from the team.

But with process, the only thing that is constant and permanent is change. So knowing that whatever you set today, you’re going to have to revisit in 3-6 months. [This] is something that you should just know going in and embrace.

Naveen Gavini
Head of Design & User Experience at Pinterest 

(Watch Naveen’s full ELC presentation here)

It’s critical to change your process as it’s necessary, not preemptively just because you’re growing. When signals arise that a process change is required, lean into it. And if you’re examining processes frequently, that’s expected at this stage too.

Evolving the Scaling Conversations

The good news is that we don’t have to face these challenges of hypergrowth alone. We’re fortunate that we have a number of resources and engineering leaders to reference that have gone through the hypergrowth process before. As we identify helpful advice on how to scale engineering teams, we’ll continue to share it with the broader community. Over time we hope to expand the scope of conversations about scaling engineering teams to encompass all aspects of the people, process, technology, and culture that require adaptation.