Show Notes
In this VacationCast episode, Mon-Chaio tackles a listener’s question inspired by “Does Your Software Methodology Matter?” about effectively scaling an engineering organization to 120 engineers. Dispelling the notion that scaling is about simple multiplication, he delves into key tactics, including the creation of autonomous, accountable teams with independent KPIs, and the importance of technical strategy. He addresses the common pitfalls and misconceptions of scaling, emphasizing tailored processes and decision-making. Tune in for insights into building adaptable, sustainable engineering teams.
References
Transcript
Mon-Chaio: Hi, everyone. Andy’s unavailable this week, so longtime listeners know that means I’m doing a VacationCast, a shorter episode on a broader range of topics that are normal research paper-backed discourse. Today, I’m going to address a question a listener sent in after listening to the “Does Your Software Methodology Matter?” episode. In that episode, and in various others as well, Andy and I mentioned that in our opinion, most software team scaling practices such as SAFe or LeSS, don’t actually work. So Roland listened to that and wrote in and was curious about how we would recommend scaling an engineering organization of, say, approximately 120 engineers.
So first off, thanks for writing in, Roland! We always love hearing from our listeners. And second, this is a common question we hear a lot, and our generic solution is usually to just not scale and keep things small. But, you know what, that’s kind of a glib answer. Most companies want to be able to grow and to do more and that often, uh, but important to note, not always, but often requires larger engineering organizations. I myself have certainly been responsible for teams of that size and larger, both startups and Big Tech alike. And I didn’t simply say no, those orgs are too big, break it up, you can’t scale, you have to be small. So it’s a good question. And what was my answer and what were my tactics during those situations?
I actually wrote up a long example answer on how to think about team scaling, and I used an example of a hypothetical team building an Uber-like application 10 or 15 years ago and starting small and growing larger and larger, but that turned out to be way too long for a VacationCast. Um, I might chat with Andy when he gets back and see whether we can actually do a full episode on that with all the nitty gritty details. I feel like maybe that’s kind of interesting for our listeners. But for today, what I’ll say is that when people think about scaling engineering teams, they’re thinking about something small that works and then essentially making a larger version of what already exists. So each individual part simply grows larger.
If you have 10 engineers, you, then you make that 20. If you have two QA teams, you make that four. And if you have three scrum boards, you make that six. But nothing else really changes in most people’s thinking. The fabric that connects everything together and the processes that support that fabric, that all remains the same. And so that’s how we get a lot of these Scrum-of-Scrums and hierarchical reporting dashboards and all of that sort of thing from, you know, take what was below, summarize it, and then present it up, and then do it all again, all the way to the top of the hierarchy.
To me, the trouble with that is it assumes the stability of this larger team organism is the same as the smaller team organism. So what do I mean by that? With a small team, such as a five to 10 person team, you’re almost always serving the same group of customers. There’s no reason, for example, that the database portion of your application will need to release at a different cadence than the front end. No reason for the product details page would have different scaling standards than the shopping cart page, right? I mean, you’re serving the same customer, you’re serving a set of use cases that are fairly well related. The team organism at this level is stable and it has to be for you to deliver maximum value for your customer. So all of the processes and rituals you run as a leader of this small organization is to keep your organism stable. It’s to make sure your database code and product code are in sync. It’s making sure your bug counts are in line and all of that sort of thing.
But when you grow, it’s almost never that everything grows as it already exists. For example, you never have just 100x more of the same customer that you had previously. You’re never selling just a 100x of the exact same product or the exact same types of product that you sold previously. You never have a 100x of the same types of databases filled with the same types of data that you had previously. That’s not how it works. You don’t have a larger organism of the same shape as your smaller organism. You kind of have a 100x smaller organisms and they each look slightly different than their neighbor organism, right? Some of them are gonna be drop shipping items that don’t require a warehouse. Some of them we’re going to be selling items that don’t have predefined dimensions and weights. Some are selling digital items and not physical items and the like. So you cannot use a larger version of the same process that you use for your smaller organism. And in fact, the way you interrogate your larger organism, the types of questions that you ask and the way that you evolve it, also have to be different. Than the smaller organism.
Okay. Wow, this is actually getting to be a bit long. Uh, even with my summary around that, I realized that this topic is way too large, so I’ll try to distill it down, finish it up, and then maybe we can dive into detail in future episodes. Okay. So what are my specific tactics for scaling an engineer organization of 120 employees? Well, first the build right sized AAA teams. Teams that have authority, autonomy, and accountability over their own set of customer-facing KPIs. In my experience, 90% of those teams are between five to 20 members in size. So first off you have 120 people. You’re going to break them down. You’re going to have between six and say twenty teams or so. Secondly, allow those teams to operate in a AAA style, using whatever methodology they want. You don’t care! I mean, you should rarely need to know what is or isn’t on their Scrum board or whether they met their last sprint commitment or whether the coverage number for a specific module is going up or down. Now, I’m not saying those things are unimportant. I’m saying that as the leader of the 120 person organization, that should not be important to you. For one of your senior managers, perhaps managing two of these AAA organizations, it probably is important. So there’s different levels here.
For you as the leader of this large ,organization you’ll want to interrogate them on the level of their team KPIs. And what you’ll want to do is use briefing, back-briefing, and Gemba walks to ensure that you and your AAA organizations under you are aligned. And if you want to know more about those tactics, listen to “The Whys and Hows of Delegation” from season one, where we dive deep into each of those.
And third, you want to ensure that your technical strategy is a strong lever to keep your teams aligned. As we mentioned in the “Defining Technical Strategy” episode, the primary use of your strategy should be to support bottoms-up decision-making in a way that gives a high likelihood that even though your AAA teams are making independent decisions on longer timeframes, that there’s still a high likelihood they will come together to form a coherent whole. And that’s because they can use your strategy to steer them in a direction where most of them will land in a way that supports most of the others.
Now I can hear all the questions already. Right? Um, but what about large releases that need to be coordinated between different teams or what about urgent issues that need experts from each team to come together and build a feature as quickly as possible? Uh, how can I just not care about the test coverage of my product as a whole. Without details of each Scrum board, how can I reallocate engineers for critical projects that come up midstream? Those are all good questions and would take Andy and I many episodes and probably even a couple of books, uh, to cover really the nuances and details of how to scale an organization and tackle those specific challenges. It’s also something we spend a lot of time helping teams and companies work through, through our consulting work, which is of course a longer timeframe thing than a 20 minute podcast episode as well. But you can kind of think through this and reason through it, on your own by asking yourself: if I have a large organism that’s made up of AAA teams – again, teams with authority, autonomy, and accountability – what parts of these questions that I’ve just asked are still valid, and what parts may point to a different way of thinking or behaving that actually changes the question, and changes the way that you think about how to accomplish some of the goals that the questions may lead to.
Okay. I’ll leave that as an exercise for the listener. Uh, do send us your homework. If you do these exercises, we’re always happy to explain debate, argue and learn from everyone in the leadership community. Or like Roland, send us other questions and comments that you have as well as your request for consulting help. Andy and I can always be reached at hosts@thettlpodcast.com. That’s hosts with an ‘s’.
Until next time, behind and stay curious.
Leave a Reply