_ Blog / Management

Scaling Distributed Engineering Team: Managing Fast Growth in Remote

by Gábor Zöld
/ January 8, 2020

#Management

Scaling Distributed Engineering Team: Managing Fast Growth in Remote (Interview with Juan Pablo Buritica, ex-VP of Engineering at Splice)

How would you scale a distributed engineering team?

It doesn’t involve just hiring more people, but also scaling communication, defining processes, making the culture strong enough and defining the vision, so you can build the new team on a solid foundation.

Scaling a distributed engineering team is a lot of work. It’s layers upon layers with no end.

This is exactly what Juan Pablo Buritica, ex-VP of engineering at Splice, did. More than once. He has years of experience managing engineering teams in rapid growth.

Fanni Karolina Tóth interviewed Juan in episode 7 of the Level-up Engineering podcast, where he explained the main challenges he faced as a tech leader, and he revealed his own process to successfully scale a distributed engineering team at Splice.

In the interview we're covering:

What is the biggest challenge when scaling distributed engineering teams?

Hiring Is Tough

The market for engineers is very competitive. A small company can't compete at the same market rate as big ones, especially in New York. You need to get creative in attracting and retaining candidates.

We’re all looking for opportunities to make our lives better, to help us grow, so we have an impact. Creating that was the first complex challenge.

Scaling Communications

The things you used to do as a small company, stop working as your engineering teams scale up. Delivery processes, the way you do project management, the way you communicate, and many other processes start breaking. Adapting and evolving these as you're growing was the second biggest challenge we had to solve.

Culture Is Key

Culture is related to both. When hiring, you need to have a vision of the culture you’re building, so you can sell it to potential hires. When it comes to growing your team, the culture and vision need to be strong, so you can scale the culture, the processes and have maneuvering space to evolve the organization.

What steps do you go through when scaling distributed engineering teams?

Make a Plan

First, you should pause and design the organization you're going to need. Whatever you expect, it's going to be wrong. But it'll be a roadmap you can follow and reiterate along the way. You need this, because bringing people on-board without a plan can hurt them and you as well.

Start Hiring

If you're building a web application, you need web developers with experience. It's different if you’re building a mobile application. So, having a blueprint of your company needs is important.

Create a light interviewing and recruiting process that isn’t a burden, doesn’t have too many steps, and helps you gauge the folks you're bringing in. You shouldn’t require the candidates to do non-standard or outdated things, like whiteboarding. Any friction you have in the process will prevent candidates from applying at scale.

Early on, a three-stage process with a light, technical exercise should be good enough. You want to make decisions quickly. You shouldn’t leave the process to hang, so be ready to give offers. Work with your recruiting or HR team as you're scaling, so you're making the process better every time.

On-boarding Is a Priority

If you're going to hire 50 people in a year, that’s four per month, and you need to be ready to on-board at scale. Build a remote onboarding process, then streamline the pipeline and have every new hire add to it, so the next person has a better experience. It’s more helpful than a light on-boarding documentation, with a 30-, 60-, and 90-day plan for everyone.

Assign a buddy, someone to help them understand and navigate the organization and the tech stack. Likely, there are many things undocumented at any point in any organization, so a buddy can help.

So, the first stage of scaling an organization is designing the process to bring people in, decide if they're the right people for the job, and set them up for success.

Make the Context Clear

The second stage is figuring out what everyone’s supposed to be doing and helping them understand the context. Set the goals and define what your people should know about the product, the existing tech stack, shortcomings, and the benefits. Help them ramp up, so they start taking ownership of it.

Organizational decision making in engineering companies tends to work best if people in the frontline understand the business and have ownership of the problems they're trying to solve. If they understand the metrics and goals, and how the product moves those numbers, you’ll often get elegant and helpful solutions that create a better experience for users.

Build the Processes

The third stage is evolving the organization, along with your people. With a five-person team, you don't have levels, career paths, growth frameworks, a feedback culture or performance review frameworks. As you start growing, you need to start shaping these at the same time.

If you let too much time pass before you put effort into this, it's going to hurt. People will feel underappreciated, like they're not growing, and they will not feel supported. At engineering organizations, the processes and the tools by which you deliver software need to grow and mature with the team.

