Lessons When Scaling From 0-130 Devs

Episode Recap & Transcription

Dan Lines: Kirby, thanks for joining us today.

Kirby Frugia: Hey, thanks for having me on. Super excited to chat with you.

Dan Lines: Yeah. Really excited to be talking about scaling engineering organizations, actually. LinearB 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: Congratulations.

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 or 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 may be where the dependencies are, whatever. Right. But as you maybe get that next round of funding, you start looking at, OK, 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: Yeah, you know, 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, etc. 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 four teams to get to know customers a little bit. You may start to split your team up a with a lot of companies do is start to split into smaller teams, maybe split responsibilities of product up into different groups. You’re probably so 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, 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 Lines: 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, OK, I’m I’m scaling now the 50 60 are there are a few things that happen to the team structure at that point, or maybe some things that like you should do.

Kirby Frugia: Yeah, absolutely. When you’re getting that big, things definitely start to get more complex. You’re probably in a monolith and starting to fill some of the impacts of that. You’re probably starting accruing some tech debt and maybe you don’t have enough test. 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, how to get them to understand the complexity that other people know kind of 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 every developer works with open source technology, whether they’re building it themselves or whether they’re using something. But, you know, you might have a lot of dependencies at that point to 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 about that fifty 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. It’s either specific repo or specifically ecological area of your code and anybody can contribute to those areas. So if I need something from you, you’re another team. I don’t go ask you and I don’t wait for you to deliver that and put it on your roadmap, because when you have to wait on on other teams, that’s when things really start to slow down. And you really don’t want that to happen, especially at the 50 engineer level. And so 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 to move at our own speed through that. And we’re starting to see some some good success with that. So that’s one thing we’ve been trying

Dan Lines: That’s that’s really, really cool because, you know, dependencies kind of do become a problem as your teams get bigger and bigger. Let’s continue down our journey of scaling up. So you kind of may be talking about the 40 to let’s call it, you know, 65 developer area. Now we’re going to head on to, OK, let’s get up to 80 dads are up to 130 dads maybe in that range. How does the organization change at this point? And what are some of the pitfalls, you know, engineering leaders could fall into here?

Kirby Frugia: Yeah, that’s a great question. It starts to look fairly different in about about that size. You know, we started off the conversation talking about like zero to 30 and you get the small team mentality and which is great. You’re very productive. You move very fast at that 80. We kind of talked about you’re still in that a little bit. You’ve started to split teams a little and maybe you can keep that or starts to get harder and harder as you get up there. They’re bigger. The number of lines of communication just have exploded at this. At this point, the you’ve got lots of different teams. You maybe even start to add directors at this stage so that you’re starting to group people not because you don’t like a hierarchy, but because you have more jobs to do. The amount of communication that needs to happen, the amount of independent teams that are moving that need to stay aligned and moving in a similar direction that gets more and more difficult to message, to manage things get messier a little bit. And so one of the biggest pitfalls, and I can list a number of them, but one of the biggest is not communicating that it’s things get messy. You start to lose some visibility into what’s going on in the teams. People may start to lose sight of the vision. Some of that stuff that I mentioned earlier about, you know, immediately everybody knows the customer. They know what’s important. You can ask anybody and they can tell you at a moment a little bit of that starts to get lost. Unless you’re deliberate about communicating it, you’re probably undergoing a fair amount of change because if you’re a resilient company and you’re agile and you’re you’re kind of figuring out what’s working and what’s not working, you’re making some changes. And so people might lose sight of things. You have to invest a lot more in visibility. So things like, OK, cars cascading, goals leading through measuring things, you know, metrics become super important. You’ve got to get really good, clean, clear, concise data seeing because you need to know what’s going on. But you want teams to be moving independently. You don’t want to get into a micromanage, centrally controlled kind of environment. You want teams making decisions because they’re close to the customers. But you don’t really have a way to always know what’s going on with those teams unless you build good information flow into the organization. So at that size, investing in information flow is extremely important to avoid that pitfall of not communicating, it keeps people from feeling a little lost. If you provide a lot of clarity and it keeps the, you know, managers from feeling like they’re accountable for stuff but don’t know what’s going on. And so information in every direction, information flow becomes really important, right?

Dan Lines: Yeah. I mean, I was in this situation myself and it kind of actually probably hit me when I was at like 60 developers and then going on to that 70, 75 range. That was kind of the last time that I was a VP of engineering. But unfortunately, there’s a few things that I didn’t do right that are kind of hitting home for me here that maybe we can dive into a little bit. So one thing that happened to me is at a certain point, I was adding on more teams. You know, we were getting kind of that pressure from the executive team. We need to grow because we need to deliver more features. And that kind of became the mindset of new teams that were forming up. But what’s 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, OK, deployment frequency is actually the number one metric for a new team because I want to ensure that you can get the new code, you know, out or new value out to production. Instead, what we did was just say, OK, we need to build features fast and that really hurt us. So it could be obvious. But is there anything like someone that’s like feeling themselves? Oh, I might be in that situation. What they should do.

