Monthly archives for October, 2015

I was recently introduced to the term “promotion to incompetence” by my good friend Julio. I was fascinated by the term and wanted to explore it more. So I started evaluating my work environment in addition to other roles around me.

Promotion to incompetence, or the Peter Principle (after Laurence J. Peter), is a concept in management theory in which the selection of a candidate for a position is based on the candidate’s performance in their current role, rather than on abilities relevant to the intended role.

For instance, if you’re a strong software engineer, you get promoted to become a tech lead, then perhaps, a manager. However, being a contributor is different from being a leader, which in turn, is different from being a manager. Each role requires different skill sets. In other words, just because you’re a strong software engineer does not mean you will be an effective tech lead or manager.

Promotion to incompetence tackles the classic case of promotion; moving up. Simply, moving a candidate up the hierarchies until they’re no longer effective at their job. However, there is a different take on promotions that may be hard to recognize. It is fair to assume that added (similar) roles and responsibilities may also be considered as a promotion. However, this kind of promotion is more of a lateral expansion than a vertical move. This, too, could lead to incompetence. Julio calls this scenario Empowerment to Incompetence, as opposed to a promotion.

For example, in most software organizations, tech leads are also contributors (that’s two roles). In an empowerment to incompetence scenario, a tech lead is asked to lead more than one team (3 roles), and perhaps join other teams as a contributor (that’s 4 to more roles). At some point, with added workload and responsibilities, the tech lead is unable to gain traction on any single project/team.

The empowerment to incompetence problem can appear to stem from one area; resourcing or lack thereof. However, when examined carefully, it can (almost) always be mapped to a lack of prioritization of the workload.

An attempt to fix the problem could involve time management techniques. For instance, employees may be allocated 20% to Project A, 30% to Team B, 10% to Project C and 40% to Team D. While different people have different multitasking capabilities, humans are not good at multitasking in general.

Though the percentages listed above beg the question; if an organization is willing to spend as little as 10% or 20% of an individual’s time on a project/team, is the project worth taking on at the moment? The answer may very well be yes, for valid reasons. However, the question needs to be asked and the priorities need to be examined.

Resourcing is a hard problem that successful businesses face on a daily basis. However, it will always remain a problem. It only surfaces aggressively and becomes a symptom of a much more deeply rooted problem; poor priority calls, or in the worst case, having competing number one priorities.

Major thanks to my friend Julio Mateo for the inspiration behind this article in addition to proofreading it.