At Splice, we used to have one staging environment for everyone. When we were five people, it didn't matter; we could use it at different times and test what we needed. When we were 50, the competition increased, so we defined a different solution. Once you've depended so much on a staging environment, you've built all the data and tests into it, so moving away from it takes effort. You should be ready to invest into your tooling.

What are the differences between scaling engineering teams from 5 to 25, and from 25 to 100?

You Need a Solid Base

The foundations and the structures by which you do your work need to be solid. There's a book called Scale that explains how organisms grow. Biological systems have figured out scaling by 10s of orders of magnitude, by trial and error.

You can look at their growth patterns and see that the infrastructure and communication channels need to scale before anything else happens. You need to be able to carry nutrients, information, waste and other things in and out. Organizations are the same.

Communication Needs to Scale First

The way you communicate has to be scalable. With a five-person team, you can brainstorm in a conference room, but when you're 25, that doesn't work anymore. So, either you specialize, choose five people, let's say make the leaders responsible, and they do the brainstorming.

The other way is to create a document for ideas everyone gets, so they can comment, and add their thoughts. It’s widely collaborative; it scales and it works, but it isn't in real-time.

The purpose of brainstorming is sharing ideas and refining rough wireframes that you may have to get to better solutions. If you're 50 or 100, you still only want 5 to 15 people who are responsible for one thing to brainstorm.

The next 80 may still want insight on the decision. They may not be responsible for the issue, but one of them may have solved a similar problem before, or they just want in “because we're one team.”

By having open processes in a team that operates with high trust, decisions happen in an open space, and people understand it may not go their way. They’ll get that someone else is responsible for making the decision, and it’ll work.

Project Management Is #2

Every aspect of how you do business needs to grow accordingly. Early on, you can manage your project in a smaller software. When you have 25 people, you need a more robust tool. When you're 100, different teams may need different tools.

What works for the individuals in the teams doing the work and what works for you, as a leader responsible for them, is different. At points, you have to make decisions that serve individual contributors; other times, you have to make decisions for yourself, the leader.

When I joined, we moved to a new project management software. We started using different task-tracking software as we started splitting into different projects. It worked. Some developer teams started using the same software, but in different ways. They had different workflows and adopted it to their own processes, as they should.

A Schedule Helps Management

Early on, teams had different sprint schedules. One team had a week sprint that started on Wednesday, another had a two-week sprint that started on Monday, and it worked with a couple of small teams. I would know what each of them was working on at any moment off the top of my head.

At a certain point, it became too much for me to know by heart.

Everyone had adopted the process in different ways, and it started breaking down. Then we started normalizing. We all agreed to start our sprints on Mondays, and we went onto the same schedule, because now we had seven or more teams. That allowed me to know the rhythm of the organization since everyone was moving at the same time.

We ship continuously, with continuous integration and delivery, so this doesn’t affect our deployments. But it helps me understand and organize the tempo of the team.

Recently, we started trying to be consistent on the states of the tasks and the way items are estimated, so we can make the organization more observable. Then I can look from the outside and see if we're taking on too much work, or not taking on enough without investigating and asking managers about every detail. That's another example.

Make All New Info Available

You need to communicate what is going on in the company. Someone may speak at a conference, skip a meeting or miss a memo. Important information needs to be broadcasted, so set up channels as early as possible to create a culture around where important communication goes and the way it's delivered.

We are in an era where all companies use real time chat, and they’re used more and more actively for doing work. That requires processes.

Creative work, especially deep creative work, like solving a problem or fixing a bug, requires focus, and keeping a part of your brain focused on the chat hurts. It reduces your focus, distracts you, and won’t let you do your best work.

At Splice, we have communication guidelines. You can ignore chat for an entire week, and you shouldn't feel like you had to be there. It’s hard to get everyone not to make decisions on chat, or if they do, find a way to communicate it broadly. The idea is that you don't need to be online all the time.

I'm the manager, so I should observe what’s going on all the time. Whenever there's something important, I'll send my people an email. My assumption is that in the next 24 hours, they’ll read it. This way, I know that my team and my organization will be in sync in 24 hours tops.

You can start or end the day reading your email. It’s for code reviews and pull requests. We expect engineers to support each other, help get the code out, and give feedback on the code.

