Making Your Mark: Tips for Starting Strong in a New Tech Role

Whether you’re a new engineer or one with experience, you must first prove yourself in a new organization.

Experienced hires often think, “Hey, I have years of accomplishments at comparable tech companies, I should fit right into this environment because it’s just another tech company.” While your new employer may have many similarities to your previous organization, they don’t have intimate knowledge of your previous accomplishments over time. In addition, they aren’t familiar with your personality or your approach to problem-solving.

On the other hand, new engineers — whether they’re from school, a bootcamp, or self-taught — likely have not been in an environment with the type of pressures or interpersonal dynamics that can exist within modern technology organizations. At the end of the day, all engineers must earn the trust of their co-workers. Doing so improves your credibility in technical conversations, sets you up for good end-of-year reviews, and enables you to enjoy the organization more because of the mutual trust between you and your colleagues.

Here are five actionable steps you can take to gain trust and prove yourself early on in your new tech role.

Review pull requests often

Reviewing pull requests is the most underrated behavior that ALL great engineers do. The first and most obvious reason you should review pull requests is that it helps your fellow engineers. Many technical organizations require a certain amount of approvers to release code into production. While approvals are often necessary for engineers who want to release their code, fellow engineers are not obligated to give these out. In performance reviews, people are usually not judged based on the number of GitHub pull requests they approve. This introduces a conundrum. An engineer’s ability to produce at work is dependent upon other engineers who aren’t strictly measured by how fast you publish your code. By jumping in and helping your teammates out with this, you can solve a problem for them, while also letting them know that you’re dependable for a code review.

Does this mean you should just approve each and every pull request? NO. When you’re reviewing pull requests, they should be legitimate. Remember, there is a public record of your approvals. If the production system breaks, the code is unreadable for future development, or the design of the code is poor, that’s on you as the reviewer who gave the green light just as much as it is on the code’s author. So make sure to give actionable feedback, raise points of discussion, or even ask questions on things that may be unclear to you. The best rule of thumb I’ve heard on this is to only approve code that you would be comfortable deploying yourself — as if it were your own code. When your teammates see this, they will not only gain insight into your technical prowess, but also they will appreciate your thoughtfulness.

Another reason why reviewing pull requests will help you gain the trust of your fellow engineers is that you are learning. Your learning has a multitude of benefits. The learning you do has value to you as an individual, of course. Many people pay to learn in college or universities, bootcamps, or online courses. By reviewing pull requests, you learn how others solve problems with code, which will make you better at solving problems.

In addition to benefiting you, it also benefits your team. You may have joined the organization with degrees or top tech companies on your resume. However, even with all those accolades under your belt, you still don’t know the norms or the stack of your new organization. This means your feedback on pull requests and in design review meetings is less valuable early on, and therefore, less valuable or trusted. By reviewing pull requests and exponentially increasing your knowledge, your expertise and perspective becomes more useful to your team much quicker. And, in the tech industry, being useful and capable will increase your trustworthiness (with respect to your technical abilities).

Look for small wins

Unfortunately, when you join a new organization, your past achievements don’t come with you. That club you started, that complex architecture you designed, that tricky bug you discovered and fixed, that extensible class you created… none of it comes along with you. Even if the organization knows about it because of your interview panel, they probably don’t care about it once you’ve started, though they’re certainly hoping you can do it again to benefit them. So do just that.

At first, it will be very difficult to make substantive changes because you don’t know much about your team’s code or practices. We can build on the prior point about reviewing pull requests (PRs) to help us find small wins. In reading your team members’ PRs, you may discover bottlenecks or other problems in the form of “oh, we always do this because…”. Take this opportunity as a new employee and run with it while your plate is still relatively empty. By investigating those bottlenecks and problems early on, you may come up with a solution quicker than those who have been on the team for years and are responsible for multiple systems.

By being the one to call out the problem and taking steps to resolve it, you’ve measurably helped your team. Even if these wins are small, it demonstrates that you’re proactive, capable, and that you care.

Meet with people in-person

