The Mythical Man-Month

About this Episode

The episode of the Acima Development Podcast centers around the challenges of scaling teams effectively, inspired by the principles from Fred Brooks' book The Mythical Man-Month. Host Mike begins by sharing a parable about his toddler's well-meaning but inexperienced attempts to help, drawing parallels to the complexities of onboarding and team communication. The core theme emphasizes that while eager new members can be valuable, onboarding takes time and resources, which can ironically slow down progress on active projects. The discussion highlights that simply adding more people to a late project often exacerbates delays due to the increased communication overhead and coordination required.

The panel delves into strategies for mitigating these challenges, such as the importance of defining clear project milestones and fostering communication between product and engineering teams. They explore how startups often face growing pains when transitioning from nimble, small teams to larger, more structured ones. Effective leadership and the role of subject matter experts are critical in this context, ensuring continuity and knowledge sharing. Prototyping, rapid iteration, and intentional decoupling of work into smaller, manageable units are suggested as ways to enable independent progress and reduce bottlenecks.

The conversation also touches on cultural and organizational aspects, like aligning incentives to encourage behaviors that prioritize long-term scalability over short-term output. The speakers stress the need for cross-training, maintaining organizational boundaries, and fostering relationships across teams to streamline collaboration. They close with reflections on leadership, emphasizing the discipline of narrowing scope and recognizing the inherent trade-offs in scaling efforts.

Transcript:

 MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I will be hosting again today. With me, I have Matt, Ramses, Kyle, and Justin. And we're going to be talking about something that's been talked about for a long time. I will introduce this in a minute. I'm going to start by telling, as I usually do [chuckles], a little bit of a story and maybe a bit of a parable.

I have a toddler at home, and anybody who's been around a toddler knows some things about toddlers [chuckles]. They love to help. They absolutely love to help. And a recent example is, about a month ago, I was fixing something, and my toddler wanted to use the hammer to help with everything. And he grabbed that hammer, and he started doing what a toddler would do and hitting everything he could see [laughs] with the hammer, requiring me to give him a lot of one-on-one attention [laughs]. And that is true about everything he wants to help with.

His help with the dishes usually involves a lot of cleaning of water everywhere in the kitchen. His helping in the yard involves filling in a lot of holes or stopping, as I'm mowing, to let him pass. In short, he is very eager to help, but he lacks the experience to accomplish that yet. And that's not to say that he doesn't want to help, right? He has all of the right attitude. And I'd love to hire somebody like that with that kind of eager attitude.

But there are limits to the training time. For him, the training time to do my job would be, you know, a few decades [laughs], and then he could have the experience needed. And that's not saying anything about him, or his character, or his abilities. He just hasn't gotten the experience yet. That's just how that works. And I got some older kids, too [chuckles], and the thing is, the same thing applies.

And even if I went over and grabbed a neighbor and said, “Hey, can you come over and help me with something?” I'm going to have to take some time to explain to said neighbor what it's going to do to do that work. Even if they have lots of years of experience in life, they probably are not very familiar with what I'm going to ask them about. And there's this crucial distinction between somebody having technically the capacity with training and being able to do something now because there is a communication gap.

Communication takes time and that is inescapable that communication takes time. And for some people who have closer experience, it's going to take less time, but it's always not zero. Not only is there communication, there's just overhead of coordination. Some jobs can't really readily be shared [laughs] because only one person fits.

There was a book written on this topic in 1975. It's written by an author named Fred Brooks, and he titled his book “The Mythical Man-Month.” You got some nice alliteration there with Mythical Man-Month. Knowing this was 1975, it's a bit gendered [chuckles] because, obviously, there are more than just men in software, but he's using it in a more generic sense. And there have been women in software from far before 1975, so nothing gendered intended here. It's just the title of the book.

He made this incredibly valuable observation that this idea that you can just have one person one month, that they are fungible, and you can just interchange, you can put more people on a project to make you go faster is false. It's just straight-up false. And it comes largely down to this communication overhead. And if you add more people, then you have more people to communicate with and more connections between people on the team. If you have one person, there's no communication, right? It's just you.

If you have ten people, you have ten people communicating each to 9 other people. That's a lot of connections. The complexity within your team has exploded dramatically, and all of that communication overhead is not going to speed things up. And, in fact, if you add it late in the project, it will almost certainly slow it down.

That's what we're going to be talking about today is this idea of the Mythical Man-Month, the idea that you can just add people to a project and make it faster. There's our introduction. I'm going to stop talking and will let my panel here share some thoughts.

MATT: Yeah, I think when you start adding too many people to a problem, communication is key, right? And you start to play the telephone game. So, it's very easy for things to become miscommunicated. But also, there's the lack of context of the problem, and that has to be shared. People have to ramp up and learn that context and gain the knowledge of the problem they're trying to solve, and, ultimately, that's always going to slow things down.

JUSTIN: Yeah, one thing that is kind of a corollary to that is that the mythical, like, the skill needed for startup, for a leader, is the ability to have vision and to do the thing. And, generally, it's a very small team, and you can all go be very fast and very nimble. But once you're past that startup phase, all of a sudden, you want to do more. And just throwing more people at the problem doesn't solve the problem any faster.

And, all of a sudden, your skill set that you need, that you had to do the startup, which was to do the thing and to be a visionary and drive the thing, all of a sudden, your skill set needs to be management, and problem dissection, and distribution. And so, it's making the move from startup to post-startup that requires a different skill set that is difficult, that's like a gate that people run into or that businesses run into that could prevent them from being a more successful business.

