Your Seniority Level is Determined by the Amount of Uncertainty you can Handle

Ambiguity is intimidating. Taking the responsibility on the path to take, on mapping the risks correctly, on building the execution plan. In my day to day, dealing with complex and uncertain projects can lead to mental difficulties. Dealing with them successfully, though, is a real growth experience.

In some sense, in my personal point of view, being able to deal with ambiguity of different levels is a true sign for seniority. In fact, I would like to argue that the only metric that successfully defines seniority is the amount of uncertainty one can handle.

The Scale of Uncertainty

This is one side of the scale. The amount of thinking in this task is limited to how you define a color, and how a blue color is defined in CSS.

Now consider this:

“We see a gradual decrease in visitation on our website over the past year. What do you think?”.

This is the other side of the certainty scale. Asking the right questions, building the right frameworks, having the mental strength to keep track and context of everything, making the right decisions along the way, building consensus, arranging the execution force.. All these are required to handle such a task.

The scale is everything in between.

There are several factors that affect the level of certainty, which can be globally defined:

  • Definition of the task — Vague tasks are not vague because your manager wants to make your life hard. Those are vague because your manager doesn’t know the answer. The less clear the task — the further it is in the scale.
    Senior engineers use their knowledge and experience to pave the way forward for a solution for everyone else.
  • Amount of different possible paths — In the above example, visitation decrease can happen for tons of reasons. Taking ownership on the task means to take the right decisions along the way out of all the different possible paths. Mapping the possible paths is usually even more important and harder than making the right choice.
  • Amount of people needed — Changes can be too big for one engineer to handle, and a task force would be required. Leading a group of engineers is always harder than leading yourself. The bigger the group, it’s harder to handle.
  • Amount of risks — also here, mapping is harder than mitigating. Understanding the risks your project involves will be way harder in more complex projects.

And above all those — The mental strength needed in order to accomplish the task successfully. Things will change along the way, mistakes will happen, this is a fact in complex projects. The mental strength needed in order to overcome these and continue without hesitations is just enormous.

The Seniority Level Framework

All projects in our industry can be put on the scale. Doesn’t matter the company you’re at or the place in the tech stack you’re positioned in. This scale can be normalized to all.

I like it for the simplicity of it. I like it because it creates a tool that enables us to compare between any two random engineers.
I find it helpful from a growth perspective. I Always look for the most uncertain tasks around. It is intimidating since the mental effort it requires is sometimes pushing the limits, but taking myself in this direction helps me to understand how far I can go. Not always I succeed obviously.
At the end — that’s what growth is all about, no?

Writing on Software Engineering & Leadership. Enjoying writing code, reading and cycling.