knowledging

“Career Ladder is an Inverted Triangle” Bias

Summary

• There is a deeply ingrained bias as follows:
  • The higher you climb the career ladder, the more you can do. You solve undefined problems.
  • The lower you go on the career ladder, the less you can do. You solve specific, instructed problems.
  • In other words, there is a bias that the height of the ladder corresponds to the level of abstraction.
• Let’s discard this bias:
  • Even among those who aren’t in high positions, there are people capable of solving abstract problems.
  • Conversely, just because someone is in a high position doesn’t mean they can solve these problems.
• However, to exert influence, a higher position is necessary.
  • Related article: Influence sucks - DEV Community

Background

Career Ladder and Abstraction Are Proportionate

As you ascend the ladder, meaning your position rises, you begin to handle more abstract problems. You also deal with ambiguous issues like people and organizations, making soft skills more crucial. Conversely, when you’re lower on the ladder, you consistently tackle specific, instructed problems. You only need to address technical and “hard” problems, making soft skills unnecessary or even unwelcome.

I call this bias the Inverted Triangle Career Ladder. The higher you go on the ladder, the broader it becomes, while it is very narrow at the lower levels.

Career Ladder and the Ability to Handle Abstraction Are Unrelated

However, being higher on the ladder does not necessarily mean you have a high ability to handle abstraction. Conversely, engineers who haven’t been promoted or have only been promoted once may have the capability to address abstract problems.

So, let go of this bias and enhance the agility and flexibility of your organization!

Successful Operation Without the Bias

If we were to discard the Inverted Triangle Career Ladder bias, how would it change the roles in our organizations and projects? More specifically, what operations would be successful?

1: Distinguish Exploration, Performance, and Influence

First, distinguish the following three points:

• Exploration
• Performance
• Influence

Exploration refers to solving abstract problems (through examination). It’s not as visible as project work, and new approaches are required. I call this Transject. As a method, I’ve previously explained Creative Thinking.

Performance refers to abilities and deliverables. For instance, there’s an engineer who can compare the usage methods and properties of the OpenAI API, summarize them in a document, actually try them in compliance with the company’s governance, and share the results of the examination and testing as knowledge. This person clearly possesses investigation, prototyping, documentation, and sharing skills. There are deliverables, too, indicating performance.

Finally, Influence refers to improving metrics directly. Note the difference from performance. Exerting influence requires considerable authority, which is the responsibility of those in managerial positions or higher. Therefore, it’s practically a dereliction of duty to assign influence responsibilities to engineers without the authority (the only exception is delegating tasks whose outcomes are certain to produce influence). I’ve also emphasized this point in Influence sucks.

2: Permit Exploration

Once you can distinguish the three elements above, the next step is to allow exploration work to be conducted by anyone at any level, including the front lines.

This might be confusing, so let me explain with a Before/After scenario. Let’s simplify the career ladder to lv1 Field, lv2 Manager or Individual Contributor, lv3 Senior Engineer, and lv4 Executive Level.

Here’s an overview of which levels handle each element. Before represents conventional bias, and After is our proposed approach.

	Before	After
Exploration	Lv3~	Lv1~
Performance	Lv1, Lv2	Lv1, Lv2, Lv3
Influence	Lv1~	Lv2~

The specific changes are as follows:

• First, ensure Lv1 doesn’t have influence responsibilities.
• Next, make exploration possible from Lv1.
• Consequently, some Lv3 responsibilities will become available, potentially allowing for performance duties.

Previously, exploration was only conducted by Lv3 or higher, but now it can be done starting at Lv1. However, as stated earlier, Lv1 doesn’t have the authority to produce direct influence, so Lv2 or higher should handle that responsibility.

3: Connect Exploration and Influence

Even if you’ve enabled Lv1 to engage in exploration, it holds no meaning unless the results translate into business impact. This part, of course, falls under influence responsibilities and must be taken up by Lv2 or higher, who have the authority to exert influence.

This means that Lv2 or higher must receive the results of Lv1’s exploration to exert influence.

When proposing such a concept, you may receive opinions accusing it of irresponsibility, but that’s precisely the bias. It’s impossible for Lv1 to exert influence. Nevertheless, Lv1 can explore and think of ways to capitalize on its results. It’s a matter of role division.

Conclusion

The height of a career ladder does not correlate with the ability to handle abstract problems. However, applying the results of exploring abstract problems requires influence, and influence necessitates height.

Therefore, it’s actually possible to collaborate as follows:

• Exploration of abstract problems can be entrusted to field-level engineers who excel at it.
• Because influence using the results cannot be exerted at the field level, it must be passed on to someone with authority to execute.

If you’re relatively high on the ladder yet struggling with abstract problems, try discarding this bias. There might be a team member capable of dealing with abstract issues. Collaborate effectively.