MATT: Yeah, and oftentimes, startups, specifically, will bring in a new CEO once they see that kind of growth, right, that actually specializes in those skills. And we always...well, not always, but very often, we see startups who grow too quickly. And I wonder if it's more than just the financial problems that it causes. But this is one of those problems as well is, the communication gaps that it creates, and the context, and people being on the same page, and understanding what they're really trying to accomplish.

MIKE: It takes, I think, always longer than you'd expect to get somebody else up to speed. It's just hard. It's hard to take something that you can see and have experienced in your own mind and hand it off to somebody else. There's a mismatch. You have to convert it into language, and they have to convert it into their mental representation. And that transfer is inefficient and is going to take time. And, I think, over and over again, we underestimate the challenge of that transfer.

JUSTIN: So, we often underestimate it, but what, I mean, we're all experienced engineers here, and we've been studying this for a while. So, what can we do to make that transition smoother?

MATT: Well, I think there's a few things, right? Front loading is important. You need to know that something's coming ahead of time and give yourself adequate space to prepare for it. And I just want to clarify that I support the idea of contractors and bringing contractors in to help with projects, but I think there is a cost. And one of the things you need to be cognizant of is being able to reuse them. Your first project may slow down, and it may take twice as long as initially planned. But if you use those same teams and bring them in for the next project, they're going to have that knowledge and that context and can jump in and out and actually provide some lift like you expected on that first run.

MIKE: I think that's huge. You have to have the [inaudible 09:52] time. Now, that's not an easily digestible message when you're trying to go fast to market [chuckles]. And you could just come up with a new project, right? The answer is going to want to be, well, I want this, you know, already. Why does it take so long to get people up to speed? Well, sometimes that is not a constraint we can mess with, right? Sometimes, we don't get to hire until today.

MATT: Yeah, and I think there's a balance. And to the opposite side of the coin...and we've all heard this, I know, and probably most of us have said this ourselves, and that is, well, I can do it faster, so I should just do it myself. We also, when we do that, tend to create silos, and you can have the opposite effect over time and create bottlenecks that way. So, I think there is a balance, and it's just a skill that you need to learn and find out what works for you, what works for your business, and, if possible, use the same people repetitively, if you can.

JUSTIN: Yeah. Another thing that I think needs to be considered is you have to acknowledge the tech debt that you are accumulating as you go along, and that's fine. I mean, if you are a startup that is trying to get a new product to market, you may not have time to document the things that you are doing, and you may not have the time to go out and help other people understand what you're doing, either.

But you're accumulating this massive tech debt, and you need to make sure that your management or your business partners understand what's going on and the risk that they're taking with you doing all that work. Then, at some point, you got to look at it and say, “Hey, I am putting 80-hour work weeks into this business,” or “I am doing this, and I don't see a way out yet.” And, at that point, you just put on the brakes and say, “Okay, we've got to pay down this tech debt that we've accumulated because it has turned from a we've proven out the business. We're making money, or we're not making money anyway. In some way, there's success. I'm still getting a paycheck.

But you’ve got to pay that business risk down because that tech debt is converting over to business risk at a rapid rate as well. And you've got to make sure that your business partners understand that, hey, there's a business risk here. If I die or go accept an offer in another company, their company that they are depending on is going to face a lot of pain to replace me.

And I think that making sure that, I mean, that's just part of what a senior engineer needs to understand is, hey, you got to communicate these risks back to the business people. And then, they will, hopefully, negotiate with you on ways to address that risk. And that is just the whole list of things that you got to do of onboarding more people, creating documentation, diversifying your products, making it not be a monolith. All of those things are to address that tech debt and that which translates into business risk.

MATT: Yeah. And we're talking a lot about startups. It doesn't have to work perfectly. It just has to work idea, right? But what about the larger companies, or the big, giant corporations, or even a mid-sized corporation publicly traded? We're on the market. We're publicly traded. We're not a startup anymore. And we're facing some of these growth issues where we want to move quickly but decisions have to be made on how does that really happen?

MIKE: Both of you touched on something that I thought was really interesting. You both talked about silos, and interesting, Justin, you talked about silos and tech debt as if they were almost synonymous.

JUSTIN: Yeah.

MIKE: And that says something, that there's some aspect of tech debt that is centralization of knowledge. And, Matt, you talked about developing a technique of sharing. In software, and this has come up over and over again in our podcasts, that we sometimes think about software as coding, which it is, I mean, that's some aspect of building.

But [laughs] it's interesting, I think, in this call, most of us do not spend most of our time coding. In fact, I would think pretty strongly that, looking at who I'm talking with, none of us spend close to most of our time coding because software is about a lot more than just putting down those instructions for the computer, and it's mostly about that communication. And that needs...if that's not central, as you grow, like you say, you can get away with it. If you're small, you can get away with not having that as a key skill. But the more you grow, the more of those connections you have, the more vital that ability to communicate becomes.

And I just heard some suggestions about things that we can do. And that's probably where we're going to spend a lot of the rest of our discussion here is talking about tactics that we can use to deal with that. How do you deal with those communication challenges? Because you can't just scale up. It will slow things down. What can you do to reduce the costs of scaling so that you can maximize the speed of that while minimizing the impact to the software?

MATT: Yeah, I think one thing that is key, and we've been talking about it a lot lately is you need good leaders, and you need subject matter experts. If people are going to be moving in and out of your projects, there has to be a keystone to help guide those projects who has a broad understanding and can lead the people who don't have the knowledge that's required to see it through.

MIKE: So, you say you need to have some continuity, have somebody who understands it and can help people out and can and will, right? Not just can help people out but will. Speaking of will, Will just joined us [laughs].

JUSTIN: So, I've actually got to leave, but Will will take the torch and move it forward.

