Engineering teams play a significant role in maximizing a startup’s success from its earliest stages—any misstep in the structure or strategy can significantly hamper growth. And once growth takes off, you’re faced with the challenges of scaling engineering teams.

To learn best practices on scaling engineering organizations, we hosted a fireside chat with three industry veterans:

• • Ohad Parush – Chief R&D Officer at Gong, the global leader in revenue intelligence. Ohad helped scale Gong’s engineering org 10x from 30 to 300+ engineers. He has 25 years of experience managing large R&D teams at companies such Akamai and Imperva.
  • Sri Ramalingam – Head of Engineering at Harness, the leading intelligent continuous integration, continuous delivery (CI/CD) and software delivery platform. Sri has scaled the Harness engineering org 5x to over 400 people and leads 7 modules in production. He previously led Zoom’s platform engineering team during their massive growth from 2014-2019.
  • Einat Orr – Co-founder & CEO of Treeverse, the company behind lakeFS, an open-source platform that delivers a git-like experience to object-storage-based data lakes. Before founding Treeverse, Einat built R&D organizations and led the technical vision at multiple companies, most recently scaling the engineering org from 0 to 200+ people at Similarweb as CTO from 2014-2019.

Five key lessons from our fireside chat that we unpack in more detail below:

1. Give people ownership

2. Organize teams in pods of 2-10 people

3. Define culture early

5. Embrace hybrid work

6. Minimize use of contractors

“What are some lessons on scaling engineering teams from 10 to over 300 people?”

Ohad: People like to have responsibility and feel like they’re contributing to what’s being done. To retain this feeling, we work in small pod structures, with each pod owning a specific feature or product. Each pod is almost self-sufficient, in the sense that there is a product manager, a UX designer, and a team of heterogeneous engineers that are working very closely.

Sri: We created a squad model similar to what Ohad calls a pod. The squads are small teams – two to 10 engineers – and everyone is located plus or minus three hours in a time zone, so you don’t have to wake up somebody in the middle of the night or have meetings during dinner time. Smaller teams mean we can move faster. One of the unfair advantages startups have is speed, and you don’t want to lose speed for any reason.

Einat: I also like cross-functional teams and small teams that can deliver. I would first define the process and then create an org structure that best supports that process. You need to create smaller processes within your architecture to allow more people to work in parallel. That is critical, because if you don’t scale the architecture together with a team you would probably not be getting the velocity you need. As much as I love cross-functional teams, if the teams involve people who are working on different components, that doesn’t contribute to velocity; it actually works the other way around.

People like to have responsibility and feel like they’re contributing to what’s being done. To retain this feeling, we work in small pod structures, with each pod owning a specific feature or product.  -Ohad Parush

“Is there a rule of thumb on when to build a centralized infrastructure team?”

Einat: As late as possible.

Sri: As you grow, you need to be careful about what I call the “island problem,” where your engineers start to focus on specific areas and lose a larger sense of how the product and the platform work. The good thing about a founding team of 20-30 people is that everybody’s working on pretty much the same thing, so if there’s a production issue everybody jumps in. When you get to phase two – where you have more products, are handling a lot of common core services, APIs and all that – it makes sense to introduce a dedicated platform engineering team.

Ohad: We have what we call “infrashifts,” in which every engineer takes a 1- or 2-week break from their day-to-day work and joins the core infrastructure team, led by our Chief Architect. This has been very successful because the engineers work with people they don’t otherwise see and learn how other things work. When they go back to their normal teams, they know much more.

As you grow you need to be careful about what I call the “island problem,” where your engineers start to focus on specific areas and lose a larger sense of how the product and platform work. When you get to a point where you have more products and are handling a lot of common core services (APIs, etc.), it makes sense to introduce a dedicated platform team.  -Sri Ramalingam

“Nurturing culture: how do you build it, articulate it, hire and fire for it?”

Ohad: The culture needs to go beyond R&D. There needs to be a company culture. They did an interesting thing at Gong; it happened before my time. They sat down and defined the Gong operating principles; the principles they aspire to. Coming from Israel, we have a concept of “no sugar” – we give you feedback right in the face; something Americans don’t usually do. Once it becomes the culture, it’s the way everyone speaks in the corridors. It’s interesting to see how new people coming into the company immediately get addicted to that culture. It’s always something I’m impressed to see.

