Kirby Frugia, our VP of Engineering, recently spoke on the Dev Interrupted podcast. On the show, he discusses how MURAL has rapidly scaled its engineering department, the pitfalls of growing fast, and how to keep lines of communication open.
Dev Interrupted: Lessons When Scaling From 0 - 130 w/ Kirby Frugia of MURAL
Episode
Transcript
Dan Lines, Host 0:01 Narrator 0:39 Dan Lines, Host 0:54 Kirby Frugia 0:57 Dan Lines, Host 1:00 Kirby Frugia 1:20 Dan Lines, Host 1:21 Kirby Frugia 2:12 Dan Lines, Host 3:14 Kirby Frugia 3:51 Dan Lines, Host 5:49 Kirby Frugia 6:33 Dan Lines, Host 9:03 Kirby Frugia 10:28 Dan Lines, Host 13:19 Kirby Frugia 15:00 Dan Lines, Host 17:24 Kirby Frugia 18:01 Dan Lines, Host 19:03 Kirby Frugia 19:34 Dan Lines, Host 21:57 Kirby Frugia 23:25 Dan Lines, Host 24:38 Kirby Frugia 24:42 Dan Lines, Host 25:53 Kirby Frugia 26:04 Dan Lines, Host 26:07 Kirby Frugia 26:17 Dan Lines, Host 27:09Open transcript
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+ developer scale up journey, dig into how he keeps the flow of information stable across teams, as well as the open source methods he uses to help onboard new employees.
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 git activity. Sign up for free at LinearB.io
Kirby, thanks for joining us today.
Hey, Dan, thanks for having me. I'm super excited to chat with you.
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 doubling and tripling our engineering organization on the mind right now. So it's kind of perfect timing.
Congratulations.
Thank you very much. To jump into it here, when you start with that smaller engineering team, you might have 10 to 20 engineers, things are a little more straightforward, especially as an engineering leader. You probably know everything that's going on, who is working on what, maybe where the dependencies are. Whatever, right. But as you get that next round of funding, you start looking at, we're getting 30 engineers, maybe we're getting up to 50, 60, or 80 engineers, things start changing, right. From your perspective, what happens to the team structure as we start scaling rapidly there?
Yeah, when you're at 0 to 30 people, things are a lot simpler. You can rely on people knowing everything, knowing everybody. They know the product, they know the customer. As you start to grow to 20 to 30 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 knowing the product, knowing the customer, all of that. You have to start to put structure in place for teams to get to know the customers. You may start to split your team up. What a lot of companies do is split into smaller teams to split responsibilities of product up into different groups. You're probably still a monolith at this point, but you're able to make pretty good progress and still deliver on time, yet things are getting more complex. You're still pretty nimble at that small stage, you can move relatively quickly. 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.
Yeah, that's exactly right. Everyone can still talk to everyone if there is a problem. Everybody knows the code, you can work things out. You probably have just one manager at that point, or zero managers, so there's not as many people related problems. But once you start scaling now to the 50 or 60 point, are there a few things that happen to the team structure? Or maybe some things you should do?
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 accruing some tech debt and maybe you don't have enough tests. You probably do have that situation, where you have some people that know everything, but not everybody knows everything at that point. You start to have to figure out how to onboard people, how to get them to understand the complexity that other people know for free. One of the methods we're experimenting with here at MURAL is what we're calling internal open source, which is really leveraging some of the cool things that work out there in the world. Every developer works with open source technology, whether they're building it themselves, or whether they're using something. You might have a lot of dependencies too where you need something on one team that another team needs to do work for so that you can get your work done. How do you deal with that dependency? That becomes a real problem when you start to get to that 50 engineer size where you have a lot of teams with a lot of different areas of focus, but they start to depend on each other. We've been using data as a technique to allow teams to move fairly independently without a hard dependency on other teams. We do that through putting a set of maintainers on a specific area that's either a specific repo or a specific logical area of your code and anybody can contribute to those areas. If I need something from you and you're on another team, I don't go ask you and I don't wait for you to deliver and put it on your roadmap because when you have to wait on other teams, that's when things really start to slow down. You really don't want that to happen, especially at the 50 engineer level. We've been experimenting with that as a way to say, I need something from you, but I'm not going to wait on you, I'm just going to submit a pull request into your repo, and allow us to move at our own speed through that. We are starting to see some good success with that. That's one thing we've been trying.
That's really, really cool because dependencies do become a problem as your teams get bigger and bigger. Let's continue down our journey of scaling up. We have been talking about the 40 to, let’s call it 65 developer area. Now we're gonna head onto 80 developers or even 130 devs, maybe in that range. How does the organization change at this point? And what are some of the pitfalls engineering leaders could fall into here?
That's a great question. It starts to look fairly different at about that size. We started off the conversation looking at 0 to 30 engineers, where you have a small team mentality, which is great because you're very productive. You move very fast. At the 80 developer mark, you've started to split teams but things start to get harder and harder as you get up there. The number of lines of communication have exploded at this point. You've got lots of different teams, you maybe even start to add directors at this stage. You're starting to group people not because you want a hierarchy but because you have more jobs to do. The amount of communication that needs to happen, the amount of independent teams who are moving that need to stay aligned and moving in a similar direction, that gets more and more difficult to manage. Things get messier. One of the biggest pitfalls is not communicating. Things get messy. You start to lose visibility into what's going on in the teams. People may start to lose sight of the vision — where everybody knows the customer, they know what's important, you can ask anybody, and they can tell you — that starts to get lost, unless you're deliberate about communicating it. You're probably undergoing a fair amount of change. If you're a resilient company and you're agile, you're figuring out what's working and what's not working — you're making some changes. People might lose sight of things, you have to invest a lot more in visibility. Things like OKRs, cascading goals, leading through measuring things, metrics becomes super important. You got to get really good at clean, clear, concise statusing, because you need to know what's going on. You want teams to be moving independently, without getting into a micromanaged, centrally controlled kind of environment. You want teams making decisions, because they're close to the customers, but you don't have a way to always know what's going on with those teams unless you build good information flow into the organization. At that size, investing in information flow is extremely important to avoid that pitfall of not communicating. It keeps people from feeling lost if you provide a lot of clarity, and it keeps the managers from feeling like they're accountable for stuff but don't know what's going on. Information in every direction — that information flow becomes really important.
Yeah, I was in this situation myself when I was at 60 developers going on to that 70 to 75 range. That was the last time I was a VP of Engineering. Unfortunately, there's a few things that I didn't do right, that are hitting home for me here. At a certain point, I was adding on more teams. We were getting that pressure from the executive team, where we needed to grow because we needed to deliver more features. That became the mindset of new teams that were forming up. What was really happening is they weren't able to get the code out. We didn't invest enough early on into that infrastructure or measure the right things like deployment frequency. That is actually the number one metric for a new team, because you want to ensure you can get the new code out, or new value out to production. Instead, what we did was say we need to build features fast and that really hurt us. It could be obvious, but is there anything for someone who might be in that situation, what they should do?
Yeah, that is constantly a challenge. Especially in a high growth unicorn company, there's money available, you know you need more, you can envision this big organization, and every single person in that big organization has value to offer. Since you have so much good stuff out there to go after and do, it's hard to say how fast do we want to get there? That becomes a question. I'm in these kinds of conversations all the time. I ask myself, at what rate can we bring on people and have them be productive and feel like they're part of a team? You get into the mythical man month thing. I'm sure most people are familiar with that. At the same time, the reason you need to invest in all of those people is you have so much that you need to do and if everything was working perfectly, you would be able to add those people and they'd be able to get great work done. We're investing a lot in onboarding. That is a heavy, heavy emphasis that we have. How can we get new people in without disrupting the people already here, and get them to a point where they feel productive and can make changes without risking things or slowing other people down? You need to balance those two things. How do we get the team that's here super productive, while getting the new people on board and getting ready for them to deliver awesome stuff. You also need to understand in your organization, to what degree you can add people like what speed you can add people without it breaking down. You mentioned deployment frequency. It's one of my favorite metrics. We should talk about the four key metrics. I know that's something you're super excited about. But that's an important one, right? If you're adding people and you're not seeing more value get out to the customer faster, you have some important things to figure out on your team on how to get there. You don't want to be in a situation where suddenly you have that 130 developers we talked about earlier, but none of them can get anything done. That's not good for customers, that's not good for the developer, either to feel like they can't be productive. There's a lot of onboarding focus, training focus. You need to think about as you split up your teams, how big each of those teams should be, and how much each of them can absorb. We think in terms of, per month, how much could a team absorb? How mature are they? Do they have experienced developers on their team? You could add somebody to the team relatively easily without making a huge negative impact to them. Do they have time to adequately onboard people, when they bring people on? Is their productivity going out? Are they deploying more frequently than they were before? You do need a lot of insight to know what's going on.
Right and for me, that's part of the visibility as a leader, which I lacked at that time. The visibility. You said the four key metrics, well, what are they? You have your cycle time, your deployment frequency, your mean time to restore, and your change failure rate. If I have that visibility as I'm scaling, I can ask myself or my teams the right questions. Am I improving or at least maintaining in these areas? In my story, we were not, even though it wasn't visible. It's harder to see. Then you can kind of adapt from there. The other item I want to touch on is around not centralizing or being more decentralized. When we started to scale, we started to have more issues in production. That's that change failure rate metric, even though we weren't measuring that as well as we should have been. I had the instinct, that things aren't going well. Let's centralize, let's form an SRE team. They did great, actually, but the downside was the new teams being bought on were relying on the SRE team. They weren't getting that full authority or that end-to-end ownership because we went to a centralized model in that area. If I am a leader, and I'm getting that urge to centralize in an area, do you have any advice for when that feeling comes on?
Yeah, absolutely. I think there's a good combination of centralizing some things and decentralizing others. SRE stuff specifically. I love that stuff. I spent time in that space in my career. What I like to think about in terms of the things to centralize are things that enable teams to own stuff, not owning stuff yourself. And, like, an SRE team can own infrastructure and like all of that stuff, and they should be accountable and responsible for those kinds of things. But in terms of a team's code, and owning that in production, you want that ownership on the team. And so what can you centralize your CI/CD, pipeline, centralize how you deploy things, maybe even centralize some test frameworks, some observability frameworks, like we have a developer velocity team here at mural. And their goal is to enable our engineering teams to have full ownership and to be productive and feel like they can actually get their stuff out the door easier and know how it's working in production. The things you don't want to centralize are quality, reliability, all of those things that, you know, are part of the process that often get shoved on other people. Because what you see happen, if you decentralize those is exactly what you were talking about. teams don't feel that full ownership, it's easy to throw things over the wall and feel like somebody else is going to catch the problem. It's not a mal intent kind of thing. But it's just a natural thing to be like, I'm gonna focus on the code. And and, you know, I don't necessarily even build those skills, or if I had those skills, they atrophy because somebody else is using them, I'm not using them. And so I'm a big fan of full accountability of the teams from beginning to end, they know the customer really well. And they care about the customer, when they're work has been deployed. And they have things like observability, they have their own metrics. So when we talk about the four key metrics, it's great for me to see it at the high level across all teams, it's great for the teams to see it themselves for themselves for the work that they do. And so they can, they can work to improve it, like, developers care a lot about this stuff. They're not often set up that way in a company, though. And so I've worked with a number of developers who've never been in that kind of environment, and it's a change every single time, I've helped move from that traditional mindset into full ownership, you end up happier at the end of that process, because they feel like actually, their work is valuable to people, because they can actually see it more directly.
Well, I can tell you, especially with the metrics, because we're doing this all the time, when I'm interacting with the LinearB community, if you just put top down metrics, even those four metrics that we talked about those the door four which are great, if you just go top down, doesn't work, you have to have the teams are the ones that own their team related metrics. And that's where, okay, now we're starting to see, at the end of the day, more value, getting the customers faster, hitting iteration deliveries on time, all that good stuff has to come from bottom up.
100% agree with that, like, and the people care about that, like developers really care, like, oftentimes they get this image of they just want to write code, and they don't want to think about all this. That's not true. Like developers love to build stuff. And they love to do things that make people happy. And so if you can move more and more towards them, and have them kind of creatively own things and feel like their work is valuable. And they can see that and they can see that in the metrics and they can they can own their own, like the four the four key Yeah, absolutely. But they probably have their own metrics to like, how do they feel that they're doing and they should be able to have their own metrics and report on those. And so as you're building that scaling organization, you're thinking about providing clarity of what's important and then relinquishing control to the teams to figure out how to get there. And one of the best ways to do that is through metrics, and through them, self reporting, what actually matters, and then taking full ownership of that.
I want to talk a little bit about mindset changes. If you are a VP of engineering or a CTO, and you do have the responsibility to grow your engineering organization, from 35 to 50, this 65 to 80 to 100+, how should your mindset as a leader change as you're scaling up rapidly?
A lot is the short answer to that, like, you need to change how you operate if you don't already operate a certain way. So like, you have to be comfortable. A lot of people get into leadership positions, through personal accomplishment, through team accomplishment, through like getting good stuff done with other people and all of that, but in a lot of ways when you're smaller, you have a lot of control over things like it's either in your own hands or you're just working closely with The people who do stuff, when you're leading a big organization like that, that's not even possible. Nor is it a good idea in general, and you don't want to be micromanaging, you don't want to be in a situation where you were the one that's in the middle of everything, you want to enable others to do that. And so the most important mindset you have to have is, you have to be really good at providing clarity. So people know what's important, and being really good at communicating that, as a leader in a big organization, your words matter a lot, your tone matters a lot, getting people aligned towards a vision and super clear on what's important to the team. That's, that's almost your number one job above all others is making sure that that's super clear to people because you want that accountability and responsibility. And you want those teams to be able to move without having to go seek permission for things, you just want them to move forward with intent to make decisions to move everything in the direction that the customer needs it without having to seek your permission, seek your approval or any of that. So how do you do that? Make things super clear. And you get really good information and visibility coming up from the teams. And so you have to lead through providing clarity, like allowing, not allowing just almost like, the teams have to be accountable for stuff, there's no other way around it, like they need that autonomy, they need that accountability, and they need to get super good at information flow. And, so, that's where frameworks like OKRs, and all of those come in is because it's a method defined to align people so that you can say, here's what's important. Now you go figure out how to achieve that. But I need to know how that's going. I need to know, like, are we getting towards achieving our goals? How are we doing with our metrics? Are we achieve— are we delivering things to customers every day, every week, you know, whatever your goal is. And so you have to get really good at communicating vision, communicating plans, not having your hands and everything that's going on trusting other people to do that, but having good information to make sure that the teams are moving in there in the right direction.
You brought up so many good points here. You know, when I was in this situation, I always kind of thought, what I say matters, number one, because I don't get to say that many things now to every single person. So when I am talking, what I talk about the metrics that I talk about matters a lot. And then the second thing is, where can I make the biggest impact possible with my time. And in order to understand those two aspects, you have to have the visibility, the right visibility and the metrics. For example, and I'm going to ask you, you know what, what you're using today, but for, for example, you know, if you're a VP of engineering, and you are having that one on one with a director, or you're having that one on one with a team leader, because you might be doing some of those skip levels, you want to know what's going on. Very constructively if you saw that deployment frequency dip for that team leader. This is a very positive conversation. “Hey, I'm seeing, you know, I'm seeing that the deployment frequency came down here. You know, that's what's important, you know, from me, like, how can I help you hear that we get into some tected? Are you getting too much pressure on the features?” Like, wow, that's an amazing conversation to be able to have with a team leader, you can only have it with visibility, though.
Yeah, 100%, it becomes about visible output, not output, but outcomes and results. Right? Like, like, that's the thing that you want to talk about. And, you know, you trust that you're hiring good people, like you need that. And you need to, you know, have mechanisms to make sure you are and all that all that stuff. But like, if you make it about the metrics, and you make it about those things, then yeah, absolutely. It's great conversations to have with managers. And it's great to walk into those saying, like, here's some data, like, you know, help me help you what's, what's going on? How can I be supportive? You know, tell them tell me, you know, and even better is if you build the mechanisms that they report on that. So you don't even have to ask that question. Right. So if that deployment frequency is one of the things that you want, as a key metric for your organization, every team should be reporting on that. And if we see it dip, you should be able to read what that dip is, rather than go knock on somebody's door and ask them about it. And so that's, that's where some of that information flow is so so valuable, because it's not only the change in that number from week to week, but it's what is the reason for that change? Did we have an incident? And everybody was jumping on that. And so we didn't have time to write code? Well, you should just know that that's-
Is our WIP too high? Too much work in progress?
Yeah. Yeah. And if that metric is visible, and people are reporting on that metric, they'll see the dip themselves. And I'll explain the dip themselves. Like it's just it becomes almost like a cultural thing, that those metrics are so important that people are reporting on them and they're self diagnosing When there's an issue, and that's what you hired really good managers for is to trust them to figure stuff out. And if something's not working, they're clear about it not working. And they're doing something about it. Like when I think about what a good manager is, it's not that they hit it out of the ballpark all the time like that. Sure if that would be awesome. If everything they did was perfect. Yeah, fantastic. But it's not. And realistically, it can't be in the world that we're in. And so we're what builds trust in me, for with managers, is they tell me how things are going. And they're completely transparent and truthful about that. And if something's not going, right, they're telling me what they're doing about it. And if I hear that, like, this metric went down, here's a reason why. And here's what we're doing about it. I've just now have a super positive opinion of that person. And that's awesome. Like, they got it. And I can trust that they got it. And I don't I don't have to worry about how they're doing because it's like clear to me that they do.
Awesome. Kirby, thank you so much for sharing all of that information. This has been an amazing conversation. Thank you so much for coming on the show today.
Yeah, absolutely. I had a great time. Thanks for having me.
If listeners want to connect with you, or for example I know at MURAL you’re hiring a bit. Can you talk about that and where they can go?
Yeah, absolutely. We are looking for great people, engineers, managers, product managers. I mean, everybody we're hiring like crazy. And so yeah, I'm on LinkedIn, under “kfrugia”, you can also just go to mural.co and look for open positions there. We have lots. If you're a great developer, I guarantee you there's a position for you on our team We're really trying to grow thoughtfully is I hope people realize through this conversation that we're we want to bring great people on board and we want them to have an awesome experience kind of onboarding and feeling like they're part of the team. We're investing a lot in that we're investing a lot in people as part of this. So if you're somebody who wants to work on an awesome product, wants to have a big impact at a growing company, wants to do good work every day in an environment where you can love that love to have you.
Awesome. Well, everyone, definitely check out the open hires on Kirby's team and also be sure to join the Dev Interrupted Discord community. That's where we keep this type of conversation going all week long. You can find all of the information in the links below and have a great week everyone!
Top comments (0)