KYLE: I wanted to add to Matt's comment there. I think it's also, like, along with good leaders, we need to have leaders with bandwidth because if you have too many people trying to communicate with those leaders, then we still get congestion, and I've seen that across several organizations.

MATT: Yeah, I've been the bottleneck a number of times because of that, and that just goes back to that sharing of knowledge. The more people we can empower and the more we can share our knowledge with others, the better off we're all going to be. I think, especially early on in your career, it's a little bit harder for you to share that knowledge because of insecurities. You think, well, if everyone else knows this, what kind of value am I providing? And ultimately, the more you share and the more you empower others, the better off you're going to be, and that provides value.

WILL: And, honestly, I have to say, I mean, in terms of bandwidth constraints, and empowering others, and stuff like that, I mean, I think I came to working a straight job relatively late in my career. And I think, on one hand, like, okay, not great in terms of dealing with corporate politics and maybe expectations of existing in a broader ecosystem, you know, if my commentary in this podcast is any indication. I'm slowly but surely going up.

But one of the good things is bias towards action, and not necessarily any kind of preconceived notions about what I can and can't do and decisions that I can and can't make, where it's just like, oh, the manager hasn't signed off on this. Well, I'm just going to use my best judgment, and I'm just going to do what I think is right, and I'm just going to go. And that mentality isn't necessarily as widespread in corporate America as, I think, even management would like.

I have gotten very, very little pushback. I hesitate to think of a situation where my attitude is just like, I'm just going to do it, and I'm going to do the thing that I think is right. And if it winds up not being the right thing, then I'll just fix it. I can't think of a situation where I've gotten burned on that. But, if you had to come up in a situation where you're just on your own, figure it out; there's no air support; there's no cavalry to be called, so you’ve just got to do it. People don't necessarily think about that.

MATT: That's a great point. I think, most times, some decision is better than none at all because you can always course correct, right, and pivot if necessary. But if you don't make decisions, then nothing's done, and, ultimately, that's bad.

WILL: Yeah, and I think talking about The Mythical Man-Month, I think one of the...and I don't know the context, so I am just sort of stomping through like a child, but I warned you I had a bias towards action. One of the real big stumbling blocks is sort of, I suppose, even when you have leadership going out and making decisions, people being forced serial processes, like a forcing of a serial process rather than people just sort of like...I mean, I hate to use the word wild [inaudible 20:34] because I think that's slanted in the wrong way.

But, like, people just sort of like, well, what can I do to unblock myself to make some kind of progress despite the fact that I have these dependencies, so I will never finish without these dependencies? It's not possible. But what can I do now? And what corners can I cut to continue making progress in the face of constraints, which, you know, a little bit of a trust fall, where it's like, I think this API is coming. But in the meantime, I'm just going to have a fake API that says, “Everything's cool,” where I'm just going to have 200 bot just saying, “You're all right. Everything's cool,” you know.

MIKE: You just hit, I think, on something critical to getting out of some of this Mythical Man-Month problem. And it's come up before in the podcast more than once, the idea of a scaffolding that you're building a building, you're going to put some scaffolding up because you need that support to build it. And that scaffolding is not permanent. It’s going to have to come down sometimes, so it's throwaway work. But you build that scaffolding in order to work around the constraints that you have. You're going to have to build some support structure in order to build

And if you can decouple people to avoid that serial work, so if you can parallelize by having each of those do a little bit of throwaway work to put in some sort of stub, to build some scaffolding around themselves so they can work in an isolated environment, you enable independent work, and that is...the bane of progress is that serial work. If you have to do one thing, and then the next thing, and then the next thing, if you've got something that's going to take 10 years, well, it's going to take 10 years.

And anything you can do to parallelize is going to allow you to scale up quickly, and that only happens when you have teams that can work independently. And you just hit on a key aspect of that is giving teams the ability and incentive to build that scaffolding around themselves and work independently, build separate components that can then be connected once the other components are available.

WILL: I love scaffolding, and I love just doing whatever I want [laughter]. And --

MIKE: That doing whatever you want, too, nobody wants to be a code monkey, to be just a robot. You tell me what to do, and I'll do it. We function as humans when we have autonomy. We want to be able to build our own stuff, which goes to the same idea. If you can break things down into smaller components, then each group or individual has more ownership over their component. And then, they get to have the joy of building stuff, which is why a lot of us got into this in the first place.

WILL: Absolutely. [inaudible 23:32] I'm stirring the pot a little bit, but, I mean, in all honesty, I sincerely cannot think of an instance where a good faith effort, like, where it's just like, I am operating in good faith, and I'm trying to accomplish the goals of the organization, and I'm literally just going to do whatever the hell I want. And I'm going to be flexible if things don't work out my way, or I need to pivot, or I need to revise, or whatever. I can't think of a time it's ever burned me, not a single time, not ever.

MATT: I'm famous for doing this. Well, I'm not famous by any means anywhere [laughter]. But I have a tendency to do that. Often, I just do it on my own time, so I'm not wasting company dollars or whatever. But I genuinely want to see the company succeed because, ultimately, I succeed as well, and my peers succeed because of it. But taking action feels so good and just creating things is an incredible feeling. So, like you said, Will, I do the same thing. I will just get something, some idea in my head, and I will just run with it. And, oftentimes, it's not the right idea, and I've thrown away a lot of work because of it.

But I think the amount of work that I've kept around and that has ended up being used is well worth the efforts and worth the cost of the throwaway work. I do think...I'm not just going to create something and, without any oversight whatsoever, go ship it because that's a bad idea. But I think if you can share your vision with people, especially if you have a prototype proof of concept of something and can help people visualize what you're seeing, it stimulates others’ ideas as well. And they're just going to add to it and make it better, and that's how you grow and find success. I know this is a little tangent from The Mythical Man-Month, but I think that idea still applies.

