Program Management Book Club - Intro & Chapter 1


I got a new job recently that requires a lot more task, time, and project management than what I’ve done in that past. I am broadly familiar with what it takes to do project management, but it’s mostly been me applying helpful ideas and lessons from that world to my problems. My role is doesn’t require the kind of professional project management that you see in IT departments.

However, as I often like to do, I decided to pick up @bcotton’s book, Program Management for Open Source Projects, to grow my brain a little bit. I know I won’t be able to apply everything in here, but I will be able to shop for ideas. That shopping ability - being able to advantage of models that work for me and modify or drop them when they don’t - has served me in the past. Now is a good time to deepen my project management skills.

I also like to write, as evidenced by my unwarranted scattershot comments in this forum. What if I could use this book to write stuff, and let the writing help me to synthesize the most important takeaways for me? I think that could help me make what I learn more concrete and force me to pick up something.

Lastly, I’ve always wanted to try a book club, but never have. Instead of blogging my thoughts, why not open it up to discussion among peeps who may also be interested in program / project management?

Thus, I extend this invitation to you. I’m going to read this book a chapter at a time and give my thoughts. if you would like to read along with me or just give your thoughts based on what I glean, that would be cool!

Disclaimer: Joseph is a grown man who is free to not read books or write words whenever he wants. He is under no obligation to continue this idea beyond this first post.

Introduction & Chapter 1: Manage the Program

First things first: this book is definitely what it says on cover. It’s a book about program management for open source, who’d a thunk? But Ben also shows how program management is made up of a lot considerations, skills, and systems for dealing with the abstract challenges that can come up in the role. If you’re someone who thinks about their work in terms of systems or structures that you set up for yourself, I think there will be a lot you can glean from this.

You’re going to be doing it anyway

The actual first takeaway I have is from the top quote in the introduction: “everyone does program management, some just do it poorly.” My current job is not in software development or IT at all. I work as an analyst helping to make business decisions for the future. On the surface the workflow doesn’t seem related, until I noticed I have regular self-contained changes (tickets) that have to be entered by a certain deadline (release) that also have to be validated before being pushed downstream (QA). It’s similar enough to software development that I could fall into the same traps and bad habits as IT departments might fall into. I want to be aware of the fact that I could be working much more inefficiently than I need to. I guess it emphasizes my need for the book, lol.

Simplify your communications

My second takeaway is about the idea of communication overhead. I’m going from a small team that worked with one or two people to a new team that works cross-functionally with like 6 other teams. In my new role we book two-parter meetings with about a dozen attendees as a core part of moving through our workflow. It’s a change of pace for sure. That’s why this quote stuck out to me.

The number of communication channels in a team goes up exponentially as the team grows. Communication overhead gets even heavier in open source projects where members of the team come and go, sometimes without warning. A successful program manager reduces the overhead by collecting and distributing information across the project.

Each additional person my workflow brings with them their own style and preferences of working as well as their own expectations for being contacted or contacting others. Folks in my job are valuing and paying attention to this process to try to improve it, don’t get me wrong, but it’s also validating to read that communication overhead is a real thing that can grow and get in your own way. It’s important to find a system of staying on the same page so that you can avoid becoming reactionary.

This observation from another book emphasizes it further:

In The Mythical Man-Month [Bro95], Fred Brooks said “adding manpower to a late software project makes it later.” His reasoning is simple: when more people are involved in a project, more communication channels are necessary because each person needs to communicate with all of the others. A key function of your job as the program manager is to counteract “Brooks’ Law” by simplifying the communication channels.

Keeping everyone informed will bloat the communication systems we have if left on their own. I need to find a way to keep my team and stakeholders in the loop of my work in the simplest way possible to fight against the tangled mess that will naturally come up.

Keep frameworks for prioritizing tasks in your back pocket

Third and final takeaway: collect frameworks for prioritizing tasks. I think this is common with a lot of knowledge work. I’ve been working with a modified version of the ABCD method I learned from Mariana’s Corner wherein you prioritize tasks based on those that are important and have bad consequences when not completed, important but no consequences, unimportant but with bad consequences, and unimportant with no consequences. Pretty similar to the Eisenhower Decision Matrix that Ben presents.

Then Ben provides a few more nuggets of wisdom in the form of these criteria:

  • Prefer finishing work
  • Prefer usability over capability
  • Prefer differentiation to catch up
  • Maximize the total benefit
  • Reward long-suffering
  • Expand the community

Can I use a lot of these? Maybe not, but I do want to have them in my back pocket. They give me a different perspective with which to view my tasks. The first one in particular about finishing work before moving on to something else is helpful because it balances out another desire I have to give myself variety in my work day. It can be better to hand over deliverables one at a time rather than having multiple tasks in progress but not done yet.


Good book. Helpful ideas. Post is too long and it’s getting late so I’m calling it here, lol. Not even gonna proofread. Would be cool to hear anyone else’s thoughts if they have any!


I was recently asked “if people only take one thing from the book, what do you want them to take away?” It’s that opening line. Nothing I wrote in the book is particularly novel. I’m not inventing anything new here, just setting out a framework for doing things with intent. I’m glad that jumped out at you.

As the author, I don’t want to jump into this thread too much, but I’ll be around to answer questions or respond to feedback.


I love this! I’ve created a book-club tag in case it inspires others — and also so this is random no more. :classic_smiley:


“everyone does program management, some just do it poorly.”

This line is so good, I am jealous that if I ever write a book on Continuous Integration(which is on my list of lifelong goals) I would not be able to use it :slight_smile:

I like this kind of humble approach to the topic, where we don’t make it look like a secret available only to a few experts, but rather see it is a natural intuitive thing. And our job is to look around, recognize it and learn how to talk about it, so that we can share experience and lessons learned.

I feel this way about CI. But also, for example, about Mathematics.


You’ve touched on one my personal guidelines when looking for resources on work and productivity. If the person wants to pitch their ideas as a secret solution that’s actually super easy to implement, I don’t trust it at all. Everyone’s different and you have to find a way of working that works for you. When someone comes out and says ‘these are my goals, and these are the things I do that help me,’ that’s when I listen. Humble approaches tend to be really insightful, in my opinion!

Oh wow, thanks for this! Really cool!

For anyone who is interested in tagging along, I figure to post about the next chapter in a week or so (no promises) so you have time to read this section if you want. Otherwise, this is an asynchronous book club, so you can really chime in with your thoughts at any time in the future, in whatever order you want. Hope it can be helpful or interesting to you. :+1: