Becoming a force multiplier
One of the most impactful things you can do is aim to become a force multiplier. This concept is under-noticed among engineers but can make a sizable difference in a project. Force multiplier work is one that, when delivered, will allow other people to deliver faster.
Whether you want to be a Staff Engineer or an Engineering Manager, this is the most crucial bar you need to clear. A staff engineer or an architect does not do 2-10x the work of senior engineers. Still, they make teams 2-10x more productive by working on areas that will improve productivity.
Force multiplier work is one that, when delivered, will allow other people to deliver faster.
If you make a specific improvement that reduces by 5 minutes of your engineer's time in each task, and if they perform about 3 tasks in a working day. In a team with 5 people, you just gave your team 375 days of work in a year. There is no 10x engineer, but there is work done by one that can have a 10x impact.
For example, a team impacted by constantly shipped bugs leads an engineer to create critical automated testing. This results in fewer bugs breaking production and speeds up every engineer on the team by reassuring them that their tickets will not break when shipping, also saving hours of debugging.
Another case would be a team that has to work back and forth frequently because new technical requirements constantly change. However, one engineer can produce excellent technical specifications by communicating effectively with stakeholders before writing the first line of code, saving the team hours of rewriting code.
The larger the number of people impacted by a positive change, the more critical the multiplier aspect is. Not every change needs to be so dramatic, but some can be even more productive, especially the ones that remove a communication overhead.
Seeking opportunities
Force multipliers are difficult to detect because they are specific to a team and codebase. But as a general rule, good potential candidates are bottlenecks and inefficiencies that drive daily aspects of the engineer's work, for example:
Overengineered code architecture that requires the engineer to write duplicated code across codebases, with some occasional bugs.
Quality control gaps, especially in automation, make the engineers take more time testing their tickets or shipping bugs requiring new tickets to fix.
Outdated or reinvent-the-wheel code that introduces a lot of bugs, requires constant attention and makes it hard to find solutions to problems online due to documentation only supporting newer versions.
There are also non-technical cases, such as proposing improvements to the shipping process, such as ticket structure and ceremonies, to avoid additional meeting overhead.
Therefore, look for gaps in your team. Your manager can help you identify those, but as someone working actively in the code, you are privileged to know how things are. Asking your fellow engineers what they dislike but have to spend their time on the project is also a good way to get that information.
I am writing an open-source book for engineering managers (EMs) seeking to enhance their skills and senior engineers aspiring to transition into an EM role. If that is your thing, check out the Github