Limit Reporting Hierarchy

A reporting hierarchy is the most common characteristic of a formal, hierarchical, organization. Cleararchy takes the stance that reporting hierarchies are not bad per se. Some hierarchy is essential for effective organization and for reasonably speedy decision making. However, traditional configurations of reporting hierarchies lead to two common dysfunctions.

Dysfunction #1

The first dysfunction is that of too many reporting levels. The greater the length of the reporting chain from the coalface to the CEO, the greater the reliance of its senior management on second-hand and inevitably inaccurate reports of ground reality—reality of customer experience and employee experience, reality of safety conditions, reality of regulatory compliance, etc. This is so because, in a hierarchy, only some reports are based on raw data, the rest are based on lower level reports. At each stage on the way to the top, some information is typically lost or distorted in translation, aggregation, or simplification. Cleararchy aims to reduce this effect by limiting the length of the reporting chain.

Reduce number of reporting levels

The bare minimum length is what is mathematically necessary. Assuming a span of control (maximum number of direct reports per person) of six, we can have an organization of max 1296 (64) people with four levels of reporting. In order to avoid increasing the number of reporting levels, we may have to increase the i.e. span of control. For example, a span of control of ten allows us to run an organization of ten thousand (104) people with just four levels of reporting. It may not be possible to closely track the work of ten direct reports but that may not necessarily be a bad thing. Fewer levels of reporting hierarchy ought to go hand-in-hand with greater levels of empowerment (and accountability) in the lower rungs of the organization.

These considerations also apply to matrixed organizations. For instance, let’s look at a common matrix configuration in tech organizations. The two dimensions of the matrix here are projects (with dotted line reporting) and competencies/functions (with solid line reporting to function leads). Day-to-day reporting takes place along the projects dimension while the competencies arm could do with reporting at longer intervals. This allows us to get away with greater spans of control (and therefore, fewer levels of hierarchy) along the competency dimension. There’s an opportunity here that tech organizations could exploit if they can be less wedded to older ways of organizing.

Dysfunction #2

The second dysfunction of reporting hierarchies has got to do with silo formation. Silos are teams (organizational units) that tend to prioritize their own interests sometimes to the detriment of other teams. They form along reporting boundaries because reporting boundaries are the seams of organization. Any two silos will invariably correspond to two different reporting chains. For example, we commonly encounter siloed behavior between functions such as marketing, sales, operations, product, engineering, and support. Within each function, further silos may arise along internal reporting boundaries (e.g. different product lines, different sales regions, different specializations within engineering). What can we do about this? To the extent that silos arise along reporting boundaries, they can’t be eliminated without eliminating reporting boundaries—an unrealistic prospect in any sizeable organization.

Reconfigure reporting boundaries

Cleararchy deals with this issue by aligning reporting boundaries with business outcomes as much as possible. If the realization of a business outcome is a cross-functional effort, then we set up cross-functional organizational units (teams) with a unified reporting hierarchy within IT/Digital. We avoid those matrix configurations where line reporting goes one way (typically to function leads) and value stream or project reporting goes the other way (to project/program/product managers). This represents a big change from the way agile cross-functional teams are being set up without any change to reporting lines in most transformation programs. Nevertheless, a unified reporting hierarchy is required to achieve greater alignment of tech with business.

Challenges

Every solution throws up new challenges. Attempts to reduce the number of reporting levels will lead to concerns about fewer opportunities for career progression via promotion. Change management will need to factor this in. One option is to ensure that rationalization of levels only results in upward transition from eliminated levels. That does not necessarily have to result in extra cost on account of pay increases—HR could be persuaded to widen salary bands to accommodate new entrants to post-rationalization levels (bands).

Attempts to move from function/competency based reporting to unified, business aligned reporting will lead to concerns among function/competency leads. Some of them may have the skills to take on business-aligned lead roles (e.g. director of product for a given line of products). Some others may be able to take on the role of leading smaller expert teams (e.g. enterprise architecture) with significant influence across the organization. The rest (e.g. engineering managers and other delivery managers) will be needed to perform the same job but report to people who are business-aligned (e.g. senior product owners) rather than function/competency aligned (e.g. director of QA).

Post Publication Note: Forrester analyst's reaction on LinkedIn