I have been in the software business for 2 decades. I have worked with a lot of programmers from different countries in various business sectors from telecom and insurance to online banking and health care.
20 years ago when I was a beginner, the words “expert” and “senior” or “leader” meant more or less the same thing to me. As I grew into my career and worked with people with different skills, I came to assign a specific meaning with each of those terms that describes different dimensions of people’s skills.
Junior, Senior, Expert
There are many ways to set those titles. One that I particularly find interesting is about their problem solving skills:
The best way I have come up with to define these titles is by looking at the challenges they face.
Instead of focusing on the requirements for a role, we can get a better definition by looking at the challenges of each level.
A junior’s main challenge is to learn the technology. You’re new to the company, and they use Node, React, Python… you have to learn their tech stack as the first step to becommimg productive. This doesn’t necessarily have to take that long. If you have previous experience with something similar or computers in general you learn faster. You may also have to unlearn some things in order to fully absorb the new things.
A senior’s main challenge is to learn the domain. You know .NET and you’re hired at a company which writes .NET code. You can read their code but you have no idea about the problem it solves. Your challenge is to learn the domain knowledge to understand the context of the code and why it is structured in a certain way to solve a certain set of problems.
An expert’s main challenge is to help seniors and juniors engineer a solution that solves the domain specific problems. The experts unleash the true power of the team by spreading their knowledge in the domain and tech stack. They are the ones with a cohesive understanding of the business as a whole.
When someone just joins the team, they are by default at the junior level no matter how many years of experience they have. But if they know the tech stack, they can be considered senior.
It is important to note that these titles are not permanent. People are different: they learn different things at different speeds and each one has a unique knowledge.
An experienced developer may learn the technology in a couple of days and become senior. A quick test of seniority is to ask them about the things they don’t like about the tech stack. When someone knows a technology well, they have a good idea about the limitations and strengths of the tech.
Also, age has nothing to do with seniority. It is just a pun in job descriptions that excites the older juniors.
When someone is head hunted from a rival company, there’s a good chance that they already know the domain, therefore they can be considered an expert.
The border between seniors and experts is not that obvious. Experts can fluently use the technical jargon of the domain, but what separates them from the seniors is their holistic understanding of how software is used to solve the business problems.
When you ask a general question from an expert you usually don’t get a simple “yes”/“no” answer but rather a “yes and no” or “it depends”. That is because the experts can see the problems in depth with cons and pros and the inevitable trade-offs. They usually need more info to distill the simple questions to more specific ones for the problem in hand and then give a “yes”/“no”.
The leader’s main challenge is to make sure everyone is moving in the right direction across the team:
- The experts share their domain and technical knowledge with the seniors and juniors
- The seniors learn the domain knowledge and share their technical knowledge with the juniors
- The juniors stay curious and motivated to learn more
The reality is more complex than that, but for the sake of this brief article it suffices to say that the leader sets the tempo of the team, and the best leaders lead from behind as a Professor of Business Administration at Harvard Business School puts it:
Leaders can encourage breakthrough ideas not by cultivating followers who can execute but building communities that can innovate. — Linda A. Hill
Most job ads call for an experienced candidate. Unfortunately this blocks most juniors in a catch 22:
But hiring an experienced developer is not always the formula for success. You want to ensure that the team has a good mix of different levels. Having juniors in the team makes the seniors and experts explain concepts and become even better at their job.
Those who know, do. Those who understand, teach. — Aristotle
You should be careful when hiring experienced people (senior & expert level according to our definition) as they tend to be more opinionated about how things should be done. Depending on the team demography, they may end up unbalancing the team and killing other people’s motivation.
You may want to leave a bit of gap between what the job requirements ask for and a person’s skills. This gap keeps them coming to work because it gives them a sense of growth and progress. Otherwise they may actually get bored and leave sooner than you would like.
You don’t hire for skills, you hire for attitude. You can always teach skills — Simon Sinek
Sometimes the word “professional” is confused with “senior”, “expert”, “experienced” or “lead”. As opposed to a hobbyist, a professional is someone who does an activity for money.
Someone cooking a meal at home for the family is not a professional chef. Someone cooking at a restaurant is.
When we talk about a “professional”, we often mean someone who:
- is service minded and does their best to offer a good service in exchange for money.
- leaves their personal life out of the work and strives for the best possible service (although it varies between work cultures and generations).
- creates the trust that is necessary to acquire and retain customers.
A “junior” can expose professional behavior while someone at the “lead” position may demonstrate behaviors that are not professional.
Specialist vs. Generalist
The specialist has a deep knowledge about a particular tech stack or domain but doesn’t necessarily understand the big picture.
For example a generalist UX engineer, may have a wide range of skills but not necessarily as deep as a specialist front-end developer:
Trivia: If you squeeze your eyes you can see the T-shape of the skill diagram.
On the other hand, a specialist front-end developer may have very deep knowledge of implementing a website but not necessarily other relevant disciplines:
And lately he went on to humbly articulate things he doesn’t know:
This is a good example that in order to be a good problem solver you don’t have to know everything. Focusing on the problem in hand is the key.
So there you have it: an explanation of Junior, Senior, Expert, Lead, Professional, Specialist and Generalist titles in the software business.