MIKE: We talk about building a prototype, going out and building something [chuckles]. Throwaway small work is a whole lot less expensive than a major initiative that didn't have some testing first. That prototype, even if you're throwing it away...and you could probably throw away ten prototypes until you find the right one and save a whole bunch of money versus saying, “This is what we're going to go to market with. Let's spend the next 2 years on it,” and not doing that discovery process because, again, it's about scaling down, right? We're talking here about parallelizing work. It's the same idea as scaling down: breaking things up into small pieces that can be worked on independently and tested independently so that they can be brought together later to make a greater whole.

MATT: Yeah, and if you work that way, it becomes much, much easier to bring in people. The smaller the problem, the easier it is to solve and much easier to understand. So, if you do want to add people, it's a lot easier to add someone to broken down chunks of work than it is, hey, we want this monolith of a service built, so here, just go build it for us. You tell me you want to form with these fields on it; I can go build it. You tell me you want something that can intake an application, go underwrite, take payments and service; that's a whole different story, right? It's the elephant theory. If you can do things one bite or one chunk at a time, it makes it really easy to just hand off to others.

RAMSES: You still have the problem of needing to know the full story, though, right? You still need the context of the bigger picture. You can't just work on making isolation on your one component because you might [inaudible 28:08] to get it wrong.

MIKE: Well, that's a really interesting problem [laughs] because that's hard, right, to see the big picture, and there's a lot of challenges with that. So, that's another key aspect of parallelizing work is you have to have some people who understand the big picture, who are empowered to communicate that picture to others. Then, also it talks about how this work needs to be broken down. You have to have decoupled components that can be built independently. And you probably should start by defining what those interfaces are going to look like. What does the API between your components look like so that you don't have to do as much interaction, but you can work towards those APIs; you can code to the boundary and consider that good? Thoughts?

WILL: My biggest takeaway is maybe, as you were saying that, it caused me to reevaluate my sort of preconceived notions, right? I suppose, to some degree, I like to just sort of assume, well, everybody could just do that. Yeah, of course, I want to do this thing, and I'd be like, chopping up workloads, and it’s sort of maybe stepping back and saying, okay, okay, okay. And I’m like, I’ve been doing this for a while. I'm not bad at it. Am I overgeneralizing my own personal lived experience?

And so, maybe the question in my mind is like, how much of that can the average developer in an organization be relied upon to just do? Because I have seen certain types of organizations and certain types of engineers coming in, maybe not necessarily internal to the company, who probably shouldn't be making those decisions because they're trying to rip and run and might not necessarily have the long-term best interest of the project at heart. And so, on one hand, I'm just like, yeah, just go for it, yeah, YOLO.

MIKE: [laughs]

WILL: And on the other, I'm sort of like wait, wait, wait, wait, wait, not for everybody or some people, you know.

MIKE: So, you talked about they want to rip and run, you said, which suggests that there is some incentive structure within an organization that can actually cause bad behavior. If you're rewarding, let's just get out lines of code; for example, you're probably going to push the organization into making poor choices because you're not valuing the decoupling of components. You're using the wrong metric and rewarding the wrong behavior. So, if you want to scale up, you need to think structurally about what your organization is rewarding. Are you rewarding decoupled functional components that could be reused maybe in different contexts and that is a measure of success? Or are you measuring...banging out lines of code? And those are –-

WILL: You said banging out lines of code. I say rapid prototyping.

MIKE: [laughs]

WILL: In the end, it's like, rapid prototyping, move first, and break things, et cetera. You can only do that if there's a lane for you to clean up your messes later. And that's a completely separate issue, right, pretty far afield from the Mythical Man-Month. But, yeah, move fast and break stuff is...I think in a perfectly led and managed organization, the only metric would be get out a prototype, get out a functional prototype that works as fast as you possibly can. Make sure it's not going to endanger the entire business but some kind of [inaudible 32:32] goal. But get it out as fast as you can, validate it, and then build out the real thing, right? An ivory tower, perfect people, perfect decisions, best business outcome kind of a world. But people are messy; incentives are misaligned; maintenance and refactoring a rapid prototype that, like, hit. You got to hit. It's a winner.

MIKE: [laughs]

WILL: Okay, okay, okay, everybody, all right, let's put the brakes on this thing for three months while we refactor it, not to be doggy doo doo, right? That's a tough meeting to be in. That's a hard sell.

MIKE: It is a hard meeting to be in, and it's one that you're going to have to be in a lot because that's exactly how it works. You prototype, wow, this works great. This is enabling a whole bunch of revenue for the business. Matt, you might have encountered something like that recently [laughs].

MATT: I just went through this exercise.

MIKE: And is it ready for expanding to everything today? Oh, well, maybe not. That particular example can probably grow pretty quickly, but there are constraints [laughs].

MATT: Oh yes. “So, it'll be ready by next week, right?” [laughter] I got a lot of that as well.

MIKE: And communicating that is hard. And sometimes the answer is, well, we can use this in a limited scope while we, in parallel, are improving it and building the better thing. And it's painful to communicate, but you have to be honest and say, “Well, this can't do all of the things yet, but it lets you know what we can do in a relatively short amount of time.” We've come back to this a number of times in our podcast, the idea of building prototypes, building small, and failing early because it's a big deal. It's interesting that this comes up in the context of The Mythical Man-Month. We're saying that the only way to be able to scale up is to break down into pieces small enough that they can fail.