Kirby Frugia: Yeah, 100 percent like that is that is constantly a challenge because especially in a high growth kind of 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 because you have so much like good stuff out there to go after and do that. It’s hard to say. Now, you know, how how fast do we want how fast do we want to get there? That becomes a question. And it’s to me, I mean, these kinds of conversations all the time. And one of the questions I’ve been asking, you know, I ask myself a lot, is at what rate can we bring on people and have them be productive and feel like they’re part of a team because you get into the, you know, mythical man month thing of the you know, I’m sure most people are familiar with that. But at the same time, like 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. And so we’re investing a lot in onboarding like that is a heavy, heavy emphasis that we have on the team is how can we get people in without disrupting the people that are here that allow you to get them to a point where they feel productive and can make changes without risking things or without slowing the people down. Because you need a little bit, especially in the really high growth to to balance those those two things. How do we get the team that’s here are 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. Like you mentioned, deployment frequency. It’s one of my favorite metrics. I think we should talk about the four key metrics. I know that’s something that 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, because you don’t want to be in a situation where suddenly you have that hundred and thirty 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. And so definitely 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. So like we think in terms of, you know, per month, how much could a team absorb or how mature they do they have, you know, experienced developers on their team. So you could add somebody to the team relatively easily without making a huge negative impact to them. Do they have time to adequately on board people when they bring people on? Is their productivity going out? Are they deploying more frequently than they were before? And so you do need a lot of insight to to know what’s what’s going on for sure. Right.

Dan Lines: And for me, that’s part of the visibility as a leader, which I laughed at that time. The visibility you said before, key metrics. Well, what are they? So you have your cycle time, your deployment frequency, your mean time to restore your change fit failure rate. Now, if I could have that visibility as I’m scaling, I can ask myself or my teams the right question are 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. And then you can kind of adapt from there. The other, you know, item that I kind of wanted to touch on that you’ve mentioned a few times is around, I think, not centralizing or being more more decentralized now when for me, when we started to scale, we started to have more issues in production. That’s that change failure rate metric. Right. Even though we weren’t, you know, measuring that as well as we should. And I kind of had the instinct, OK, things aren’t going well. Let’s centralized. Let’s form an SRE team. Nothing bad against our SRE team. They did great, actually. But the downside of that was that the new teams that were being bought on, brought on, they were relying on the team. They weren’t you know, we were giving that full, I guess, authority or that end to end kind of ownership because we went to a centralized model in that area. So if I am a leader and I’m giving that urge to centralize in an area, do you have any advice for when that feeling comes on?

Kirby Frugia: Yeah, absolutely, I think there’s a good combination of centralizing some things and decentralizing others, so esoteric stuff specifically, like I love that stuff. I spent time, time in that space in my career. And 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 clearly like in a sorry 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? Centralize your CICD pipeline and 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 gets shoved on other people. Because what you see happen if you 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 malintent kind of thing, but it’s just a natural thing to be like I’m going to focus on the code and, you know, I don’t necessarily even build that 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 their work’s 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 things. 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. 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 end up happier at the end of that process because they feel like actually their work is valuable to people because I can actually see it more directly.

Dan Lines: 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 for, 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 OK, 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.

Kirby Frugia: 100 percent agree with that. And the people care about the developers really care. Oftentimes they get this image of they just want to write code and they don’t want to think about all this. Not true. 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 on their own. Like the four the four key. Yeah, absolutely. But they probably have their own metrics to like how, 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 taking full ownership of that.

Dan Lines: So, you know, I want to talk a little bit about mindset changes. So if you are a VP of engineering or a CTO and you do have that responsibility to grow your engineering organization from 35 to 50, this 65 to 80 to 100 plus how this year mindset are, how should your mindset as a leader change as you’re scaling up rapidly there?

Kirby Frugia: Yeah, a lot is the short answer to that. I think you need to change how you operate if you don’t already operate a certain way. So 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 so when you’re leading a big organization like that, that’s not even possible, nor is it a good idea in general. I mean, you don’t want to be micromanaging. You don’t want to be in a situation where you are 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 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 without having to seek your permission, seeker 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 an information flow. And so that’s where frameworks like ours 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 is are we getting towards achieving our goals? How are we doing with our metrics? Are we 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 in the right direction.

Dan Lines: Yeah, I mean, you’ve 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 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 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, you might be doing some of those skip level that you you want to know what’s going on very constructively. If you saw that deployment frequency dit 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, for me, like, how can I help you here that we get into some tech debt, 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.

Kirby Frugia: Yeah, 100 percent. It becomes about visible out, but, you know, not output, but outcomes and results. Right. 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, you know, help me help you. What’s what’s going on? How how can I be supportive? You know, don’t 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 a dip, you should be able to to read what that dip is rather than go knock on somebody’s door and ask to 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? Well, you should just know that that’s too high.

Dan Lines: Too much work in progress. Yep.

Kirby Frugia: Yep. And it’s that metric is visible and people are reporting on that metric. They’ll see that up themselves and they’ll explain the dip themselves. Like it’s just it becomes almost like a cultural thing. The 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 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 I would be awesome if every 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 what builds trust in me with managers as 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 has 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.

Dan Lines: Kirby, thank you so much for sharing all of that information. This has been an amazing conversation. And thank you so much for coming on the show today.

Kirby Frugia: Yeah, absolutely. I had a great time. Thanks for having me.