Engineering a New Job: Part 3 - Onboarding
A practical guide on finding & thriving on a new engineering role
I’ve been working as a Software Engineer since 2015. I’ve had 7 full time jobs (plus a few more role changes), contributed to 12+ companies, and interviewed for many many more in my ~10 year career so far. Anecdotally, this is a higher-than-average rate of job changes, even for the software industry. As a result, I’ve acquired a good amount of experience finding, starting, and thriving in a new role.
In this 3-part series - Engineering a New Job, I share my personal approach to job changes - not only finding a new role, but making it a success.
Previously in Part 1 and Part 2, I shared my approach on preparation and the hiring process, respectively. This last part focuses on the onboarding process - how I can quickly settle into a new role.
Ramp up
Just as the foundation determines the height of a skyscraper, a strong first 3-6 months of ramp-up in a new job can meaningfully decide the ultimate level of success in it. As a result, it is essential to make the most of this limited-time opportunity, when there tends to be the most support but the lowest expectations.
Get a head start
As part of the hiring process, especially around the offer stage, I’m already thinking about setting myself up for success, if I were to join the team.
I would try to talk to as many people I would work closely with as possible
I would specifically ask for material or resources to start looking into
I would do even more research on the company/team and get a sense of how they work
So hopefully by the time I officially start a new role, I’m already somewhat familiar with the environment.
Explore then exploit
The number one priority of the ramp-up period is learning, so this is the time I have a heightened sense of anything that allows me to pick up new things more quickly, including:
Having 1 on 1 with as many people as possible, even if I might not directly work with them straight away
Do at least one pass on as many resources (docs, videos, training videos) as possible
Ask as many noob questions as possible, there’s only a short window of time I can do this without getting frowned upon
Volunteer to do as diverse a set of tasks as it makes sense to, e.g. write/modify documentation, help others debug, attend meetings, review code even if I don’t understand, shadow an on-call rotation
I prefer a Breadth First Search approach to onboarding, where I would survey the lay of the land first before I start focusing on specific areas. I feel this allows me to participate in more conversations earlier, and gives me a broader sense of priority, so that I’m not tunnel visioned on something that may turn out not very important.
As I build a more and more detailed mental model of the work, I can focus more time on specific areas.
Start small and build momentum
As I go from explore to exploit, I would also go from small problems to bigger ones, and this combination has worked really well.
Tackling small problems early on allows me to gain more cycles of “full-stack” processes, without being bogged down in one specific step. This way, I’m able to change code and quickly see how it gets deployed in production, which gives me exposure to all the tooling, from source control, to change management, and all the way to the monitoring stack.
Being able to register wins early on, however small, is a huge confidence boost for me, as well as for everyone around me. This sets off a snowball effect of me being able to tackle bigger and bigger problems, with higher and higher expectations.
Build Relationships
Having productive working relationships with coworkers are extremely important, and first impressions can very much set the tone for them. That’s why I make extra effort in starting off on the right foot with everyone on a new team:
I try to connect with everyone on somewhat of a personal level. My approach here is to try to find commonalities with everyone, whether it’s sports, certain experiences, or opinions. If I can identify something to bond with for everyone I talk to, that’s usually a great start.
I observe & follow the norms on the team. This can include small things such as what time people usually start and leave work, what time they lunch, what analogies they tend to use, do they small-talk, etc. It’s subtle, but once I follow the unspoken norms, people treat me as one of their own, and things get easier.
I try to be extra agreeable. Even if I have some strong opinions, I try not to ruffle too many feathers too early on - unless I’m specifically asked about them. Even then, I leave plenty of nuances.
I try to observe the power dynamics. Figuring out who tends to agree with whom, and whose opinions matter more in what situations would also allow me to find my way round the new team quickly.
Hold off on big ideas
Being the new person, it’s natural to come in with an abundance of enthusiasm, and frequently, this manifests in big ideas. Unfortunately, being the new person also means I have the least amount of context on the work. Most of the time, there’s something more nuanced as to why things are how they are, and why my big ideas are less practical than they first seem, I just don’t know about them yet.
As a result, I’ve learned to hold off on publicizing my big ideas, especially if they seem too obvious. Instead, I note them down for myself to look back on in 6 months. If they still apply, I will act on them then.
Summary
Adapting to a new role is not easy, and I’ve found the onboarding process to be a tricky balance between learning as much as possible, while also trying to impress everyone and establish myself. In attempting to be successful at both, I would:
Get a head start even before I officially join
Get as much exposure as possible when I join before digging deeper
Start small and get early wins to build momentum
Try to connect with everyone, fit in, and build meaningful relationships
Document big ideas, and act on them later