WILL: Sure, but that subdivision of the technical labor into small pieces that's really the art of software engineering, software technical leadership, like, real senior individual contributors. That's the real thing. How do you whack that thing up? If you want a pure rapid prototype, there is a lot to be said for just batching it up where it's just like, batch it up, batch it up. There is, I think, an intrinsic trade-off there in that the bigger your prototype is, the bigger the chunk of feature that you need to deliver to test, to validate your theory, to validate this product. The more the demands are going to be on, I'd say, the engineering leadership, the high-level architecture, the engineering managers, or the project managers. People like that coordinate this sophisticated operation.

If you're trying to just hammer out a really stupid, simple prototype, you could just have a couple of dudes kind of just banging things out. I have worked with developers who were not...it's going to sound like I'm shading them, but they're not. They're just sort of like streetwise, get-it-done type devs, and they're wonderfully effective. But they're not necessarily...they don't come up with...so, for what they're doing, they're very, very, very good at rapid prototyping, but they're not really great at multi-billion-dollar scalable systems, right?

And it works the other way, too, right? There's a lot of people who are great at writing very rock-solid scalable code, but they're not fast, right, like a short-order cook versus a Michelin-star restaurant guy. The Michelin-star restaurant guy is probably not going to enjoy the shift at the Waffle House, just slaying hash all night.

[laughter]

MIKE: If you ever watch somebody working a shift at the Waffle House, it's a work of art [laughs]. Amazing.

WILL: Yeah, they're sweating.

MIKE: [laughs]

WILL: And you can watch it, too, because, like, Waffle House it's a...I don't know who made this decision at the Waffle House, but it's a show kitchen. It's all right there.

MATT: Sometimes that's exactly what you need is just some greasy food, whether you love fine dining or not, every now and again, that's just what we want and what we need.

WILL: You had me at want, and then you lost me at need [laughs]. I don't think Waffle House has ever been a good decision for me. I've been there, and I'll be back, but [laughs]...

MIKE: So, I went on a bike ride with my oldest son some years back. Well, this happened maybe more than once, but we were about a hundred miles in. And we went by a McDonald's and got French fries. And I think we also got some sort of sweet drink, and I tell you: need [laughs]. That greasy garbage food was exactly what my body needed because it just needed a whole bunch of bursts of carbs, salt, and grease, right? Calories, carbs, salt; it's the perfect combination. I can't think of another circumstance where that would be an appropriate choice [laughs]. But there is sometimes, there is on occasion [laughs] the right moment.

WILL: Manual labor, like, a full day of manual labor, like, laying brick or, like, concrete, like something just godawful.

MIKE: [laughs]

WILL: Except you want the steak and eggs.

[laughter]

MIKE: Many years back, I used to work landscape. I’ll tell you, I had an appetite [laughs]. I could put down some food.

WILL: That's the truth.

MIKE: Which goes to the fact, sometimes you need that line cook, right? Sometimes you need somebody who can make the greasy food.

WILL: Yeah, I mean, I think a lot of it just really just boils down to that Mythical Man-Month stuff. Like, that's almost all leadership, almost all just people, organizational leadership, product leadership, I mean, really. Like, how do you scope it? How do you organize it? How do you break the thing out? How do you get a prototype through quickly and cleanly? It's...I don't know.

MIKE: Every really successful project I've taken part in started with a conversation between engineering and product, where you said, “What's the problem?” And then you spent probably hours banging away at it, saying, “Well, what are our constraints here? What's most important? What needs to be worked on first?” and, eventually, coming out with a set of milestones. This is what needs to be worked on first. This is what needs to be worked on second, and so on, that can be assigned to teams to work on and probably in parallel, to a degree, right? These are milestones. These are the parts that can be worked on in parallel. Here is our plan for work that can be split across teams and worked on.

And, a lot of times, I've seen the opposite in my career, which is we've got this thing to work on, and here's some requirements, and people just start banging away at it. And then, they reach the end, and pieces aren't matching together yet. And you spend the second half of your project time...right when you thought you were done, you start the second half: getting everything else working, and that first part, clearly defining what your milestones are.

And notice I said product and engineering together. You have to have somebody with the requirements, and you have to have somebody who knows how to build it, and you work together. And this may be more than two people; it often is, but a small group of people who work together to break that problem down and understand where it's going to go.

And when that has been done, those projects have pretty much exclusively been successful. And when that hasn't happened, the opposite has pretty much happened. And I think that it's inescapable. You have to have a map, and, somehow, that's really easy to miss in leadership. It's just you think, well, we're smart. We can do it, right? It's the guy in his car who says, “I don't need a map. I know where I'm going [chuckles].” It works for a while.

WILL: I feel like the biggest ask that I wish I could get out of leadership, and it seems to be like...well, I think I have some ideas around why it goes like this, but I wish there were more product leaders out there that were more disciplined about scope. That's the number one thing out of a product leader, right, where it's like, what's the smallest thing we could do to prove this concept? What's the smallest thing that we could ship? Because complexity doesn't...it's not a linear thing. It's exponential. It's an exponential curve. And it's tremendously that discipline and then the art, really, of saying, “No, this needs to be in there. This is critical”. That complexity is so cutting things out, cutting things out, cutting things out. It's so rare. It's so critical.

MIKE: We started talking about, and we still are, talking about The Mythical Man-Month and how to deal with these communication structures. And we're coming down to needing a product team to be able to define true minimum scope of work and a series of milestones to work on it, which is a strategy for parallelizing the work. Without that, you don't have a strategy, so your work's probably not going to happen very well in parallel. You're going to have just arbitrary work that will not align very well.

WILL: I think product-wise, it's just descoping it as far as you possibly can and no farther, right? And then, it's sort of like engineering-wise, that's our job. It's like, okay, how are we going to get the building constructed? Who's going to lay the concrete? Who's going to run the plumbing? That's us. You can't outsource that. That's engineering. If you don't know how to build a house, you're not going to be able to tell me when the drywall should come in.

MIKE: [laughs]

KYLE: So, I've been kind of thinking as we've been talking. I'm wondering, how far can we go with improving this process? So, that has drawn me to think about hardware. And if you take the human aspect out of the equation, I'm sitting here thinking and looking at hardware and CPU specifically. And when you're working on a task, some tasks, it's very good to just run on that one core: one thread, one core. Other tasks, many threads, many threads, many CPUs, many cores can do that.

Other times, you just start imposing latency between those threads when you start getting too much of that. And if this was a very easy solution, we wouldn't have as minimal core count as we still do to this day. It's quite a bit further along than we were several years ago. But we're still relatively low on our core count and our thread count. And even that industry is they're playing around with solutions. They're introducing higher caches, different layers of caches, different types of core. You've got performance cores, efficiency cores. Where do you spread the workload and hyper-threading? Some of the newer cores they're dropping hyper-threading, and hyper-threading has been a standard on the lower core counts.

And I’m just like, that is something where it's just, like, mechanically, they are equivalent. You don't really get better than that. And that process I guess the controller could be changed. But that process there you can't just keep throwing cores in there and expect to get improvements. It breaks down at some point. And so, we can't really expect...my thinking is, we can't really expect humans to get much better than that at some point.

WILL: I think it's directly analogous, like a parallel program because, as a programmer, that's kind of how I think about...honestly, that's in my mind. I think of it like a parallelly threaded program or an assembly line where I want to keep all the machines busy all the time. And I don't want to have too much work piling up. I don't want to have too much inventory or backlog or whatever or a thread where I don't want my threads blocked.

And exactly as we were talking about the short order cook programmer, which is disrespectful, but whatever, like, the rip and run, fast, efficient, but maybe less scalable solution and maybe less scalable developer that's, like, a single core. It's always more efficient to have everything running on a single core. It's more efficient of the CPU. The CPU will be more engaged and utilized.

KYLE: You don't have to cross-chatter.

WILL: Then the cross-chatter because they all have to synchronize, and they might have to block. And there might be messages passing back and forth, and all of these things add up overhead inevitably. It is always...I want to say always less efficient to have a parallel solution. And I will say it's always more technically challenging to have a parallel solution, always. It's always going to be harder and probably a lot harder. I've done a lot of parallel programming, more than most web devs do. And it's hard. It's tough. It's real tough. The technical bar is higher. The opportunities for bad things to happen are higher. It's just tough.

As people, as we're organizing things, I think your North Star should be what if we could just not? What if we could not do it? Because I am a really good high-performance, real-time, parallel programmer. And I am the first to pass that job off. I will dump that thing off so fast, and I'll be like, what if we just bought more servers?

MIKE: [laughs] Yep.

WILL: Can I spend my way out of this? And I think going back to some of these management things, what if you could not? Can we not? Is there a way that we could not have to do brain surgery and we could just do it the dumb way?

MIKE: Which is a different way of scaling and requires decoupling your work in a different way, independent units that can operate separately. If three work there, oh yeah, it's great. It's not efficient, but as long as I can have multiple units doing the same thing, it works.

WILL: So, we may be out of time. It might be just time to wrap it up. But one question in my mind is always, like, we're tackling and debating the easy part, right? Which is great, but The Mythical Man-Month really becomes a situation where, too late, then what? Because an ounce of prevention is about a pound of cure at least. But [inaudible 49:40] when we're talking about The Mythical Man-Month in those kinds of situations, something already went bad.

KYLE: And it’s already too late.

WILL: Yeah, too late. It’s like, you know what I mean, and that's --

MIKE: What you don't do is double the size of your team when your project is late because now you're onboarding all those people and spending all of the time and cost to build those communication structures instead of allowing the people who already have the context to finish it up. It's in The Mythical Man-Month. I was reading a summary before the call here. It says, puts it this way, "Adding manpower to a late software project makes it later."

WILL: I want to make one very important caveat, right? Very important caveat because, in my experience, when software projects go south, we're talking about sort of these blocker dependencies, and how do we get rid of those. Well, one thing that I have noticed a lot of the time is, you'll have a team, and they'll have these peripheral teams that are building parallel services, other dependencies. It's like, ah, I got to have this, and somebody from this team is going to do this.

And that is a situation when you can and should, and I would argue must, grab their liaison, if there's a liaison, where this team has a liaison in the other team, yeah, you bring them in. You bring them in full-time. You're working on this all the time now. This is all you do. And that has absolutely moved the needle.

And it's a frequent ask of mine to sort of higher levels of leadership. I'll go to a director or somebody who's over a bunch of teams and say, "I need a guy. I need a guy on the pricing team. I need a guy on the AI personalization team to be on my team, to be my embed and be my full-time asset, my full-time resource until we get this thing out," right? That is a situation where you'll have sort of, like, a fractional developer, and pulling them all the way in, that's a needle mover. That's a big needle mover.

KYLE: That's not necessarily, like, a new body, right? That's somebody that has some tribal knowledge, to some extent, that is able to jump in and contribute.

WILL: Maybe. But maybe they haven't started yet, and I need them on my thing now. They could be fully cold and to be like, this is a dependency, and I can't wait to get on your sprint plan and do it whenever. No, you're in here with me now. Pulling in those sort of resources that are blocked that's a big needle mover because inter-team communication it's a sticky point. We're talking about those parallel cores. That's that sort of memory buffer, where it's, like, I need this data in so that I can process it. That's how that happens, torturing that analogy just a little bit more.