Einat: The thing with culture is that it makes the decisions for you when you are not there. Whenever there is a void, the culture will make the decision. And this is why it’s very important. We have discussions to apply the culture, because it’s not enough to say, for example, we don’t sugarcoat anything. Let’s roleplay these situations where I’m really upset about someone harming production and I didn’t sleep all night and I need to have a good discussion about that. What is the way we have those discussions? What is the expected outcome? What are the processes that help us get to that culture? For example, we have a postmortem after every such problem. These are tools that help enforce and apply the culture.

The thing with culture is that it makes the decisions for you when you are not there. Whenever there is a void, the culture will make the decision.  -Einat Orr

“What’s your stance on remote and hybrid work?”

Ohad: The important thing we’ve learned is that reality changes and we as humans adapt. I remember that just a couple of weeks before COVID erupted, we sent out an email to all the employees to minimize the days they don’t come to the office, because we value working from the office. Then COVID erupted and our life changed. The first two or three months, it’s like a deer in headlights. How do we recruit? How do we onboard? Would it impact our ability to collaborate? But then slowly we found ways to do this. People found that Slack could be an effective way to communicate. And you can supplement with Zoom and WhatsApp communication. So we’ve changed our perspective. No one is thinking of going back to the office full-time; everyone is talking about working hybrid. People are able to have a better work/life balance, spend more time with their families. And when people come to the office, they actually value the energy they get from being around other people. So to me life is much better now than it was before. I don’t think we’ll ever go back. We have adjusted to the new reality.

Sri: The pandemic made us rethink how we operate. Providing flexibility is extremely important. Instead of every conversation becoming a Zoom meeting, we are moving to a more asynchronous means of communication. For example, if you want to review a design, you put it in a document and use asynchronous collaboration rather than holding a meeting every time. We are still not there completely yet, because it’s tough to get engineers to write. So, it’s more of a cultural shift. How you make the hybrid model work is a challenge. If you have five people in a room and three are on Zoom, the people in the room will always have a natural advantage. How do you break that and create a seamless hybrid environment?

We’ve embraced hybrid work. People are able to have a better work/life balance, spend more time with their families. And when people come to the office, they actually value the energy they get from being around other people. So to me life is much better now than it was before.  -Ohad Parush

“How do you balance building in-house versus using third-party vendors?”

Einat: It is extremely important to have the right model for using third-party vendors. I would use remote teams, not just one person. Then you have to do quite a lot of groundwork to make sure they feel some ownership and feel the culture. For example: sending people physically to sit with them, a lot of face-to-face on Zoom, or having a dedicated product manager for them. You want to have their deliverables presented as any other team in your organization; make them feel as if they are really a part of your team. If everyone around them behaves in a way consistent with the culture, then they would adopt the culture and become part of the company. I did it several times and it worked beautifully. But ownership is key, because the moment they don’t own anything, they become a person who does what they need to do and then goes home.

Ohad: We try to minimize usage of third parties or contractors, especially if they’re not in our main centers of excellence. We do use contractors in Israel, but we treat them like any other employee (except for equity). We have just opened a development center in Dublin, and we are applying two lessons that we learned from a failed effort in Romania. First, you need to have a strong site lead; someone that people can relate to and see as a leader. Second, they need to own something that is valuable for the company or the product. If you give them just the scraps or the stuff you no longer want to do, you won’t be able to retain good talent. So, we’re moving critical pieces of software over to them. It’s a risk, but either we do this or we don’t do it at all.

Sri: Getting contractors to work on your core codebase is always going to be challenging. We have adapted the contractor model so if there are peripherals you want to develop, use your API’s but don’t let them get into your core code. Give them bigger, logically independent components. There are some considerations you need to take; e.g. if you have federal business in the U.S., it becomes a bit more challenging because of audits and a higher level of scrutiny.

Getting contractors to work on your core codebase is always going to be challenging. We’ve adapted the contractor model so if there are peripherals you want to develop, use your APIs but don’t grant access to your core code. We’ve found that giving contractors bigger, logically independent components work best.  -Sri Ramalingam