Should being on the chat be an expectation? It helps in collaborating, but I always say work chat is for GIFs and fun stuff. Hopefully it's making work better, but the point is: it's not mission-critical. Most teams I’ve led have been distributed, and it worked well.

Many companies become distributed at some point, because you can’t fit in the same room, floor or office if you're in hypergrowth. If you rely on scalable communication, you’ll have an easier time as you grow than if you discuss stuff on your way to the kitchen. You need to set up the way you treat your communication channels from the beginning, and on-board people to them. It’s key, whether you are 5 people, 25, or 100.

How did you scale distributed engineering teams at Splice?

I think you can’t plan it all ahead. The first thing I’d say if you're about to scale a company to 100 people: don't do it.

If you need to, you should have an idea about the types of information that people have to have for their work. You should also have an idea about your preferred methods of sharing that information. My approach won’t work for everyone. I’ve scaled hybrid teams quickly a few times, so it comes naturally to me now.

Make Sure Everyone Knows Everything

Sometimes, folks follow me from my past teams, so it's easier in the new one because they know how I work. They help me organize the company in a certain way, so it's easier to bootstrap the culture.

Distributed teams force me to be deliberate with communication, and it’s important when scaling. I have to consider how people will understand the goals of the company. If I have a person who got sick, and fell completely out of sync, they may have missed important stuff.

I embrace the fact that my team isn't subject to every single remote meetings, so I have to plan to make the information accessible. If you’re scaling an engineering team, you need to understand what’s important to know for everyone joining the company to do their work. Give them the tools to become autonomous and to do great work without you carrying messages all the time.

Build a Story

I like being consistent with every candidate. I like narrating a story, so I build one for my pitch for any candidate. The key points are:

What’s your company’s purpose?
What’s the business objective?
What are your values?
Where are you trying to take your culture?

My story hits the main points, and we fill the holes with the questions. I explain the road so far, the plans for the next two years, and introduce the people they’ll be working with. People tend to be mostly interested in their teammates, and the rest of the people, especially at a smaller, 50-100 company, where you can still follow what others do.

6 Months In, Let Them Set Company Goals

After they’re on-boarded, and six months later they get comfortable, give them access to goal setting for the company. For instance: “There’s a strategy meeting every six months, this is how you apply your ideas, and this is how you learn about the decision.” Give them enough knowledge to become autonomous, and to shape the culture of the company, so it scales better.

How do you change a process while scaling distributed engineering teams?

That is the million-dollar question.

It’s easy when you’re small

It's relative and contextual to the size of your team or company. There’s less friction when you're 10 than when you're 50. When you're 5 or 10, you can talk to people directly every week, and it’s easier to repeat yourself.

Let’s say you want to start using feature branches instead of staging. With 10 people, you tell them to start using it and to come to you if they have questions. Maybe half the team will catch on, and the next week you can ask the rest specifically if they have any problems. In two to three weeks, everyone starts using it and stops complaining about the change.

Listen to Your People

When you're 50, you're not the person to tell your people if they should switch to another tool. You could host a staff meeting for 50 people, but that's expensive (you can do the math).

When scaling a distributed engineering team, you have a lot on your plate, so the message of the feature branches occupies a less important space. You're lucky if you get 50% of people to adapt to it. Convincing the other half and dealing with complaints is a lot of work. There’s always resistance.

This is why your role as a tech leader is to manage change. To deploy a change that impacts everyone requires building enough trust in the organization so they’ll follow you. You explain the problem, the possible solutions, listen to their input. Let them know your decision, the reason behind it, and leave the door open to choose another way, if the solution you choose doesn’t work out according to a predetermined metric.

Do It in Stages

Another way to go about it, is to have 10 people try it, and tell everyone else how it worked out. Give them training material and a process, then refine the process with their feedback, and deploy it for 20 more. Rinse, repeat, and always ask the next batch of people if they want in.

Every time you successfully implement it, you’ll gain advocates for the new way. Some want to be early adopters; others don’t want any change. It’s usually not an option, but you can leave them for last.

Eventually, with reasonable effort, you have converted the entire organization.

We've been good at piloting solutions for processes. We let people test solutions and report back on how it went. After a successful pilot, deploying anything across the team is easier.

Be a Politician

You should also give space for people to provide input on how the solution may affect them. It seems faster to get everyone in a $5,000 meeting and to tell them what they’re going to do. You may feel like you gave the order, and everyone will do it, then spend two months getting everyone to actually do it anyway.

