Noise On Software Engineering Seniority Discussions

Occasionally, I found myself reading a new discussion on software developer seniority on Twitter or LinkedIn. What technical questions should a senior developer be able to answer? How much autonomy should a mid-level engineer be able to handle? How many developers a technical leader should manage?

Companies try to answer these questions by creating well-defined job descriptions. They do their best to establish a career ladder where the employees can play in a set of rules that could give them predictability and a sense of fairness over their growth in the company — they know what to do to jump to the next level by reading this manual. It pushes people to develop themselves in a way that increases their “impact” on the business. The bigger their influence, the higher their level.

However, is it possible to achieve this level of certainty in a software company? Is it possible to determine the actions that will produce the exact results that will allow everyone to grow?

Of course not, and by implementing the perfect compensation system upfront to optimize performance, we produce noise for people, distracting them from what really matters: effectiveness in solving problems. People will see themselves in situations where on the one hand, they have the path that they really think is the way for a certain business objective and, on the other, a conservative alternative that will guarantee a more beautiful end-year personal report in the gaze of others — guess what people will pick. In the end, it is perfectly possible to have a company full of excellent performers that will be laid off in the next crisis.

I’m certainly not proposing to abandon all role descriptions. They’re fundamental to achieving a minimum level of conformity over what is expected from a person in a specific role in a big company. However, the obsession with objectively evaluating the cause-effect of every single action may produce a culture averse to risk-taking rather than effectiveness oriented.

Software developers should be more interested in how their products interact with the real world — their users and the problem it is supposed to address for them — instead of worrying about a checklist that brings a false sense of certainty to their careers.