Studies have shown that one of the most common reasons for burnout happens in the workplace: you don’t have any control over your job’s expectations and activity. While it seems like long work hours are the common reason for burnout, a common feeling for burnout is because their work is not appreciated.
Software engineers often switch jobs because they feel like staying in one job stops their growth. Thus, switching jobs is one of the fastest ways to increase one’s net worth and title.
As software engineers, we yearn to do meaningful work. That meaningful work, to translate into plain English, is valuable work. It is the work that effort doesn’t go unnoticed. It is the work that brings value to the organization. It is the work that can bring direct translation to one’s performance review; help us get promoted.
There are a lot of ways to create meaningful work and become a valuable member of your team. However, we often misunderstood what counts as being valuable. For instance, we tend to think that working more hours means more value to the company - this doesn’t necessarily true. More hours doesn’t necessarily translate to more output, and too many hours, as I said early, can lead to burnout and decreased productivity.
Another myth about becoming valuable is to be strong in your technical skills. Strong technical skills may able to get a good job with a great salary. However, pure strong technical skills alone are not enough to go up the software engineer ladder.
To become more valuable in the team is to create impact.
In this article, I would like to share three tips that you can do to create impact and become a valuable person in your team.
Involve in Highly Visible Project
Work with a project that is critical to the business system.
The project is usually client-facing. Your product will have a direct impact on the clients of your business.
It can be tough to evaluate what kind of project is critical to the business. You don’t have full visibility on what the executives decide on the action future company strategy. As a rule of thumb, a highly visible project will be an important feature, or maybe even a flagship, for the company. There will be very high expectations of quality, and all defects will be knowns by the manager or executives.
For instance, the payment system in Saas is a highly visible project because it is a critical feature for acquisition. If you don’t have a payment system, you are not able to generate any sales.
Within the payment system, creating the core payment processing system is a highly visible system because it needs to be available at all costs.
Tips you Can Do Right Now
Start with creating great execution with the current project. The progress and how well you execute on your current project can be great leverage to prove to the team that you can take on a more highly visible project.
Talk to your manager that you want to involve in a highly visible project. If your manager doesn’t assign you to one, you probably haven’t to earn trust in the team to execute that project because it is an important project. Someone is more ready to take on that project because of their past performance execution. In this scenario, going back to the first tips can help earn trust in your team.
There are many ways to solve a problem, and the team wants to make the right solution to the problem, not the perfect one. Therefore, one solution is not necessarily inferior to the other but has more convincing arguments to solve the current problem.
When I was teaching Scala to Java developers, they often asked me various questions on the best way to do certain things. One of the simple examples is how do you handle an
Option. You have a variable with an effective type of
Option, and you want to do something with the value. At first, I try to give them all possible solutions. Let them decide which one seems to be the best fit. My thought process was each person has their way of solving a problem. Your coding style may be different than mine, and I don’t want to force them to do it in my way if that is not the right style.
However, these developers do want to know an opinionated answer. Moreover, they want to know what is the reason for choosing one solution over another. Knowing these, they can learn how to write code in a Scala way instead of Java in Scala.
Having a strong opinion can help you stand out from other developers. However, standing out in itself is not enough - you need to explain why your solution is the best fit for the problem. You need to be okay with criticism and need to be flexible to change your belief.
A team that has two strong opposing opinions is well-rounded. Why? Because they can view a problem from more angles. For instance, one of our team developers proposed creating a centralized model artifactory for all of our microservices. One of the engineers has a strong opinion on not doing things that way because the time spent doing model updates will be tedious. By having a discussion and brainstorming session, each team member’s member was able to gain insights from these two engineers on the advantages and disadvantages.
Another reason to be opinionated is to make you become an expert in certain domain knowledge. For instance, a strong advocate in Scala’s functional programming makes you the go-to person to ask for any Scala or functional programming questions.
Tips You Can Do Right Now
Everyone has their own belief. Ask yourself, “What do you want your team members to perceive you?”
You may like a certain language because it is less verbose. You may like to use regular REST call from service to service instead of message queue because it is easier to debug product issue. Find material that is of interest to you - it may be hard to read many articles every day in your job to solve various problems. However, you may have a strong choice against some architectural patterns or some language features to solve these problems.
Once you resonate with a certain topic or material, preach it. Let the team know that your solution is the right solution to the problem.
Be ready to take on opposing views, and explain your thought process. Considerating on being opinionated is that you also need to be flexible, not take things personally, and give up your solution and take on a better one if that is the right fit for the problem.
Spread Knowledge As Much As Possible
Spreading knowledge can be: a simple pair of programming with your peers, creating better documentation for your system, create a systematic onboarding program that enabled the ramp-up of new team members quickly.
One of the important aspects that I undervalue is conducting a great code review on PR. Giving constructive feedback to your peers during code review sessions is the best form of mentoring and helping them grow their software engineer careers.
Volunteer to talk at a knowledge-sharing session and inform insights into the system that you are currently working on.
Knowledge sharing is the basic strategy to boost your software engineer career and build your brand. It can lead you to better job opportunities if you are doing this on the side. If you are doing this within your team, it indicates you are putting thoughts and value to help your teammates grow.
Tips You Can Do Right Now
Write documentation on every single system that you write. Marking everything you know to the system helps you be the less-critical person in the system and demonstrates how well they know about the system.
Writing blogs and having a knowledge-sharing session with the team demonstrate that you are a domain expert on the topic. However, you will need to do countless research, and you also need to be prepared to take on criticism.
If there are any conferences that you can attend, volunteer to do so.
Beyond technical skills, there are some interpersonal skills and gotchas to navigate through the tech career. To be a great leader, you will need to provide value to the team, and providing value means creating impact in the company.
Start involves in highly-impacted projects. Talk to your manager, and network with other teams to be involved in that project. Second, trust your ideas and preach them - find ways to create impact by giving different views to your team members. Last but not least, seek ways to share knowledge as much as possible. Sharing knowledge reinforces yourself to know the material well and helps the growth of your team members.
These three tips are the tips that I observe and used in my software engineer career to create immense value for my team members. If you do have any other tips, don’t hesitate to comment on them below.