How to Become a More Influential Engineer?

Recently, I received a question from a reader asking: if your daily work mostly involves small tasks with little impact, what can you do? For example, frontend engineers often worry they're just cutting layouts week after week, year after year, without seeing real progress. Or backend engineers feel stuck writing CRUD APIs, doing the same work for months with no advancement.

This lack of progress can feel discouraging. You might worry about how to advance to senior level, or when updating your resume for a new job, you'll struggle to find meaningful accomplishments to highlight. In this article, we'll discuss how to start with small tasks and gradually become a more influential engineer.

I recommend treating the points in this article as a checklist for self-reflection. If you find areas you haven't addressed yet, you can set specific goals to improve.

Pursue Reliability Before Pursuing Influence

As mentioned in the article Do Good Work First, Before Pursuing Efficiency, it's important to do things well before optimizing for speed. The same principle applies to influence. Before chasing impact, focus on becoming a reliable engineer. Only when you build reliability can others trust you and be willing to give you more impactful work.

How Can You Tell If You're Reliable?

You might ask: what makes an engineer reliable?

Consider using these indicators to assess yourself:

• Is the quality high? Is the code you write high quality? When submitting to QA, can you ensure it won't be full of bugs and issues?
• Don't cross important lines. In software engineering, there are many lines you shouldn't cross. For instance, as discussed in How to Maintain a Good Release Process?, there are procedures you should follow before deploying to production. If you cut corners to move faster and skip these steps, and something goes wrong, the damage to trust will be enormous.
• Deliver on your commitments. If you promise something during estimation, do you deliver on time? Do you follow through on everything you commit to? Keeping commitments is the foundation of trust. Once you fail to deliver a few times, people will gradually lose confidence in you.
• Communicate properly. When working as a team, if there are any changes, do you ensure all collaborators are notified? Are you just telling them, or making sure they actually receive the message?
• Do you anticipate future issues? When doing something, do you think ahead about possible complications? Or do you just patch holes as they appear?

Many engineers feel like they're doing the same work over and over, but they don't carefully examine whether they're actually being reliable. When you build enough reliability to earn trust, it becomes much easier to pursue more impactful work.

Don't Become a 0.1x Engineer

The reliability indicators mentioned above actually measure whether you're a 0.1x engineer. Most people have heard of 10x engineers—those who produce 10 times more than others.

But at the other end of the spectrum are 0.1x engineers. These engineers not only fail to deliver their own work, they actually drag down the entire team's output. With these engineers on the team, productivity doesn't stay the same—it decreases by 10 fold.

This happens because when an engineer makes a mistake, the impact isn't limited to them alone. It affects the whole team. Take the "low quality" example from above. If this leads to an incident where production code needs to be rolled back, you'll need to create a new PR. Now other team members have to spend time reviewing it, which means less time for their own work. This reduces the team's overall productivity.

So along with assessing your own reliability, make sure to actively avoid becoming a 0.1x engineer.

The Same Problem Can Be Solved in Different Ways with Different Impact

The previous section discussed how to pursue more advanced work—you first need to become reliable in your current responsibilities. However, the reality is that the same problem often has multiple solutions with different levels of impact. In other words, you don't necessarily need to wait for new opportunities. You can take the work you're already doing, approach it from a different angle, and increase your impact that way.

Let's say you get a monitoring alert showing that a new feature's performance doesn't meet the team's performance standards. You might respond in several different ways:

• Level one: You see the alert, ignore it, and hope nobody else notices
• Level two: You spend some time investigating the cause and quickly fix the issue
• Level three: You immediately notify the team, fix the problem, then sync with them on the solution
• Level four: You notify the team right away, fix the issue, then document it and share knowledge with the team
• Level five: Beyond what level four covers, you also investigate whether similar potential issues exist elsewhere in the system and conduct a thorough review to find systemic root causes
• Level six: Beyond what level five covers, you think deeper about why this issue existed, how to address it fundamentally, and lead the team in optimizing workflows and implementation practices to prevent similar issues in the future

You can see that the same problem can be handled at many different levels, each with different impact. When you start feeling like your regular work is already familiar and you're not challenged or growing, try pushing yourself to the next level. Let's explore how to achieve each level.

Level Two: Self-Discipline

To move from level one to level two, you need self-discipline. Don't let problems slide. This discipline should apply throughout your work. For example, in the article Why Code Review and How to Do It Well?, it mentions that when you complete code, your PR message should explain what changed. Without self-discipline, and without team members pushing you, you'll keep cutting corners. Over time, this becomes a habit that prevents growth.

Level Three: Team Perspective

To move from level two to level three, develop a team perspective. Look beyond yourself at your teammates. In modern software development, nearly everything is team-based. A single person can't build complex systems quickly. So when doing anything, "thinking about your teammates" is crucial. When a problem happens and you communicate the solution to the team, that's team perspective in action.

With code review as an example, thinking from the team angle adds weight to self-discipline. If you're a junior engineer and a senior sees your PR lacking thoroughness, that's not ideal. If you're a senior engineer and juniors see poor PRs from you, they think "the senior developers do this, so it's fine for me too." This drops the team's overall quality standards and should be avoided.