Daniel Leeder

We have a problem with title inflation in the technology industry.

We frequently see "Senior Engineers" with two years of experience who are excellent at writing code but struggle to engineer a system. Conversely, we see engineers with ten years of tenure who still require detailed instructions to be productive.

This confusion stems from a fundamental misunderstanding of what "Seniority" actually means. While there are certainly other pillars to leadership, such as mentoring and communication, when it comes to the work itself, seniority is not about Tenure (how many years you have sat in a chair). It is about Ambiguity (how much uncertainty you can handle).

The Ambiguity Ladder

Career growth is not a linear accumulation of skills; it is a step-function increase in the scope of ambiguity you are expected to resolve.

1. The Junior Engineer: Zero Ambiguity

• The Input: A specific task with a defined solution (e.g., "Add a 'Cancel' button to this modal using the ButtonSecondary component").

• The Role: Execution.

• The Ambiguity: None. They are learning how to code, not what to build.

2. The Mid-Level Engineer: Solution Ambiguity

• The Input: A defined problem (e.g., "Users can't cancel their subscriptions").

• The Role: Solution Finding.

• The Ambiguity: They know what the problem is, but they must figure out how to solve it. They design the flow, the database schema, and the API.

3. The Senior Engineer: Problem Ambiguity

• The Input: A vague symptom or a high-level goal (e.g., "The application feels slow on Tuesdays," or "We need to improve retention").

• The Role: Diagnosis and Strategy.

• The Ambiguity: They must first identify the root cause (Is it the database? The network? The frontend?) and then define the solution. They turn the vague problem into concrete tasks for others.

4. The Staff/Principal Engineer: Strategic Ambiguity

• The Input: The business goals.

• The Role: Anticipation.

• The Ambiguity: They look at the horizon and find the problems no one else sees yet. "If we keep growing at this rate, our current architecture will fail in six months. We need to start 'The Project That Never Starts' today."

Stop Chasing Years

If you are an engineer looking to grow, stop worrying about "putting in your time." Start seeking out vaguer problems. If you usually pick up tickets that are fully specced out, ask your manager for a problem that is poorly defined.

If you are a manager, stop promoting based on tenure. Promote based on the ability to turn chaos into order.

The value you bring to an organization is directly proportional to the amount of uncertainty you can ingest and turn into clarity for the team.