The Mythical Man-Month by Frederick P. Brooks (August 2017)
Good morning,
Welcome back for another round of the Business Bro Book Club. Today’s feature is The Mythical Man-Month by Frederick P. Brooks.
The last time I rolled out the book club concept, my counterpart here got all sniffy about my initiative. For some bosses, I guess 'coming up with a good idea' really means coming up with a good idea they would have come up with.
So, for this week, I invited him over in the spirit of a book club to have a conversation. Hopefully, no feelings get hurt in the process. Please enjoy our TOA-BB collaboration below.
Signed,
The Business Bro
*********
TOA: So, want to summarize the point of this book for the readers?
BB: What, no hello? No how you doin', how you beens?
TOA: I thought you'd prefer to get straight to business? Well, in that case, I've actually been kind of bored, you see-
BB: Ah, no, you had it right the first time, my mistake. Anyway, specifically, Brooks writes for managers of large-scale software development projects.
TOA: Right. Well, having never held such a position myself, I can only speculate on the book’s value for these managers. And since I know you've never-
BB: Quiet, right, I had a good feeling about it. The reviews from other readers were consistently glowing and a lot of what Brooks wrote matched up with my own intuitive sense of the topic. I am comfortable suggesting this book is required reading for those looking to deepen their understanding of this particular role and a decent bet for anyone who wants to learn more about running a project.
TOA: I see. What makes you suggest this book will have appeal beyond just a software project manager?
BB: Well, I think a lot of what Brooks covers is applicable to managers in general. He gets into concepts like growing rather than building a team, for example, which will appeal to anyone with an eye on the long-term challenges of leadership.
TOA: That’s surprising to hear about a book focused on project management.
BB: Why are you surprised?
TOA: Well, I kind of assumed project management was a short-term thing, at least in terms of teams. Once the project is over, everyone goes to do something else.
BB: Wait, well, I’ll get back to that, but I meant why are you surprised to learn this? Didn’t you read the book?
TOA: Why would I read the book?
BB: This is a book club, man, you’re supposed to read the book!
TOA: Still with the book club? Sundays are for reading reviews, I told you to stop with this book club nonsense.
BB: So what did you think the point of coming over was?
TOA: I thought you were gonna talk about the book.
BB: I was, with you!
TOA: Hmmm, I was expecting more like a business meeting, where we talk in clichés and generalities and analogies-
BB: Right, analogies, like how half your posts are written, in analogy, so you can pretend to know what you are talking about.
TOA: Interesting to hear that from you! Actually, not knowing what you are talking about is the only thing you might have any expertise in-
BB: OK, well, whatever, we can have it your way, it's too bad though, since you missed out on some pretty good analogies Brooks was kind enough to include for the clueless reader.
TOA: Why would anything for a clueless reader interest me?
BB: Ha, I see, well, better to never read at all than be clueless, eh? Well, anyway, I was referring to how software projects are prone to being scheduled by your demographic and therefore-
TOA: What demographic?
BB: Clueless customers, clueless workers, cluessless people, clueless. Stop interrupting.
TOA: Whatever.
BB: As I was saying, it’s a lot like going into a seafood restaurant and asking for the meal right away. The chef can tell you to wait or the chef can serve it up raw. A software manager might hem and haw and even arrange a meeting to talk it over with the most sociable guy in engineering.
TOA: Fine with me, I like sushi.
BB: Yeah, right. People like you with no technical savvy don’t get the distinction. Two months later, guess who comes back to complain about a shoddy product?
TOA: That was a stupid analogy. People like you with more suits than knowledge should know better than to serve up a raw meal. If a chef ever screwed up like that, he’d end up fired.
BB: Well, the point is that people who don’t understand the natural schedule shouldn’t try to change the timelines. It’s like how it takes nine months to bear a child. Assigning more women to the job doesn’t bring the baby along any faster.
TOA: That’s the dumbest analogy yet. Only a business bro would even think of using the expression ‘assigning women’ in the context of childbirth.
BB: Whatever-
TOA: Plus, doesn’t that contradict the whole ‘both of us read the book for book club?’ idea? It isn't like if the two of us read it at the same time, it's gonna get read any quicker-
BB: The point is that software projects suffer whenever leaders assume time and manpower are interchangeable. New hires don’t necessarily make the project finish any faster.
TOA: Why would that not be the case?
BB: It’s the nature of software projects, especially large ones. Adding people to the team might reduce the time spent on one part of the assignment. But the new people will have to communicate with the rest of the team. It’s the increased communication burden that slows down the project.
TOA: You don’t need to tell me.
BB: What?
TOA: Never mind.
BB: Right, well as I was saying, if the scope of the project is large enough, the higher communication cost will offset the positive gains from adding manpower.
TOA: Huh. So it’s like having too many cooks in the kitchen?
BB: Sort of, I suppose.
TOA: As long as they don’t serve up raw meals?
BB: Maybe.
TOA: Maybe?
BB: Well, it’s not a bad understanding coming from...an illiterate...
TOA: Excuse me?
BB: I mean, what's the difference if you don't read? Why even know how?
TOA: Oh please, like you ever bother-
BB: Never mind, this is going on too long, anyway, but the problem, I mean, is that cooks generally get involved early in the process. What Brooks really looks at is toward the end. Maybe too many servers at the tables is the better comparison.
TOA: Your analogies need work because you take them too literally.
BB: Your analogies need work because you don’t understand the comparisons.
TOA: You need work.
BB: You can say that again.
TOA: You need work.
BB: Are we done here?
TOA: Wait one second, I did actually want to clarify something else. So this book then is saying - don’t add anyone to projects? Seems simplistic, and a recipe to get sacked.
BB: No.
TOA: But that’s what you said.
BB: I didn’t say that.
TOA: You did.
BB: I said adding people can cause the communication burden to go up.
TOA: That’s the same thing.
BB: What?
TOA: It’s the opposite of the other side, which makes it the same thing.
BB: No, it isn’t. You’re working with a false duality. This is a continuum.
TOA: False duality? Continuum? Are those your words of the day?
BB: I’m saying it’s not like you do the opposite of adding people, what you do is structure the project so it can accommodate more people later.
TOA: And how would you do that, you old business bro, you?
BB: I’m getting there. One way is to add people only to parts of a project where the task is divisible without extra communication.
TOA: That’s obvious.
BB: Right, obvious. I’m stunned by how many concepts you dismiss as ‘obvious’ despite never coming up with any ideas yourself.
TOA: But all you are saying is less talk, more walk?
BB: Well…
TOA: Then it’s obvious.
BB: I think it’s about time you walked.
TOA: Yeah, I’m thinking along those lines, enough talk for now. Same time next week?
BB: What?
TOA: I’ll read the book and come back, I promise.
BB: Oh, don’t bother. I’m going to write my own thing about this book.
TOA: Hmmm, sounds almost like an application of this book.
BB: How?
TOA: Well, by not communicating anymore about it, it’s easier for you to get more ideas across.
BB: Yeah, maybe that’s true, but it's irrelevant.
TOA: I mean, it’s what you just said.
BB: There’s no substitute for the reading.
TOA: OK, fine. I’m gonna do my own review when I finish reading.
BB: That sounds good. We'll need content in 2023.
TOA: How should we split up the topics?
BB: Doesn’t matter to me.
TOA: Well, how about I write my post and you just cover the rest?
BB: You’re the boss, boss.
TOA: OK, then, until next time.
BB: See you later.
