How can I get better at my technical influence?

Here's a checklist to go through to increase your impact and/or visibility.

• Draw a connection between your work and the OKRs of your management
• Actively help others and elevate their work. It's only a matter of time before reciprocity kicks in.
• Document and publish your accomplishments in written form. Don't purely rely on verbal communication during live meetings.
• Seek out some higher visibility tasks such as running a training, leading new hire onboarding/intern program, presenting a 'win' / topic at townhall or even participating in the company's ESG initiatives. No need to do everything and don't force it, just do what works for you.
• Leverage your 1-1s to get your manager's support to find more impactful work and make it easy for him/her to share your accomplishments with other (i.e. I always do a full writeup that they can simply hit 'forward' and share with the broader organization)
• Expand your network to those beyond your immediate team / project. This can lead to finding a new side project or even a new sponsor/team altogether.

Casey provided excellent advice on increasing technical influence. I will try to address your other concern of trying to understand a large code base. Here are some tips:

• Use your product to understand what features it provides and how they relate to the codebase. This will improve your high-level understanding.

• Reading existing documentation on requirements and design. Even though these might be out of date, it'd help you understand the core concepts which will make reading the code easier.

• Read through the tests to understand the behavior of the code. Tests are the most up-to-date documentation of code.

• Start making minor refactors on the code base like renaming functions and variables, making functions smaller etc. This will make it more readable and can also help you understand it better.

• Pick small tasks (feature updates, bug fixes) dealing with a single feature/component. As you work through these tasks, your understanding will gradually improve. This is the most effective way to understand a piece of code thoroughly and make it stick.

Hope this helps.

These are great questions! There's 2 big, very important components here, especially for mid-level engineers:

1. Increasing technical influence
2. Broadening technical understanding

These go hand-in-hand, but they're still different and require different tactics. Because of this, I'll split up my response into 2 parts.

Increasing Technical Influence

• Build a reputation as a stellar executor - This is the absolute first step. If you aren't known as an engineer who sweats the details and cares deeply about code quality, there is no chance that other people will respect you when you share your technical opinion. I recommend following the advice from this video to make your code amazing: One Diff, One Thesis - What Every Code Review Should Be Like
• Do a lot of code review - After you master writing great code, this is the very direct next step to help others write great code. You can learn how to do that here: "How to give better code reviews without full business context?"
• Build up your presence in meetings - This is the most impactful and final step. In particular, you want to contribute a lot to technical design meetings. This step can actually be broken down into 2 sub-steps:
  • Get comfortable asking questions - In the beginning, your goal is to just figure out what's going on, setting up the "foundation" for you to more meaningfully contribute later on. Check out the tactics here to ask good questions: "I struggle to come up with things that add value to a meeting - What do I say?"
  • Start sharing your opinions on technical direction - After you have the ability to quickly read through a technical spec and understand it, you can now influence the team to improve it. Watch my system design series to learn how to come up with actually good technical opinions: System Design Masterclass: Taro Playlists

Broadening Technical Understanding

• Get really good at debugging - Fixing bugs is the best way to learn a codebase as it forces you to learn the entire flow end-to-end. Put yourself on the hardest bugs that other engineers run away from as those usually cut across multiple stacks, which pushes you to understand even more of the system. I saw this behavior all the time with engineers growing to senior and staff (and I did this myself). You can learn how to become an expert debugger here: [Highlights] How To Become A Debugging Master And Fix Issues Faster
• Talk to people - I'm an Android engineer, but I was a tech lead at Instagram. This meant I was responsible for shipping entire projects, not just those on Android. This is why I had tons of 1 on 1s with iOS engineers, back-end engineers, and machine learning engineers. If you don't really understand how a system works, don't be afraid to ask. It's crucial to build up relationships with engineers across the entire stack, and we gave a masterclass about it here: [Masterclass] How To Build Deep Relationships Quickly In Tech

Most people here are talking about focusing on social "influence." I disagree. If you have a project that is well thought out, made simple, and well reasoned via an ERD that is 80-90% of the way there and several reviews from other people, there will be no shortage of people eager to jump on it for an easy win, especially if it has high impact.

Social influence just gives you an edge but is not a substitution for proper engineering.

What you've described is the "what" of software engineering, not the "how". That is, you are overindexing on information. Overreliance on this is very dangerous because you will never be able to fully comprehend all the intricacies of a constantly evolving codebase. What was true 6 months ago may not be true today.

I have never met even a Staff Engineer who could 100% tell me with absolute certainty what is happening across tech stacks that he has never worked on, only a rough general mental models for how they interact with each other.

It is only when you work with the code itself that you really understand what information is true and what is false. People may be mistaken. Documentation may be outdated. They are good starting points for information but you should weigh the accuracy of the information with the source.

There is what you think you know. Then there is what you can prove.

So I will tailor my answer on how to achieve this.

Consider that the job of a senior engineer is be able to solve "known" problems but the solution is "unknown". In most cases, this usually is a product or a feature that requires participation from both mobile, backend, and other tech stacks.

Work backwards: what kind of work should be expected?

1. The project should have a solution that is sufficiently de-risked and well reasoned. Why is it the best possible solution out of all other solutions? Why should things be implemented your way versus other ways?

2. Each part of the solution should be discrete, well laid out, and step by step such that anyone can do it. These usually correspond to Jira tasks.

   However, unless you've specifically interacted with that code, you're probably not going to be able to do this. What is most likely to happen is that you will have to consult with several experts in tech stacks that you are going to be making changes in and asking for their opinions. What components need to be modified, how the system at a high level interacts, what significant changes have been made in the past x months that you should be aware of, etc. You may need to also see a sample example of each of the interactions for clarity.

3. Hypothesize and iterate. Research is par for the course. You will have an idea of a solution. It will probably be wrong because you didn't know a few details that someone else will bring to your attention. Then you will need to improve your solution's design over and over again until it is the right one. This is what the ERD process is. It is a high level overview of how different systems, code, and contracts interact with one another. This is what you want to be able to visualize and understand. Yes its kind of a PITA but to be honest, clarity of design and thought and consensus about what is important and how to do things and checking for what you do not know is going to save you a lot of grief later on. Especially when avoiding crashes.

4. When in doubt, delegate. For areas you are responsible for, your knowledge should be deep. For areas you choose to delegate, you should have the right rough broad strokes and let someone else fill these in. It is not necessarily important that you know how to work with a custom in-house architecture on the mobile side if you're a backend engineer. All you need is for the mobile engineer to craft a feature that does xyz behavior when abc payloads are sent from the backend.

5. If all else fails, sometimes put the team on your back. I've been in projects where people who are responsible for their portion do not deliver or, at least, need you to figure out something for them. Do what is necessary to find the piece of information or general strategy. I find that finding example diffs that are similar to what is expected is a very good way of communicating this. Chances are, in a mature codebase, standards have been set and features don't differ too much from one another. You can probably dive into the git history and pull up a change similar to the one you are thinking.

Your relationships with people are not nearly as important as your ability to execute and deliver. Or rather, your relationships with people are meant to allow you to execute and deliver on projects. Influence is leverage but if you cannot even deliver or execute, there is no sense in applying leverage or influence. Why should people do what you say when you do not have a clear plan or vision for how the product will be made?

At the end of the day, your solution should be mostly right. There will always be small hiccups not accounted for but they should not move the solution roadmap too much unless you're dealing with something very bleeding edge or you're looking to perform a task where both the problem and solution are unknown (and therefore, nobody has any context on).