If you accept it’s going to take two months, you can be a lot more successful doing it step by step. You're also building trust with folks, your people should know their insight matters.

Your job is to be a politician. Keep repeating the reasons for doing everything, the values of your company, how everything is going to be great, and how everything will be more efficient. You’re engineering yourselves. It helps.

What are your key takeaways from scaling distributed engineering teams?

I used to be at a company called Ride.com, which was the first team I had to scale quickly. We went from 2 to 40 in a year and a half. When I joined Splice, they expected not to grow fast. Splice aimed to be profitable quickly and thought the engineering team wouldn’t be more than 20 in two years. I said: “Sign me up!”

It’s a Lot of Work

Scaling an organization requires a lot of work with no tangible output. It’s about building a culture and processes; it requires a lot of attention, moderation, curation, and loads of conversations with humans. Humans can be exhausting with insecurities and all the stuff we bring with ourselves, because we're not machines.

As a leader, that falls on you. I’ve done it twice, and if I had to do it again, I may use some shortcuts, but it's going to be different, and still a lot of work. That’s the first takeaway. Looking back, it was worth it, because it was exciting. It’s rewarding when you get it to work well, and I'm proud of our team.

You’ll Get All the Complaints

When scaling distributed engineering teams, be ready for a lot of work, repetition, communication, convincing and loads of complaints. Some people have followed me through teams. We agreed that when they complain, I ask, “Do you want me to solve this?” If they say yes, I do, but then they have to look for something else to complain about. We just laugh at that.

I like complaints, because it's feedback as we're scaling. I've seen other leaders who can't deal with it.

Balance Seniors and Juniors

The second takeaway is to balance between people who have experience, whether it's managing developers or building technology. You need entry-level or early career people, whether engineers or engineering managers. You don't want people to be too convinced that their way is the only way, because in a new organization, you need to continuously shape that.

There are patterns we've identified as good frameworks. You can read about them in books like Camille Fournier’s Managers Path. But you have options, and you can get to the same outcome with a different path and a different skill set. You should strive not to create a homogeneous culture, but a place of learning with a scientific approach to building organizations.

It's also your responsibility to make space for new people. You shouldn’t hire senior talent all the time, because they won’t be excited to deal with a bug for the tenth time, but it may be exciting for a junior engineer. Teaching juniors will likely be an exciting challenge for a senior. You want to capitalize on these opportunities, as it creates a richer and more resilient team that scales better.

Have Fun

The last takeaway is to have fun. Don't take yourself too seriously, and remember, barely anyone gets to scale organizations. Again, it’s a lot of work, so you may not want to do it many times, but just enjoy yourself. That's what it's all about.

Is there any other advice you would add to scaling distributed engineering teams?

Have Some Empathy

For individual contributors who joined engineering teams that are scaling fast, be patient with the people who are trying to make it work. We can all use some empathy. I've seen a lot of exasperation and frustration towards management, as we’re also figuring things out.

We're humans as well, we're in this together, and some support makes our job a lot easier. Management isn’t always in a position to discuss complex challenges. At times, like a clown, we show up to a 1-on-1 with a smile painted on our face, even though we have a nuclear disaster going on.

Learn Like Your Life Depends on It

For leaders who take the leadership path from technical careers, we need to recognize that we're starting from scratch when we switch careers to engineering management. We have to devote the same attention to building organizations and supporting systems for people, because this is our job and our responsibility.

About Juan Pablo Buritica

I live in New York. I was born in Colombia. In the last 10 years, I've been working for tech companies of different industries. I've worked for a ride-sharing app, a comics app, an advertising platform, and most recently a music company.

I’m currently a VP of Engineering at Splice, a fast-growing music creation platform.

(Editor's note: Since the time of the interview he left Splice, and is currently on a break.)

Juan returned for a panel discussion on the 2020 software development trends.

Let's build awesome things together 🚀

At Apex Lab, we're experts in end-to-end digital product development. Our remote-first company operates with a flexible schedule, allowing us to help clients tackle difficult challenges worldwide.

Want us to build your next idea or upgrade your existing product? Our experts cannot wait to work with you. Get in touch with us and let's make this happen. 💡🚀