In this post, I will detail 5 jobs in the tech industry using a book-writing metaphor:

• Product manager
• Software engineer
• Software engineering manager
• Project manager
• Program manager

Let’s write an epic novel: Lord of the Bracelets!

Here are the rules of this exercise:

• We will compress the time it takes to write the story by doing things in parallel
• We will break into teams
• Teams will work on one or more chapters
• Many sections may require multiple teams to work on it simultaneously

Who Decides What to Do?? Product Managers, mostly.

The Product Manager determines the requirements (the “why” and “what“), after extensive market research and analyzing business needs:

• We will write Lord of the Bracelets.
• It will span 3-books because that maximizes revenue.
• We want the first book done in 12-months.
• It will cater to fashionable teenagers because they are more affluent.
• It must mention evil fashion executives because that’ll sell more.
• etc…

The requirements would be very detailed and break down individual story arcs, locations, and characters. Product Managers are also responsible for making sure the final story actually matches their requirements.

You might imagine this makes the Product Manager the boss of everybody, but in practice, they are usually a peer. The Product Manager tends to use influence to get people working on the right priorities because they tend to have the most perspective on the trade offs. If you aren’t good with people, don’t enter this profession. Because of its close alignment with the business needs, MBA’s tend to be attracted to this role.

Each team will usually have one (or share a) Product Manager. There would be a team of Product Managers for a project of this complexity.

The “Doers” Come in Many Forms

Software Engineers are the writers (the “how”). They come in many forms and you might hire different ones for different types of writing. For example:

• Action scenes
• Funny scenes
• Engaging dialog
• Building suspense
• etc.

In the same way, there are Software Engineers that specialize in mobile, data, algorithms, user interfaces, etc.

If you thought engineering is anti-social, I am here to dispel that myth. The Product Manager can’t dictate every last detail; otherwise, they might as well do the writing themselves. Because of the small decisions one writer makes in one part of the story impacts another, collaboration becomes necessary. Have you ever thought about how much collaboration writing a book might require if you had an army of writers writing chapters in parallel?

• What is the current weather as of Chapter 10? Will it matter in Chapter 11?
• Did we already discuss the origin of the bracelet by chapter 8, or did we agree that Chapter 12 would do that?
• Can we add subtle romantic undertones between our protagonists if it doesn’t change the ending? Wait, should we call the Product Manager over?

In practice, Engineers will spend a significant, double-digit percentage of their time in meetings and discussions with other Engineers. Writing any meaningful software requires thousands of person-hours.

It is extremely common for the Engineers to negotiate with Product. A common reason for this is that a requirement “changes” (or gets clarified) and the engineers don’t believe it is wise to rewrite 2-weeks of work. Engineers have ideas too, and they may influence the Product Manager on a different way to achieve the same business outcomes.

In a given team, you might see 5-10 Engineers per Product Manager.

What does the Pointy-Haired Boss do??

Software Engineering Managers know which people are right for which jobs since they hired the team. In our metaphor, they are assigning chapters to writers (the “who”). They are ultimately accountable for hiring a team of writers (software engineers). For example, they match up the dialog-heavy chapters with the writers who are masters at that.

They might also act as a proxy for the writers by going to meetings, getting requirements, or coordinating work. If Michelle notices a plot hole, she might ask her manager to get clarification from the Product Manager (unless this is a Hollywood blockbuster, in which case she would just keep writing).

Managers also do the classical “management” duties like evaluating performance and making sure people are working on their assignments. In practice, engineering isn’t the type of job where heavy oversight is often needed except in extreme cases (like if Billy just stops showing up). And just like with the Product Manager role, this is a role that requires strong “people skills.”

Each team usually has one Manager.

The Project Manager Watches the Shot Clock

The Project Manager manages the schedule and resources (the “when”). Their goal is to understand, across all teams and necessary “work,” if we are on schedule or not. I stress the term “work” here for a reason that will become clear in the next section. At a high level, the project manager has a few core duties:

• Quantify the work
• Analyze the bottlenecks
• Provide timely data to everybody so they can react to the problem

If you recall, we want to write our book in 12-months. Here is a simplified example of what a Project Manager might stress over:

• We have 11 months left in this project timeline (8.3% of the total time has passed)
• There are 120 total chapters (10 chapters a month)
• In the first month, five teams wrote 9 chapters
• Are we on schedule? Nope!

In the above example, a Project Manager might further analyze the cause of the slippage. For example, what if we learned that 40% of the chapters were rewritten because the requirements changed? (this problem is sooooo common!!) The Project Manager might do the same quantified analysis of the Product team:

• We have 11 months left in this project timeline (8.3% of the total time has passed)
• There are 120 total chapters (10 chapters a month)
• To catch up, we need to complete 11 chapters in month #2
• In month #1, the Product team completely revised 5 chapters (effectively writing 15 chapters)
• The Product team has completed the requirements for 17 chapters (of 26 needed at this point in the project)
• Are we on schedule? Nope!

In this example, the problems are that the chapter requirements are behind schedule and that the team is re-doing a lot of work. This type of analysis is the heart of project management. They help the other members of the team understand why things are falling behind.

There would be a few Project Managers per project (sometimes just one). In corporate, you may see roles called “Scrum Master” or “Delivery Lead” which fall inside this category.

Somebody Tracks the Work that isn’t THE Work

Recall that I highlighted “work” earlier. It turns out there is more to shipping something than writing words on pages (or code in a program). The best way to think of a Program Manager is as a super Project Manager of multiple projects. But unlike a Project Manager, their focus will span far beyond the core project or team (“When” and “Where”). Program Managers will deal with a conglomeration of many other important, but easily missed projects:

• Did legal approve the title?
• Who is our distributor and did we get the printing press deadline?
• Did we get final approval on our budget to hire all these writers?
• Did we negotiate an extension for book #2 with the publisher?
• Did we hire a design firm to do our cover?
• How will we make the book available on Kindle and/or Audible?
• How are we distributing royalties?
• Should we re-use this new team to pump out more books in the future?

Program Management comes into play as soon as a project becomes more than just one project. You can imagine each of the above topics having its own project with timelines and requirements. You can’t re-use chapters beyond the book it was written in (the project), but you can reuse the legal contracts, distribution deals, royalty structures, etc. Program Managers tend to focus on topics that tend to branch out beyond any one project.

If you are really paying attention, you might have noticed that the timelines didn’t include time to print the book. The Program Manager helps to reveal these types of cross-project gaps.

There are very few Program Managers in a project. Maybe one or two shared with many other projects. Project Manager careers tend to move toward this role over time as they gain seniority.

It Takes an Army to Ship Software

To summarize using the “Five Ws” framework:

• Product manager – Why and What
• Software engineer – How
• Software engineering manager – Who
• Project manager – When
• Program manager – When and Where

It is not unusual for a major project to involve dozens or even hundreds of Engineers. Without each of the above roles doing their job well, the complexity and lines of communication can grind the project to a halt.

I hope this metaphor successfully detailed the roles involved in shipping a piece of software. There may be variance across companies, but the functions should be consistent.