MIKE: And you talk about torturing it; I don't know how much that's torturing it. We could say that even in hardware, you would see the exact same pattern to where it really is genuinely analogous. You have units that can do work, and the communication provides so much overhead that the more units you put in there, it becomes less and less effective until you're not getting any gains at all, which comes right back to where we started, which was, it takes time to communicate and to get people up to speed.

And you can't throw a bunch of people who are unfamiliar with the project at a project and expect it to go faster. It will go slower because you have to do all that work. The time to do that is, like, a year ago [laughs]. And if you haven't done that, then it's already too late. Finish what you've got and maybe start training gradually. Incrementally, increase the size of your team so that a year from now, you have been doing that all along, and you've reached the capacity that you'll need with the context you need.

WILL: How do you measure the most that a team can absorb? So, it's like, okay, let's say the real size of the team, that the true size of the team that needs to be...it needs to be double. It needs to be double. You're behind or whatever. How do you measure the rate that you can add people? How do you measure that?

MIKE: Boy, I’ll give you, like, some gut heuristics. That is about all I got. I don't think you could get more than about...the upper bound is probably somewhere close to 25% the size of your team because you get much more than that there's a lot of impact. It depends on how loaded you are right now. If you're pretty loaded, you're probably not going to get over about 25%. So, that's a rough number. If you reach your team by 50%, I think that's going to be a real challenge. And maybe you could do 30% if you've some strong people. But it's going to take you a while to get back up to full function. Now that's my gut sense. What do you all think?

WILL: So, what I'm trying to do is I'm trying to imagine somebody getting up to speed, where it's like, you're going to have some developer, and they're going to need some amount of time let's say a full dedicated pair, dedicated pair, some amount of time. And then, they'll be able to work independently with maybe a half-time pair, and then maybe a quarter-time pair, and then maybe they'll be, you know, asymptotically, they'll hit whatever level of independence which is never 100%. I'm not 100% independent.

So, they'll get to sort of, like, steady state, and then it's, like, how much time can you...and then, eventually, they'll be able to start training somebody else at some later period, right? And so, it's a question of how much capacity can you allocate to getting that done? And, like every developer...let's say every developer adds 5% management overhead, like, 10% management overhead, some amount. And, eventually, the management overhead is going to overwhelm the productivity wins because they'll be stuck. And so, those are the two factors. And I'm like, in my head, I'm trying to think of the equation, the series equation of, okay, how does this work out? Because you're right; I think if you double the team, you're probably going to need two teams.

And then, you're going to need some level of management because you have a manager for both teams and then some level of inter-process communication manager, where you would need a quarter of a director or something like that, some kind of thing, or a product manager. You're going to need something. And so, things will get bigger, and as things get bigger, the overhead kind of starts to get bigger until eventually you sort of clamp down, where if you add a developer, it gives you this much productivity and then takes away that much organizational overhead, and you're just treading water. You cannot do more. That's not a factor of, like, that's just a factor of people, organization, not ramp-up time, right?

MIKE: Right. And it only works if you are able to subdivide in some way to reduce some of that overhead within each part of the unit.

WILL: But, yeah, I don't know, I think maybe you could allocate 20% of your development effort to...I think you could take 20% of your engineering productivity and allocate it to getting the team bigger. I think that's, I don't know, it's kind of stinky from a statistical smell sort of a thing. And I'm like, okay, if I've got a team of four developers, I could have maybe one guy, one guy carrying out building out the fifth guy.

MIKE: Yeah. Well, you came to the same number I did [laughs].

KYLE: I kind of was thinking 10%-20% in my head, too, so right in that ballpark. But it's one of those things where I was hesitant to answer because it's that age-old question: what is a team size? If it's one person, that's a massive impact. If it's two people, it's still pretty big. At what point is it actually feasible to onboard somebody during a project release, you know, you've got a month to go. At what point? Is it four? Is it five? Is it six? Then you actually have somebody that's available to train while the other ones are getting the project done to actually make it beneficial.

WILL: Just going back to Matt and Mike's original statement, which is just sort of, like, at the point that you are adding developers, you have implicitly admitted that your deadline's hosed, right? You're either descoping, or you're pushing it out, right? That's it. It's like, oh okay, well, all right. So, if I'm going to take 20%, 20% and say, “Okay,” then it becomes a situation where you're going to have a certain amount of ramp-up time. And every developer is going to be different. Some people can just hit the ground running, and we're going to go. You're going to throw your strongest dev on there. They're probably going to take, like, a week, maybe.

And then, they're producing at 50% capacity, and then another week 75, and another week 100%, something like that. And so, I was like, okay, well, I take 20% of my productivity out, and then I could map this out. So, what you need to do is you need to be pushing your deadline out, so let's say the deadline goes out by 20%. And then, you need to have a developer that you could reasonably expect to be...how do I put this? If your timeline is infinite, the one-time cost of onboarding a dev kind of goes to zero.

MIKE: [inaudible 1:00:51]

WILL: And then, [inaudible 1:00:54], then that's bonus, 25% improvement, good to go. If it's a year out, probably negligible. If it's a week out, not worth it, right? You need to be able to amortize the one-time hit of adding a developer and onboarding them and have that be worth it, either because the project's going to be longer term, or we're going to bump out the deadline. Or if you want to keep the deadline, you're going to have to descope. There's just no other way, right?

MIKE: Right.

KYLE: I need to --

WILL: And I'm sure I can math this, but I would have to stop talking and draw on a piece of paper.

MIKE: Yeah, and you nailed the math, right? You're going to have to balance the hit versus the productivity you will eventually get. Do the math. There's maybe a little fun that you can, you know, eyeball it at the back of the napkin. Go ahead, Kyle.

