Preface
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.
Conclusion
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!
