Growth and Career Progression as a Software Engineer

Benze Tang — Sun, 12 Feb 2023 09:31:06 +0000

Being an engineer manager for the past few years has given me chances to have 1-on-1 meetings with my team members. I found that topics regarding personal growth and career progression often pop up in our discussions. So I'd like to share some of my thoughts on this topic in this article.

Expectations for each engineer rank

The typical engineer ranks are junior engineer, senior engineer, and tech leader/expert, which in my view, can map to the E3, E4, and E5 ranks in Meta shared in this article.
Below is my interpretation of the expectations for each rank.

Junior Engineer

The expectation for junior engineers is to deliver tasks independently within a reasonable time and with the expected quality. As a fresh graduate from school or someone new to the industry, the focus at this rank should be to become a professional/qualified engineer. This means being skilled at the technical stack, familiar with the engineering workflow and system infrastructure, and comfortable working with different roles in the project team.

Senior Engineer

Compared to junior engineers, the expectation for senior engineers is to handle tasks with higher complexity and contribute autonomously.
All the projects/tasks we're doing have various levels of complexity, and a highly complex task can be divided into smaller and simpler tasks. Although the skill set remains the same as senior engineers, we will be expected to handle tasks requiring a deeper mastery level. We should be able to solve most of our projects' technical problems, come up with valuable project initiatives, and sometimes help divide a complicated project into tasks of suitable complexity for other team members.

Tech Expert/Lead

A tech expert/lead usually will be given a project scope, and there are two expectations within the scope.
Engineering skills: We should have the skills to solve any technical problems that arise from your project scope. And if sometimes the solution to the problem is out of our scope, we should be able to analyze the problem, identify the correct team to solve the problem together with, and drive the project forward.
Project leadership: Since engineers at this rank are expected to lead a project scope, a certain leadership level should be demonstrated.

Engineer Manager
After reaching the tech expert/lead rank, engineers may have the chance to decide if to fork into the managerial track or continue to grow in the technical track. Becoming a manager means taking up the responsibilities of management. Anyone aspiring to pursue this path or who has already taken this path should know that this is a different job with a different set of responsibilities, which requires a new set of skills.
Regarding the responsibilities of a manager, I'd like to think of the team the manager is managing as an independent organization and the manager to be the organization's CEO. It means the manager has to understand the team's mission and do whatever he/she can to fulfill the mission and keep the team thriving.

About Growth

Growth can be reflected in one's ability to create value. Simply put, imagine the value of a person's work can be measured with a virtual currency $ (This is just a theory, practically, it's hard to do so). If previously a person could create $100 of value per week, and now the person can create $200 of value per week, this is growth. And to achieve this, we will need to become more skillful, knowledgeable, and experienced.

Problem-Solving

Problem-solving is how engineers create values most of the time. I believe what defines our career is the problem domain we're working on rather than our skillset, so I prefer to refer to myself as an FE engineer rather than react/react-native developer. If the problem we need to solve requires certain skills, then we should develop those skills.

We shouldn't let the job title define what we should or should not learn. Most of my skills and knowledge are acquired through solving some problems that I need to solve, and my confidence in my ability is based on the problems I've solved rather than the skills and knowledge I have.

Looking at what kind of problems one can solve is usually the most direct way to evaluate growth. There are two distinguishing ways of problem-solving.

Recognize what the problem is and match it with a known solution.
Analyze the problem and go down to the fundamentals layer by layer, then solve the problem based on the fundamental understanding, which sometimes involves creating something new (First Principle thinking)

In the early stage of our career, the 1st way is predominant. We usually grow by experiencing more problems and improving our solution toolbox so that the chance a problem can match a solution in our toolbox can be increased.

But to progress further, we must get used to the 2nd way of problem-solving. I would expect any engineer reaching the level of tech expert/lead to be able to solve problems in this way. After a certain level, we need to move away from the mindset that a problem can not be solved because we don't have the solution (or the existing solution doesn't support this case). No matter the problem, we should be able to analyze how the problem is constructed, the possible actions to take, and the corresponding cost and expected outcome of each. Then provide the analysis to the decision-maker to decide how to proceed (or not) with that information.

Growth Mindset

Mindset is very important for growth. Although I don't know what the right mindset for growth should be, I think the following ones are wrong and will ultimately limit our growth.

"Not an Exam."

This is a common mindset I observed in many people (including myself), and I think it's cultivated by the education system. In our education system, exams have explicit grading rules, explicit scores, and the expectations according to the exam scores, such as which college to go to or what degree to get. Based on all these, people decide how much effort to put into the study.
However, in actual work, there are not so many scenarios that are as explicit as the exams in school. Usually, we may need to do something that doesn't have explicit grading rules, explicit scores, or what to expect after doing it, i.e., not an exam. In such cases, people may choose just to get the work done but not devote much effort. The reasons why this would limit our growth are:
Losing the chances of learning: it's hard to learn something without devoting enough effort.
Losing the chances of winning new opportunities: our work sometimes may win us new opportunities, such as working on challenging projects, working with other strong engineers, or working with some senior leaders. But because the work is not done well, it may cause us to lose the opportunity or lead to bad consequences.