WILL: Or, I mean, it would be –

KYLE: I was going to say, I'd have a hard time with all of the different variables because, even then, you know, we're like, okay, cool, it's 20%. But 20% of whose time and what? Because 20% of my productivity might be vastly different than 20% of Will's productivity, and then averaged across the team, each team is going to be different. So, you're going to have to figure this out on the fly on every project that you're on. And that seems, I don't know [laughs], that seems like it's getting very complicated to try and figure out.

WILL: So, it's just art, not a science, or not a science. Because another thing is, the first week, you can have your junior dev on the first week. He just needs to know where all the light switches are. That's all you need. But on their third week, that sort of maybe one day of pairs time, let's say, then they actually need the senior dev because now they're actually going down rabbit holes that they're getting. They need to make good architectural decisions. And maybe you only have one kind of tippy top dev that's like, okay, I know exactly where this thing is going.

And so, that impacts scalability because your engineering team lead, managers, by and large, should not be relied upon to make specific technical architectural decisions because they don't live in it all day. You could rely on them. Hopefully, they're not total idiots. But in terms of what's this class called? Where does this thing go? What does this API look like? Under the hood, how are we coding this thing up? What goes on the task queue? What are we running? It's just all kinds of stuff. That's the tech lead's problem, and they only have so much time. They only have so much time in the day, and they could [inaudible 1:03:40], right?

MIKE: So, I would suggest, to Kyle's point about it being hard, I think it's almost unwinnable. So, I think the best way to do it is you just say, you know what? I'm going to invest 20% indefinitely, and I'm going to realize it's not going to help this project. This is my long-term investment. It's the same as you're paying down the tech debt. You're paying down your tech debt. You're investing in your next generation of engineers, and you pay that 10%, 20%, whatever it is. You just have to have a constant background of somebody new on the team learning the system.

And if you want it growing, you have somebody on the team, not expecting them to help yet. You're doing that so that they will be able to help later. And if you're continually doing that, well, you got compound interest because as they become effective, you got your next 10%, and your next 10%, and your next 10%. You can get to that double size of the team maybe within a year.

WILL: I freaking love cross-training and cross-teams, where it's maybe you lend that 20%. Maybe you lend that guy to the other team, sort of your brother or a sister team, so there's like, uh-oh, we're in it. Can you jump in quick? Do you know our systems well enough so that you can jump on and move the needle for this thing that has gone pear-shaped on us? You could do it because you already did that.

And you have a ready-to-go developer that knows your stuff well enough so that their ramp-up time is a day or two, not a week or two, like a day or two. Because I know where the bodies are buried, and I can help you get on this thing where this deadline is screwed up. Plus, it's just fun. Cost sharing is fun. Business logic, I don't know, man, you have to continually keep yourself re-engaged in the work. And just doing the same old things the same old way, week in, week out it becomes a grind.

KYLE: Well, in cross-training, I realize this is a tangent, but in cross-training, it simplifies communication, too, because I realized today, somebody asked, "Well, do you guys have automation?" Automation what? What kind of automation? What are you talking about? To different teams, that's going to mean different things, right? There's several cases like this, whereas if I've cross-trained with a team, it’s like, that's the kind of automation that they're talking about, and we don't have to take time to figure out what it is they're communicating about.

WILL: Cross-training is great just because I keep a book of people that I have done a favor for, and when I need an answer, I can get one. And they'll just be like, oh, that's Will. Like, he's a bro. He's good for it. I'll help him out. Because if I don't know you and you're just coming up, I'll be like, “Go to the PM. Go to my manager,” because I don't know you, and I don't know if you're good for it. I'm not going to see you again. You just don't put a problem in my lap, and I got plenty of my own.

MIKE: [laughs]

WILL: And people are like that. If I know you, I got you. If I don't know you, then you got to go through channels, and going through channels that adds a day to your turnaround, every single time. I'm not sorry about it because there's a lot of people who will dump on you and give you back nothing. The overwhelming majority of help requests are people who came and did a drive-by, bang, bang, bang out the window. I've never heard from them before or since. And the next time I see their face, it's going to be the same thing. And I'm going to do it, but you're not getting the express lane. You got to take the [inaudible 01:07:37] with everybody else.

MIKE: So, you avoid getting entangled in other people's work and enforce that process so that we can actually have those boundaries. Because as we've talked about this whole time, those boundaries are how you parallelize and make things work, which is --

WILL: I'm not going to try and justify it [laughter] as anything other than selfishness. I'm not going to try and justify it. Because, in the end, nobody wakes up in the morning thinking like, I'm going to wreck Will's day. Something went wrong. Something went wrong, and the broader organization is responsible for it. And, I don't know, man. If I find out who's giving out my name like that, then that'll be a conversation to have but --

MIKE: I'll justify you on your behalf. I think that you are maintaining boundaries, and that's actually a valid and critical part to what we've been talking about. And maybe that's where we end. You have to have boundaries. You have to have boundaries in your organizational structure, and they don't just appear by magic. You have to plan and recognize that it takes time. It takes time to form these units. And if you expect to get anything done, you can't just tear that apart or throw a bunch more people at it, not going to work. You have to plan it out. And it's a problem that goes all the way down to the hardware.

WILL: Yep, yeah, and do favors, and make sure you keep a book of markers, man. Make sure you got favors you could call in. It moves the needle. It gets things done. Otherwise, it would be difficult [laughter]. [inaudible 01:09:29] a little horse trading.

MIKE: With that, thank you. I think that's a great place to stop, and until next time on the Acima Development Podcast.