Big companies require big buildings. And big buildings require big workforces to fill them.

The Engineer’s Guide to Companies

In which I continue my thoughts on the effectiveness of bureaucracy

This article is exclusive to Pointer — a reading club for developers.

Sign up at Pointer.io for our weekly newsletter.

In my previous, totally important technology business article, The Engineer’s Guide to Management, I explained how massive management infrastructure is necessary for running an effective engineering organization. If you didn’t read that other article, you probably should. I’ll be using a lot of the same highly technical terms in this article (words like “company” and “management”), so it might help you to familiarize yourself with the terminology and discussion so far.

Go ahead, I’ll wait.

…

Okay, ready? Good.

By the end of that previous article, we had developed the structure of a typical engineering company (in our case, one which manufactured products to put out fires, using a bucket-brigade development process), which looks roughly/exactly like this:

Typical engineering-driven company. Engineers are shown in green, managers in gray, executives in black, and the CEO always wears a crown (obviously). The water on the left and fire on the right represent the raw materials and end-customer pieces of product development. (This is all covered in the previous article. Which you probably didn’t read. Even after I waited for you. I’m starting to lose faith in this relationship.)

But there’s obviously more to a company than its amount of management overhead. While layer upon layer of management is necessary for keeping the engineers focused on product development, the long term success of the business itself is dependent upon other factors that provide their own additional levels of helpful bureaucracy.

First, it’s important to realize that with this many completely necessary levels of management, it can be difficult to ensure that product development happens in a predictable fashion. Instead, the product can ricochet around the organization like a steel ball in a pachinko machine.

Products should always have easy linear development flows, but may end up meandering through the halls of corporate bureaucracy instead, rebounding off of multiple “not my problem” mangers. A product could even spin out of control into the executive ranks where it may mistakenly end up in the inbox of the CEO, who obviously has more important things to worry about than the products that the company makes.

In the diagram above, we see the product bouncing out of the management structure to land on the CEO’s desk. This can have only bad repercussions, causing the CEO to retaliate, probably by firing whoever bounced it their way.

You don’t want to be the person who made the CEO deal with a problem.

Project Management

What’s needed here is some Project Managers, who are responsible for keeping projects on track. They handle everything from spreadsheet creation to spreadsheet updating to going over spreadsheets in meetings (which are scheduled on other spreadsheets). They ensure that milestones are communicated and that project schedules are added to spreadsheets. By sprinkling these people throughout the organization, a company ensures that product development and schedules become more predictable, or at least spreadsheetable.

Project managers are purple. This is a traditional color for this role, which comes from the color of their bloodshot eyes from staring too long at spreadsheets and project-milestone charts.

A high amount of project management helps guarantee that product development stays on track. But the more important issue, in the executive ranks, is how the executives can keep from getting fired. More project managers are hired to act as a buffer between management and the execs, ensuring that any pachinko activity will stay on the inside, allowing the executives and the CEO to continue working, unburdened with the responsibility and hassle of “product.”

Project managers can serve other functions in the organization, including acting as a buffer between executives and any real product development in the organization.

Rest Assured

Another element missing from the picture is Quality Assurance. This department tests the products that the company develops, to ensure that they are performing to specification. A common misconception is that the products are tested for readiness. Nothing could be further from the truth (except policy statements from politicians). Companies are only responsible for testing whether the products are done according to the original spec, not whether they are actually usable. Users hold the responsibility for this final phase of testing, which is often referred to as “user testing” or “buyer’s remorse.”

The addition of a testing group (shown by the single QA engineer depicted by the yellow circle to the right) ensures that products meet test criteria as they are delivered to the customer. Test criteria often includes such stringent requirements as “Were some tests run?” and “Was there a dashboard displaying the results of tests?” Note the small size of this group and the strategic placement of it right at the end of the development process — this typical approach to testing guarantees that testing results cannot disrupt a productive development pipeline, and that any unfortunate test failures will be surfaced too late to delay shipping the product to the customer, which is always the most important thing.

Product Management

Sometimes, products actually originate from clever ideas. For example, in our over-extended metaphor, the founding engineer had the idea of using the “water” to put out the “fire.” But it is usually not sufficient to trust the instincts of random engineers in developing and delivering great products. For this audacious task, companies needs people that have the word product in their job title — this is why they hire “product managers.”

Product Managers (usually abbreviated PM to cause confusion between the similarly-acronymed and ambiguously-overlapping roles of Product Marketing, Project Management, and Personnel Mangling) are responsible for determining features that products need to meet customer needs. They then create presentations and spreadsheets to justify these features and schedule meetings to align all of the relevant stakeholders (typically, and almost exclusively, other PMs).

In the case of our bucket brigade metaphor, a good product manager would find that the development production could benefit from lower latency by introducing more buckets. This enhancement would create a pipelined process delivering more product more quickly, ensuring more revenue and higher PM bonus.

Product managers (shown in blue, for the BMWs they drive to their meetings) investigate product development and user needs and request new features. Here, they introduce the product feature of “more buckets” to ensure higher product production products.

Account Management

An external vendor (shown here by the word “Vendor”) is typically surrounded by a large set of Account Managers (shown here in green, for the expenses they ring up at “meetings” and “restaurants”).

Of course, our fictional company doesn’t make buckets, so the new multi-bucket feature of the product requires working with an external supplier. This, then, requires a fleet of Account Managers, who are responsible for managing that vendor account. Account Management typically entails frequent meetings, lunches, golf games, and junkets to ensure that the buckets keep coming.

The End?

We now have a fairly complete picture of a successful and efficient product development company. There is a core set of products that are being developed and managed appropriately, a sufficient level of bureaucratic overhead that everyone can micro-manage everyone else, and a customer base that is paying a premium to keep this massive organization running smoothly.

Next time*, in the upcoming finale** of this multi-part*** series, we will see how this company evolves one final step to become a complete success story.

*Assuming I don’t write something else in the meantime.
**Assuming I actually write that final installment.
***Three (3)

Now that you’ve read this article, you might want to go back and read the previous one. Or move forward and read part 3: The Engineer’s Guide to Consultants.

p.s. Sometimes I write serious articles. Sometimes I don’t. In fact, usually I don’t. This article is clearly in the latter category. Don’t take this piece seriously. And definitely don’t think that anything I’ve said here has anything to do with any company that I happen to work for now, ever worked for previously, or will ever work for in the future. Because it doesn’t. It’s just comedy.