Lessons When Scaling From 0 - 130 Devs w/ Kirby Frugia of MURAL

**Dan** (0:01)
Hey, you're listening to Dev Interrupted, the only podcast made for Dev Team leaders who want to continuously improve.
Today's guest is Kirby Frugia, the VP of Engineering at Mural. Mural has gone through enormous growth in the past two years, and Kirby came on to discuss the ins and outs of rapidly scaling engineering organizations. We go through the entire zero to 100 plus developer scale up journey, dig into how he keeps the flow of information stable across team, as well as the open sourced methods he uses to help onboard new employees.

**SPEAKER_2** (0:39)
This episode is sponsored by LinearB. Give your dev team the power to improve with team based metrics, high risk code alerts, and the world's first project board based on real time get activity.
Sign up free at linearb.io.

**Dan** (0:55)
Kirby, thanks for joining us today.

**Kirby Frugia** (0:57)
Hey Dan, thanks for having me. I'm super excited to chat with you.

**Dan** (1:00)
Yeah, really excited to be talking about scaling engineering organizations. Actually LinearB, my company just announced our series A round of funding. So we have kind of doubling and tripling our engineering organization on the mind right now. So it's kind of perfect timing.

**Kirby Frugia** (1:20)
Congratulations.

**Dan** (1:21)
Thank you very much.
So, you know, to kind of jump into it here, when you start with that smaller engineering team, you know, you might have 10 to 20 engineers. Things are a little more straightforward, especially as an engineering leader, you probably kind of know everything that's going on, who's working on what, maybe where the dependencies are, whatever, right? But as you maybe get that next round of funding, you start looking at, okay, we're getting 30 engineers, maybe we're getting up to 50, 60, 80 engineers, things start changing, right? And so, you know, from your perspective, what happens to the team structure as we start kind of scaling rapidly there?

**Kirby Frugia** (2:12)
Yeah, when you're at zero to 30, zero to 20 kind of people, things are a lot simpler. You can rely on people like knowing everything, knowing everybody, they know the product, they know the customer. As you're starting to grow to that 20, 30, et cetera people, it gets a lot more complicated really, really quickly. The number of lines of communication that you have starts to grow exponentially. You don't get some of those things I mentioned earlier for free, like, you know, knowing the product, knowing the customer, all of that. And so you have to start to put a little structure for teams to get to know customers a little bit.
You may start to split your team up. What a lot of companies do is start to split into smaller teams, maybe split responsibilities of product up into different groups. You're probably still monolith at this point, but you're able to make pretty good progress, still deliver, things are getting a little more complex, but you're still pretty nimble at that small stage. You can move relatively quickly.
But, you know, at that stage, you're just starting to grow, and you're probably starting to feel a little bit of the growing pains of a company.

**Dan** (3:13)
Right, right. Yeah, that's exactly right, because, you know, everyone can still talk to everyone. If there is a problem, it's like everybody knows the code. You can work things out. If you do have, maybe you have like one manager at that point, or zero managers. So there's not as many, you know, people related problems.
But once you start getting, let's say, you know, okay, I'm scaling now to 50, 60
Are there a few things that happen to the team structure at that point, or maybe some things that like you should do?

**Kirby Frugia** (3:51)
Yeah, absolutely. When you're getting that big, things definitely start to get more complex. You're probably in a monolith and starting to feel some of the impacts of that.
You're probably starting accruing some tech debt, and maybe you don't have enough tests. You probably do have that situation, like you said, where you have some people that know everything, but not everybody knows everything at that point. And you start to have to figure out how to, on board people have to get them to understand the complexity that other people know kind of for free.
And so one of the methods we're experimenting here with Mural, we're calling it internal open source, which is really leveraging some of the cool things that work out there in the world. Like every developer works with open source technology, whether they're building it themselves or whether they're using something. But you might have a lot of dependencies at that point too, where you might need something on one team that another team needs to do work for so that you can get your work done. And how do you deal with that dependency? That becomes a real problem when you start to get to about that 50 engineer size, where you have a lot of teams with a lot of different areas of focus, but they start to kind of depend on each other. And so we've been using that as a technique to allow teams to move still fairly independently without a hard, hard dependency on other teams. And so we do that through putting a set of maintainers on a specific area that's either a specific repo or a specific like logical area of your code.