"I can't, so I needn't."
What we need to do is determined by our current responsibilities and the responsibilities we aspire to take. It's normal that once we start doing what we need to, we will start encountering difficulties, and it's tempting to use these difficulties as the "reasons" to convince ourselves that we don't need to do this. But we must overcome this temptation.
It's ok to review why we need to do what we're doing, and sometimes there could be legitimate reasons to stop. But if it's clear that we need to do it, the focus should shift to how to resolve the difficulties (within a certain timeframe). And to resolve the difficulties, we should try every means possible, including seeking help.
It's normal to encounter problems we can not solve at work, so seeking help is normal. But after the problem is solved, we have to spend some time reflecting on why we were not able to solve the problem and devote some time to make sure we can solve the same problem next time. That is how growth can happen.

"It's working."
A sign of becoming a mature engineer is the realization that something that is just working is not good enough. A project doesn't end when it's delivered. It just starts to "live" when it's delivered, and the actual end of a project is when it gets shut down. This means that aside from getting something to work, we must also consider whether it's working in the right way. In my career, I've learned that something not working the right way will eventually go wrong. When that happens, it will cost us a price. Although the one who pays the price is possible to be someone else. Anyone with a long enough career should have the experience of paying the price to understand this.
If two different ways can lead to the same result, everyone will choose the easier way, and it's right to do so because it's more cost-effective. However, in reality, different ways always lead to different results. Furthermore, in most cases, the right way will produce a better result in the longer term, but it will happen to be the harder way. Being able to resist the temptation to choose the easier way and insist on the right way will reward true growth in the end. Plus, based on my experience, insisting on the right way will make things easier and easier. Choosing the easier but wrong way will make things harder and harder, and after a certain threshold, it becomes desperately hard that nothing can be done.
But of course, insisting on the right things doesn't mean ignoring reality, it's a hard balance to reach.

"Who is right."
From time to time, people get into arguments about who's right. But ultimately, "who is right" doesn't matter. What matters is "what is right."
Focusing too much on "who is right" will just make it harder to align on "what is right." As long as we can get to "what is right" in the end, we don't need to care too much about who gets it right or wrong during the process.

"This is how/what other people do."
This way of thinking is essentially using other people's standards to set expectations for ourselves. It's not wrong when those standards can help us improve, but there are two pitfalls:
It's tempting to use it as an excuse to lower our standards; even if the standard from others is good initially, we will have to outgrow it eventually. Otherwise, that initially good standard may become limiting after a certain point in time
If the standard is too high, it may be too daunting and demoralize us, so we won't even try.

A better way to ensure consistent growth is to define our own standard and continuously raise that standard.

"I will try it again."
It's good to be persistent, that's how a difficult problem can be solved. However, repeating the same thing but expecting a different result is a fantasy. Unless when trying for a random event. But most of the things we're working on in software engineering are not truly random, even the random number generator (after all, we're not working on quantum physics).
Whenever we think about trying something again, we have to ask ourselves what will be different this time. Will we try a different approach, or will we look at something that we haven't looked at before? If there's no clear answer to these questions, it's better to save time for something more effective.

About Leadership

The word "leader" defines the expectation of leadership, which is to lead. This implies that the role of a leader only exists when multiple people work together, and the leader leads while the others follow. It's the responsibility to lead that makes one a leader, rather than the skills, the knowledge, or the experience. That responsibility is mainly for two aspects:

the purpose that the team is working for
the people working in the team

The purpose

Achieve Alignment
Usually, people form a team to work together for a certain purpose. Everyone on the team should understand the purpose. And to fulfill that purpose, the leader is expected to help the team align on the following:

what: what should the team do to fulfill the purpose
why: why should the team do what it's doing/going to do (the linkage to the purpose)
how: how should things be done (solution, process)
who: who to do what (task assignment, project scope assignment, responsibility assignment)
when: when to do what (task scheduling, timeline arrangement, priority definition)

To achieve alignment, there are many different styles a leader can choose, from authoritarianism to democracy. But no matter what style is chosen, the expectation is always to reach alignment within the team. Otherwise, the team won't be able to function efficiently. This is not an easy task to do. That's why so many so-called leadership skills exist, and communication skill is definitely one of the most important.

