Tech Lead Other Tech Leads | Software Engineer Career Strategy

In order to be promoted to senior engineer, you need to be seen as a senior. Otherwise, management would lose credibility by promoting you. Writing quality code is a significant part, but not all of what is required.

The strongest way to build credibility as a senior engineer is to establish yourself as an authority.

There are three ways to build authority in your company and on your team.

1. Own a significant piece of the codebase.
2. Build exceptional knowledge in a domain.
3. Be highly intentional in your process.

Own The Code

The most effective way to build credibility as a senior engineer is to take ownership over a significant piece of the codebase, and make it better.

You want to own the most significant piece of the codebase that you realistically have the skills to manage. If you’re new, take the module that everyone hates and make that turd shine.

Consistently write quality code that your team trusts. Make sure you’re familiar with the team’s best practices, and follow them. Once your team trusts your code, they’ll start to trust you with more important features.

Only a certain amount of work can be prioritized. Part of your role as an experienced developer, and aspiring senior, is to properly advise the Product Owner/Project Manager and other teammates. Practice your ability to:

• Assess risk associated with a particular initiative. What are the chances something goes wrong when the requested change is released? Risk factors may point to an opportunity for optimizing the codebase.
• Identify and prioritize technical debt. Nobody will appreciate this more than senior developers.
• Advise on solutions that balance effort and reward. Can we accomplish a close, similar outcome with less effort? Or achieve a greater reward if we do a little more?

Find a piece of the codebase you want to own. Grooming is the best time to talk about this. If your team trusts you, and it isn’t already owned, they should gladly assign future work on that module to you. This is your opportunity to show everyone what happens when you take ownership over something.

Note: Teams may practice weak or collective ownership of modules. The strategy still applies, but adjust how collaborative you are.

Build Your Expertise

You may establish yourself as an expert in a technical or business domain.

It could be as simple as you’re better than average at front-end or SQL, or able to advise on financial compliance like SOX. You’ll be seen as an authority on that topic, helping your credibility as a senior engineer.

It’s important to find your niche within the company and the team. What is special about you? Are you just another developer that is good at coding? Or is there something unique about you? It doesn’t have to be anything spectacular, but you need to be able to articulate it.

This one is simple, but hard. It requires dedication.

When you find something that you’re really good at, go out of your way and put in overtime to provide any value to your teammates in that regard. Host brown bags (presentations), share tips and tricks, jump in with an eager spirit when someone needs assistance.

Make it part of your brand. When you’re seen as an expert, there is an authority associated with that, and people will perceive you as a leader in that domain. This will make it easier to transition to a senior role in the minds of your colleagues.

Be Intentional

Through the whole process of grooming, implementation, code review, deployment, and monitoring, you need to be able to discuss the full scope of an issue with a fellow engineer. This includes the code, infrastructure, business rules, compliance, risk, and dependencies. And you have to do it with clear process and intention.

When you are very intentional about your process for developing and implementing a solution, you are better able to communicate that with fellow engineers. It builds trust and reliability to know that you’re operating based on a system and not just flying by the seat of your pants.

Start a document where you clearly outline your step-by-step process for different tasks. You can start with high level categories like planning, coding, testing, monitoring, etc. And then break it down depending on your specific project types and infrastructure.

Once you’ve defined and refined your process, you need to demonstrate it. The best way to do that is to dominate grooming and code review. When you have a significant feature in a module that you own then you will be in a primary position to speak authoritatively and demonstrate your effectiveness.

One Last Note…

These strategies should be applied appropriately. It’s up to your own good judgment. Don’t champion any particular strategy too forcefully, or you’ll risk looking self-important.

These are healthy practices that, when applied at the right times, can build you up. But you have to come from a service mindset. Otherwise, it will feel like you’re trying to take something. It can’t be about you and what you want. It must be about your team and what they need.

Subscribe for the next post in the series!

Video Coming Soon!