Engineer titles roughly represent how much experience an engineer has and also their responsibility and role in the team. Here are some commonly seen engineer titles:
- Software Engineer
- Senior Software Engineer
- Staff Software Engineer
- Principle Software Engineer
I had an opportunity to work in a few different environments that handle engineer titles very differently. Today, I would share some of those experiences as well as some thoughts around this.
Working In a Small Team
In my early career, I worked at a small startup with less than 10 engineers. We all know each other very well. It is clear to us what the strength and expertise of each individual are. When problems arise, we naturally know who to reach out to get help.
The entire engineering team can be fit in the same meeting room. At lunch, we all go grab food together around one o’clock. We use a slack channel #lunchatone to coordinate lunchtime. We sit around a big picnic table, have lunch, and chat.
We know the company’s goal and mission very well and believe in them. There is hardly any misunderstanding in communications.
In such a small working environment, it simply wouldn’t make sense to distinguish engineer titles.
From No Titles to With Titles
When the company grows, we naturally start thinking about titles and team structures.
There are often multiple projects going on at the same time. And it becomes harder and harder to keep track of what each individual is working on. In engineer all-hands meetings, it becomes harder and harder to get everyone’s attention. For example, there may be a heated discussion about mobile MVVM architecture between a few engineers who work heavily on mobile; those who work deep in the backend systems, will simply zone out and work on their stuff on their laptops.
We hire a few executives from some successful startups and big techs. And we start to copy what other companies are doing. The team is being split based on multiple dimensions.
It is being split based on business units: a team focusing on revenue, a team focusing on growth, a team for each product we sell, etc. It is also being split based on technical domains: iOS team, Android team, backend team, data team. Lastly, each engineer will also have a title that reflects their level: junior, senior, principal, etc.
A Software Engineer now becomes Senior Android Software Engineer on the Revenue team, for example.
Splitting based on business unit or the technical domain is easy. But splitting based on level is tricky. How do we know who should be granted which title? How do we know how many levels should we create? And how do we define the boundaries of responsibilities and expectations for each level?
The Transition Can Be Turmoil
Eventually, with a big re-org is done, everyone is landed on a new title, reflecting their domain and level. Each level also comes with a page-long description of the responsibilities and expectations.
The journey transition is painful and bumpy. It becomes one of the most disruptive and unstable periods of time that I can remember. Before then, the turnover rate at the company was essentially 0. Some people have to move because of family, but they stick with the company working remotely. But since the re-org, people started leaving.
Some of them felt that they are treated unfairly. If you think you are a bigger contributor but are given a lower title than your peer, then your esteem would inevitably get hurt. Regardless of how much you love the product, the work, or the team, it would be hard to stay if you don’t think you are getting the recognition that you deserved.
Some of them no longer believe in the leadership or the vision of the company. A great engineer, also a good friend, once said, “Leaders are not given, but come naturally. For those who are capable and familiar with the system, others would naturally turn to them for help.” He left not long after.
After all the dust settled down. Those who left are missed. And those who stayed carried on the journey. With the new team structure and engineering hierarchy, scaling the workforce becomes a lot easier. As we continue to grow, we just need to hire proportionally engineers at different levels and create more teams.
Some Problems With Titles
One of the biggest drawbacks is that it pigeonholes us into a certain stereotype with predefined responsibilities and expectations.
In meetings, those at a higher level inevitably give more weight to their ideas and opinions. At the same time, those with lower levels are sometimes ignored. To a certain extent, it also hurts creativity, as more courage is now required to express and oppose the ideas of superiors.
Engineer titles nourish top-down engineering culture. Senior engineers focus more on defining the scope and direction of a project and can sometimes dictate implementation. On the other hand, junior engineers focus more on the execution of the predefined tasks.
Recruiting become more complicated too. Previously, the question that we need to answer are: 1) is this person smart; 2) can I work with this person. Now, some questions that we commonly get asked during interview debrief are: 1) if this candidate doesn’t meet the bar for senior software engineer, can we bring them in as junior? 2) which team should this engineer be onboard into? 3) do we engineer in that team with a more senior title who can onboard this candidate?
Before having engineering titles, we focus more on the overall vision of the company. There is a strong sense of ownership and a shared goal. With engineer levels in place, people are still motivated, but with a different reason. Everyone works hard to get to the next level, which implies more money, more recognition, and more power. This mindset change doesn’t happen overnight. But it is inevitable.
Sometimes, it creates unnecessary tension and competition among colleagues. If there are multiple engineers of the same level doing a similarly good job, they cannot be promoted all at the same time, right? We still want to maintain a meaningful distribution of engineers at different levels for a team to operate smoothly.
Previously, the sole purpose of work is delivering a great project. Now it is more important now to make sure others know you delivered the project successfully. That’s how and when politics start to creep in. Those who know how to show off their work, get promoted faster.
How About Engineer Titles Based on Job Functionality?
I was once hired as a full-stack engineer. I love the fact that I can dance between the front end and back end. There is always plenty to learn and there are always new challenges day in day out. With the re-org, we have to choose a technology stack to focus on.
The benefits are clear, since each individual is now focusing on a smaller tech stack, we can gain more expertise in certain areas. Front-end engineers will only have to deal with UIs; backend engineers only have to work on distributed systems; data engineers only need to think about data pipeline…
But the drawback is that we now create some artificial boundaries.
It creates more dependencies that require more coordination and communication. This complicates project planning. If one of the two backend engineer are on vacation, then it can severely impact the progress of the project.
It also makes it harder for engineers to explore other domains. An engineer may not spend time fixing a problem that he identified, but instead, create tasks for other engineers who own that domain. It also discourages horizontal learning and growth. It is fine for those who want to become experts in one domain. But for those who are keen to become a system generalist or full-stack engineer, now the door is closed.
A Workplace Where Engineer Titles Are Hidden
In a recent year or so, I joined another company where engineer titles are hidden. The title is considered as privacy just as compensation. The rule of thumb is that if one is willing to share their level, that’s fine; if not, we are not supposed to ask.
An environment like this is interesting to work in. Every engineer is empowered. The culture is more bottom-up. You, as an engineer, are supposed to come up with your own project ideas, identity partners to collaborate with, and drive them forward.
Of cause, every coin has two sides.
To a new member who join a team, it can be very confusing. Without asking around, you don’t know who is the team lead. Similarly, if you need help from another team, it is also hard to know who has the most context.
Since project ideas are bottom-up driven, there sometimes can be duplicated initiatives. Imagine two teams are working on two similar projects, if they don’t have overlaps, these two projects can go on for a while before noticing.
Some high-level ICs do not have the recognition that they want. They might change their title to something fancier, either internally or externally. After all, having a Senior Software Engineer, Staff Software Engineer or Principle Software Engineer on your resume just looks so much better than a plain Software Engineer.
Conclusion
A vast majority of the companies on the planet have a tree-like org-chart or some variations of it. I felt lucky that I had the opportunity to work in a small team where titles are not as important; also a bigger company that tries its best to promote individual creativity by purposely hiding engineering titles.
Are you in the junction where you are trying to decide whether you should introduce titles among engineers? There are plenty of pros and cons to consider. Hopefully, the above can serve as some food of thought.
What do you think about engineer levels and titles? As always, I would love to hear from you too.
This article is also available at https://betterprogramming.pub/f271c20fae9.
