Seniority Is About Ambiguity and Decomposition
When a company says it needs a senior engineer, what is it actually asking for? Usually, the description starts with years of experience, number of languages and frameworks, and some version of “can work independently.” Those things tell us something, but they leave the important question unresolved: how much of the problem does this person need someone else to figure out before they can do useful work?
Consider the difference between “implement this endpoint” and “figure out why customers keep getting inconsistent information.” In the first case, someone has probably already decided what the system should do, where the change belongs, and how it should interact with everything around it. In the second, the engineer has to establish what is happening, determine what kind of problem it is, and decide how to address it. Both involve technical work, but the second contains substantially more responsibility for defining the work itself.
That is where seniority becomes meaningful. An engineer should be able to take a certain amount of ambiguity and turn it into a sound plan. The more responsibility they can reliably own for understanding and decomposing the problem, the more “senior” the contribution. Technical depth matters because the plan has to survive contact with the real world. Someone eventually has to implement it, operate it, and deal with the consequences.
Before decomposition, though, there is categorization. You have to understand what kind of problem you are looking at. Suppose an application is slow. That description gives you a symptom, but it does not tell you whether you have a database problem, a network problem, a resource problem, or a workflow that forces the user through too many sequential steps. Each category points to different evidence and interventions. If you choose the category badly, you can do excellent implementation work and still accomplish very little.
Engineers build a taxonomy of these problems through experience. They encounter situations, absorb models for understanding them, and learn what happens when those models are applied. Over time, they develop a larger repertoire: this resembles a consistency problem; that looks like contention; this complexity might be coming from the way responsibilities have been divided. Recognition gives them a useful starting point, and experience helps them determine whether the resemblance holds up.
This is what makes experience valuable. A senior developer has seen decisions play out beyond the moment when the code worked. They have watched an apparently convenient abstraction become difficult to maintain, or discovered that an approach borrowed from one environment depends on conditions that do not exist in another. They start to understand which details are decisive. The next time they encounter something similar, they have more than a technique available; they have some understanding of its consequences.
But people accumulate that understanding at different rates. Someone can spend years doing variations of the same well-defined work without developing much responsibility for choosing the model or framing the problem. Someone else can progress quickly because they reason well, make connections, and learn deeply from each new situation. Counting years gives us a rough indication of the volume of exposure. It does not, itself, tell us the variety of situations they have encountered or what the person has done with that exposure.
This is also why a junior engineer with high potential can be so interesting. They may not have encountered the particular problem before, but they can reason their way toward a useful model. They can work from first principles, recognize a structure they learned somewhere else, and make a lateral connection. They can arrive at an approach a priori that another person had to acquire through direct experience. That ability is part of what allows them to become more capable quickly.
But reasoning still needs development. Reasoning toward a model does not automatically give you knowledge of every exception, operational constraint, or failure mode. Experience puts pressure on the reasoning. A senior developer can discover where the analogy breaks, which assumptions were too convenient, and what you failed to consider. Strong potential and accumulated experience can reinforce each other, but they are different things. A person can have considerable experience without much depth, and considerable potential before they have had the opportunity to acquire it.
Once you have an appropriate way of understanding the problem, you can decompose it. What needs investigation? What can be decided now? Which decisions depend on information you do not yet have? What can be implemented independently, and what needs to wait? A good decomposition makes these relationships visible and puts the work in an order that allows you to learn before making expensive commitments.
Simply breaking something into tickets does not establish that it has been done well. It is possible to produce a beautifully organized plan around a mistaken assumption. Everyone knows what to do, the work moves quickly, and the team gets further into the wrong approach. The quality of decomposition depends on the quality of the understanding behind it. The plan should make it easier to test that understanding, rather than bury it beneath implementation detail.
The cost of getting this wrong extends well beyond the original engineer’s time. Other people may have to reconstruct the reasoning, correct the approach, and unwind dependencies created along the way. More output can mean more work for everyone else. Conversely, someone who understands the problem properly may eliminate a proposed component or discover that a much smaller change is sufficient. Their contribution is partly the effort the organization no longer has to spend.
For that reason, seniority has to be considered in relation to the assignment. An engineer may have excellent judgment in one class of systems and need substantial context in another. A strong executor inside an established architecture may have less experience deciding what architecture an undefined product needs. You have to know where the ambiguity sits and who is expected to resolve it.
When we ask for senior capability, we are buying some amount of that responsibility. We expect the person to recognize the problem, select or derive an appropriate model, and organize work that advances the objective. Years of experience help explain how they might have acquired that ability. The ability itself is what we need.