Since the world shut down in early 2020, remote work has been a contentious battle between employers and employees. While it’s been demonstrated that remote work can have tremendous benefits, many corporate executives are against the idea. We’ve recently seen Mark Zuckerberg, CEO of Meta, share his stance that he believes in the merits of doing work in person. When we compound the numerous examples of corporations favoring in-person work with how easy it is for the achievements of Black engineers to be overlooked, it’s my opinion that new engineers in an organization should try to spend time with their new co-workers in real life as much as possible in order to build trust.

One major reason for this is that when you’re in-person, you’re available for more informal opportunities to be of service. Let’s say there’s a pie that represents when someone needs assistance on a bug or wants to talk about a new idea. Even if 60% of that is expressed online via the team chat or in meetings, that still leaves 40% that wouldn’t be. Some portion of that would certainly be shared in-person in chit-chat between meetings, random walks to the water fountain, etc. As a new engineer to a team, it will be difficult to get in on those informal opportunities when you’re not there. These informal opportunities are critical for proving yourself in your new organization.

Secondly, being in person allows you to take advantage of the biases we know humans possess. In this new normal, there are still mixed feelings about coming into the office. Despite that, managers will more than likely still come into the office. As mentioned in my prior article, “Biases That Affect Hiring And Firing,” similarity bias is a phenomenon that occurs where people similar to the manager can be seen as favorable (according to evidence-based research). If we know that many managers go into the office and you go into the office just as much as them, it stands to reason that you may be able to benefit from this similarity bias early in your role with your new team.

Proximity bias is another one you could use to your advantage. When a manager or someone in a position of power works physically close to you, they tend to believe you’re working harder than someone they can’t see working. Although biases like this ideally shouldn’t affect your career, it’s important to know that they realistically can. With knowledge of these biases, you can navigate them and maybe even take advantage of them when you’re first starting in your new organization.

Get involved in extracurriculars

The rough part about starting in a new organization is that you don’t know anyone and nobody knows you. So you may go to work feeling a bit nervous, which could lead to you not performing your best. By getting involved in different efforts inside and outside of your specific team, you’ll be able to more easily integrate yourself within the organization.

For example, as a Black man, I’ve always wanted to help educate and promote technology careers in the broader Black community. So, when I join a new organization in which I’m one of the only Black engineers, I look to join some of the diversity groups. This way, I can not only serve my personal agenda of educating others about technology careers in the black community, but also I can help the organization attract talented engineers to work there.

Employee resource groups like these have benefitted me tremendously when I was first starting out, as they introduced me to other Black engineers, managers, recruiters, etc., throughout the company. They also enabled me to ask questions about how to succeed, create a community of like-minded individuals in the workplace, and become more comfortable in the organization. Having people that you actually like in your workplace is pivotal in making your mark. You’ll be excited to go in every day not only for your role, but also for the valued connections you’ve built there.

Do what winners do

If everything else I mentioned fails or doesn’t apply, there is always the surefire approach of emulating the top performers. Every engineering team is different and likely has its own unique culture. Some really value collaboration between engineers, whereas others put a heavy emphasis on delivering single-threaded pieces of value. So, when I’m in doubt about what to do so I can excel in a new organization, I’ll just observe my co-workers.

Usually, you can easily tell which people the managers hold in high esteem. When it’s unclear, rely on the following clues to identify the “winners”:

• Leaders of Meetings — People often vie for time with management. As a result, it is normal for their busy schedules to conflict with standing meetings. When this happens, the manager may designate a team member to run the team meeting in their absence. There may be something in this person’s actions that you could use to your advantage.
• Promotions — When it’s promotion time, pay attention to those emails! The engineers mentioned have a track record of major accomplishments. By emulating their engineering habits, you’ll be able to stand out for the right reasons.

To this day, I still remember my first day of high school football practice. Similarly, starting a new role as a software engineer has always filled me with excitement, nervousness, and a longing for success within my new organization. Just as I did, you too can gain confidence and start strong in your new tech role by doing the following: review pull requests often, look for small wins, meet with people in person, get involved in extracurriculars, and do what the winners do.

Thanks for reading! If you enjoyed this article, please make sure to follow me for more, share it with a friend, and like it!