A Metaphor to Explain 5 Tech Industry Jobs

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.

A Peek Into the Open Source Technologies Behind CapitalOne.com

(This is a post I made on Capital One’s tech blog.)

Ever wonder what goes into selecting technologies for one of the most trafficked banking websites in the world?

According to Alexa.com, the CapitalOne.com home page is ranked the 49th most popular site in the US and the 253th in the world. To maintain and enhance the functionality of this mission-critical site, we at Capital One have partnered with the open source community to address the incredible technical challenges associated with being a high profile web destination.

I oversee the team implementing the new technology platform behind CapitalOne.com. During the 2016 ng-conf keynote (I speak at the 56 minute mark), we were invited to present our cutting edge solution that leverages popular technologies such as the Cloud, Node.js, Angular 2, TypeScript, and Angular Universal. This post is based on the content of that talk.

Enterprise Constraints

Our website engineering teams must balance a number of difficult technical issues which can be generally grouped into:

· Performance


· Accessibility

· Distributed Nature of a Global Engineering Team

The first two issues — Performance and SEO — have clear revenue implications for any website. As a financial institution, we have additional regulatory requirements when it comes to the third issue — Accessibility for all users. Finally, with dozens of engineering offices across the United States, building complex JavaScript applications can be unwieldy as code bases grow and teams are not collocated.

Looking at Angular 1

The good news is that “Performance” is a relatively straightforward problem to address. In our case, move as much of the application to the front-end and leverage the full power of a CND. In building the first iteration of our website solution, we started here, with Angular 1. However, the limitations of Angular 1 became immediately apparent as it impacted our SEO or Accessibility issues.

The source code of a typical Angular application is boilerplate “loading” text/image and some JavaScript tags. This “initial state” HTML is not what the user ultimately interacts with and tells you nothing about what content will be on the page. Our problem emerges when screen readers and crawlers — often not as robust as a modern browser — get confused and do not “see” what we he developers expect.

In short — the HTML is a mess.

For example, if your team uses Slack and you go to send a link, Slack will crawl the page to create a preview. If your application uses traditional Angular boilerplate, the crawler will not know how to interpret the JavaScript.

As a result, the preview might break if the page title is determined in the JavaScript code. You would see this same problem if you tried to share the link on Facebook.

Ideally, crawlers and screen readers would be able to see the “end state” — or what the user ultimately sees. To address this, the ideal solution is for the cached source to reflect the “end state” and the page to retain the Angular application behavior. An advantage of this is that performance is dramatically improved since JavaScript doesn’t need to download and run for the page to appear correctly.

Building It Ourselves

To address this, our team decided to build a solution that combined Angular 1 with server-side Node. This would involve building a pre-rendering service that would determine the HTML “end state” and cache it.

We looked at every page we wished to migrate and built two versions of it: a “fragment” version and a “full page” version.

The “fragment” is the content (images, text) for a URL and the “full page” is that same content with the menu/header/footer surrounding it. We served the appropriate file based on the context of the user: “full page” for a first time visit and “fragments” as users click around.

The “fragment” experience would swap out the contents and leave the surrounding menu/header/footer in place. From a load time perspective, this performed extremely well.

But this solution was limited. Out of Angular 1’s many features, our pre-render service only managed to port over one aspect, the route (URL) changes. Other components of Angular functionality such as directives, filters, and services weren’t being evaluated by our pre-render service.

This meant major parts of any given page could not be determined server-side. We concluded that Angular 1 had limitations that ensured it could never fully support our specific use case.

We needed a more robust solution.

Enter Angular 2 and Angular Universal

Thanks to a major rewrite, Angular 2 with Angular Universal fully supports server-side rendering.

A rough example would be that this is like the browser being emulated on your server — allowing you to pre-render the HTML and cache it. When we heard this, we immediately started planning to leverage this capability.

With Angular 2, the source code resembles normal HTML and if you link to a cached page, everything works as expected. Every feature of the Angular framework codebase gets run server-side.

We still use the same “fragment” and “full page” caching strategy from earlier, but the remaining drawbacks are eliminated. This strategy has some additional major performance benefits. Normally, the user cannot interact with a web application until a number of serial processes are finished:

Download the HTML * Download the JavaScript *Run the JavaScript.

While this is happening, the user often sees just a white screen or a loading spinner.

In the Angular Universal flow, the user can see and interact with the page as soon as the HTML downloads. While the JavaScript downloads and boots up, we can capture user inputs and play them back via a nifty library called pre-boot. This yields a performance boost of hundreds of milliseconds, making the application feel much snappier and more responsive.

Best of all, we now have a cache of exactly what our visitors see, and our developers can build their systems using standard Angular 2.

Don’t Forget TypeScript

JavaScript has a problematic reputation with some enterprise developers due to issues like inconsistent browser support, lack of classical OOP, and weak type support. Whether these criticisms have merit or not — or apply to your project — the Angular community listened to enterprise developers and proposed a solution.

Angular 2 leverages an amazing new programming language called TypeScript. When this was first announced, the decision was greatly criticized. Fortunately, the community has come around as developers have pushed the limits of Angular and JavaScript.

The benefits of TypeScript to enterprise — and large code bases — cannot be overstated.

This technology adds key new functionality to JavaScript — it forces dependencies to be called out explicitly, enables types, supports stronger OOP through the addition of interfaces and generics, and provides compile-time error checking.

The main takeaway: TypeScript provides many of the benefits of a language like Java while avoiding the baggage. It works well for large, distributed teams where the code needs to be self-documented, catching bugs earlier (via compilation). Best of all, it runs on Node.js.

Wrapping Up

The CapitalOne.com team is grateful for the hard work that the Angular teams have put into making these great technologies. Together, Angular 2 and Angular Universal significantly advance web development for the enterprise community. We look forward to remaining a part of the Angular community and working with these technologies on additional projects.

For more on APIs, open source, community events, and developer culture at Capital One, visit DevExchange, our one-stop developer portal. https://developer.capitalone.com/