Set Direction
Normally, the greater the purpose is, the harder it will be to achieve. And many of the purposes we're pursuing may never be fully achieved, as there will always be new struggles to deal with.
The importance of direction is that we can know where we're heading, how to make daily progress, and actually see the progress. So that even if we're not reaching the final ideal status, we can still know what we're doing every day is meaningful. And week by week, month by month, quarter by quarter, we can see we're making progress. That's necessary to give people hope and motivation to keep going. And that's why the leader needs to help set direction.

Set Expectations
When a leader assigns someone to do something, if there're certain expectations regards to the timeline, the process, the solution, or the result, those expectations need to be communicated in advance. Otherwise, there's no reason to blame people for not meeting expectations because those expectations are not set initially.

Set Example
A leader has to communicate his/her ideas to the team members correctly. But communication between humans is not as effective as most people think. The purpose of communication is to transfer an idea from one mind to another mind, this is done through:

encode the ideas into words
transport the words through some medium (sounds, texts)
decode the words back to the idea

Every step in the process is (highly) likely to cause some error, especially the encode step and decode step. So one way to reduce the error is to reduce the encode/decode needed, which means finding/creating a good example and showing it, so people can understand the idea by observing the example themselves.

The people

Aside from the team's purpose, the leader is also responsible for taking care of the people on the team.

Provide a conducive working environment

An experienced leader should be able to sympathize with this meme. In reality, most of our work is not as easy as it appears. There will always be difficulties, disturbances, and noises. But a good leader should be able to shield the teams from those external factors so that the team members can focus on what has been aligned, stay productive and keep growing.

Provide help when needed

Sometimes a leader will have to delegate work after reaching alignment, but when delegating work, the leader must also ensure the person delegated is capable of delivering. This requires:

Carefully judging the person's capability and the requirement (effort, complexity) of the work
When the person's capacity falls short of the requirement, provide the necessary help. For example, assign someone who can fill the gap to help along the way, provide some guidance and training to fill the gap‚Ä¶
Be "there" to observe and be reachable when help is needed

Grow the members

There's ultimately a limit on what one person can do. If a leader wants to achieve more, growing the team members is a must.

Because the leader is usually the one with more experience, more skills, and more knowledge, it's common that there will be work that only the leader can do. If that's the case, the leader will have to do the work him/herself. But if the leader's capability is fully occupied by this kind of work, then the team will not be able to accept new challenges or withstand unexpected difficulties. Therefore a leader needs to constantly think about how to enable the other team members to do what him/herself can do.

About Management

It's easy to confuse leader and manager. In short, "leader" is a role, anyone who takes the responsibility of leading is considered a leader. While "manager" is a job to do management, specifically, performance management.
A leader's focus is on leading the team to deliver its purpose and take care of the people in the team, and a manager is a leader, so he/she should fulfill the leadership duty. Aside from that, the manager is also responsible and accountable for the team's performance, which boils down to each individual's performance. Therefore, the manager is expected to:

evaluate each team member's performance
improve each team member's performance and the team's overall performance

Anyone who has become a manager or aspires to become a manager should know that being a manager is a new job rather than a continuation of the previous job (engineer). Failing to recognize so will be detrimental to the team and the manager him/herself. As the whole team's performance depends on the manager, the damage could be huge if the manager doesn't know how to do management work.

The skill set required by a manager and how a manager approaches working are very different from an engineer. Think about this, most of us spend at least five years of training to become a qualified engineer, how can we expect to become a qualified manager overnight just because of being assigned as one? Therefore, a manager should consciously improve management skills and eventually form his/her management style. This is also a difficult but rewarding self-discovery process.

I recommend reading this book, "The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change." Even if you're not going to become a manager, it would be beneficial to understand management work and what to expect from the manager.

Closing word

What is shared above is just some explanations and reasoning for growth, which is up to you to judge whether they make sense. But below I'd like to give two suggestions that I hope everyone can take.

Take your actions
If something is important to you, please take your own action, don't count on others to make things happen for you. This Little Red Hen story from Mark Twain explains the idea vividly, please take a look and think about it.
When you take your own action, even if it turns out to be a mistake, you will at least be able to learn something from it.

Be honest
My manager once told me that I need to be "sharp." While I understand what being "sharp" means, I do not understand why I was not "sharp" enough because I'm confident that I'm intelligent enough and skilled enough to be sharp. Eventually, I realized that it was because I wasn't honest enough. When one is not being honest, it means one is:

withholding the truth, which appears to be quiet, mumbling, or stuttering
telling a lie, which appears to be inconsistent, illogical, chaotic

In either case, one appears to be not "sharp." Therefore I suggest you be honest:

If you don't understand something, don't know something, or are not able to do something, admit it and work on it.
If you need to do something, don't lie to yourself you don't need to it
If it's not right to do something, don't lie to yourself it's ok to do it

Be honest with the others:
Share your honest feedback, opinion, thoughts, or concern, as long as they come with goodwill.

DEV Community: Benze Tang