Looking at The Peter Principle, Dilbert Principle, and Parkinson's Law

by Tom Johnson on Feb 15, 2012
categories: technical-writing

After my last post about being an individual contributor, a reader asked if I had heard of the Peter Principle or Parkinson's Laws. I hadn't, so I read about them on Wikipedia, as well as a related principle, the Dilbert Principle.

The Peter Principle

The Peter Principle states that "in a hierarchy every employee tends to rise to his level of incompetence." In other words, employees who perform their roles with competence are promoted into successively higher levels until they reach a level at which they are no longer competent. There they remain.

For example, let's say you are a brilliant programmer. You spend your days coding with amazing efficiency and prowess. After a couple of years, you're promoted to lead programmer, and then promoted to team manager. You may have no interest in managing other programmers, but it's the reward for your competence. There you sit -- you have risen to a level of incompetence. Your technical skills lie dormant while you fill your day with one-on-one meetings, department strategy meetings, planning meetings, budgets, and reports.

The Dilbert Principle

The Dilbert Principle is related to the Peter Principle, but the Dilbert Principle states that

"companies tend to systematically promote their least-competent employees to management (generally middle management), in order to limit the amount of damage they are capable of doing."

In contrast to the Peter Principle, which seems to promote competent employees out of good faith (though it works toward the employees' detriment), Dilbert sees management as a place to stuff the incompetent so they are no longer blocking the productive workflow of the company.

The Dilbert Principle assumes that " the majority of real, productive work in a company is done by people lower in the power ladder." Those in management don't actually do anything to move forward the work.

You can see the Dilbert principle play out in The Office, Office Space, and other parodies of corporate culture. (See The Dilbert Principle.)

Parkinson's Law

Parkinson's Law states that "work expands so as to fill the time available for its completion." Although this law has application with procrastination, storage capacity, and resource usage, Parkinson focuses his law on swelling bureaucracies. Parkinson says that bureacracies swell for two reasons:

(1) "An official wants to multiply subordinates, not rivals" and (2) "Officials make work for each other." [Parkinson] notes in particular that the total of those employed inside a bureaucracy rose by 5-7% per year "irrespective of any variation in the amount of work (if any) to be done". (See Parkinson's Law.)

In other words, a bureaucracy may swell not because the workload increases, but because they have the capacity and resources that allow for an increased workload even if the workload does not in fact increase. People without any work find ways to increase the amount of "work" and therefore add to the size of their bureaucracy.

My Analysis

None of these principles or laws gives much credit to management. Either the wrong person fills the wrong role, the role exists only to minimize damage control, or the role swells unnecessarily simply because it can.

I find the whole topic of management somewhat fascinating, not because I think these theories apply to my own manager. In fact, my manager has a consulting background. He negotiates projects and budget, and interacts with other product owners throughout the organization to solicit more work for our group. He's not a former technical writer, but rather a former developer.

These management theories are more relevant with our community volunteer efforts. Lead engineers looking to leverage community IT talent for their projects often find themselves in management roles, without a strong understanding of how to manage a large group of people. Most of the time, these engineer project leaders (I include myself here too, by the way) fail to engage the community. Most volunteers remain "observers," which means they remain waiting for assignments -- indefinitely. The project leaders are usually brilliant at their technical job but don't excel at management.

One project manager, however, seemed to find a way around this predicament. The project manager was a lead engineer, a sharp developer who could code an iPhone application all by himself in a matter of weeks. Yet, he suddenly found himself leading a project that involved more than 100 volunteers. Because he was shy, and not inclined to interact with volunteers in an outspoken, engaging way, he found an outspoken community volunteer and designated him as the community manager instead.

The project manager interacted mostly with the community manager, giving instruction, assignments, and other critical information to him alone. The community manager in turn interacted with the scores of volunteers, doing all the interacting and assigning and following up that management involves. Apparently this system worked out quite well, and it's a model we're trying to implement on other projects. The trick is to find an outspoken community manager who can fill this role.

However you do it, the key principle to follow should be this: put individuals to work in their core competencies. It makes little sense to take your most brilliant engineer and have him or her manage people and budgets. Likewise, it makes no sense to take a shrewd consultant, one who can negotiate projects and requirements down to the most minute detail, and put that individual into a role involving creative design and content generation. However, to implement this model, you have to allow for reward without a dramatic change in job responsibilities or skills.

Last week I was talking with a social media maven in the breakroom. I mentioned how I wished he could take over the Twitter, Facebook, and other social media aspects surrounding the technology blog in our organization. I'd rather just focus on creating content for the blog, I said. He was clearly intrigued, and if the world were a simple checkerboard that allowed us to move pieces here and there at will, I would already have made the switch. But of course he's in another group, with other responsibilities, and different billing codes and reporting structures. It reinforces how complicated movement can be in large organizations.

I realize that these laws and principles -- the Peter Principle, the Dilbert Principle, and Parkinson's Law (as well as Putt's Law, which I didn't mention) -- aren't necessarily founded in reality. It's easy to look at a manager's closed doors and wonder he or she does all day, if anything. But having had a taste of management with my volunteer project, I've come to realize the difficulty and scope of what management entails. It's hard work and requires a certain skillset that I'm only beginning to develop. One should therefore look at these principles and laws with an acknowledgment that they most likely developed from the employee's perspective, not the manager's.

Photo from Flickr