Why owning your onboarding is key to making a great first impression

If you have been working in the tech space for any non-trivial amount of time, you have probably heard the term "ownership" thrown around and how teams and individuals that embody it are more successful. Executive leadership going around telling their staff that they want them to work like this is their own startup or product, and so on and so forth — As an engineer, I can't relate to handwavy stuff so let's cut to the chase.

While ownership can be exhibited in various levels, for example at a feature level, at a system level and at a team level, each one worthy of its own article. Today I want to focus on ownership during your onboarding process in context of a young startup team.

I will be sharing key learnings and anecdotes from my experience, then some ideas on steps individual contributors (ICs) and managers can take to recreate these positive outcomes within their own teams.

A rough start

I had suffered from a very rocky onboarding in a prior company, due to a gap between my experience at the time and the role's needs, my manager overlooking this and hence unable to set the right expectations explicitly from the get go. The anxiety caused by not being able to get up to speed as requirements ramped up was etched deep into my memory.

So when I joined my next role I knew that in a fast paced environment I simply cannot expect my manager and co-workers to be available as much as I'd like and that I was not going to wait for expectations to be set either. Additionally motivated by the need to avoid past mistakes I ended up over compensating.

Spoiler! it ended up being a fantastic idea!

So here's what I did...

After I got the offer I immediately used my down time during the notice period to familiarize myself with their stack — tutorials, articles, practice projects. Whatever I could get my hands on.

First day at work! The team was young and as expected documentation was still quite immature, things were moving fast and while my manager and team members were some of the most helpful people I have ever met, everyone was busy trying to ship and hence their time needed to be used wisely.

In my first week rather than trying to hack away at some backlog items or bugs, I got access to the staging database and I dug deep into the app's UI instead. I Went through as many flows as I could and wrote down for my own reference what parts of the UI were driven by which APIs and their respective tables. Also when I ran into issues setting up the project as a new joiner, I updated the documentation with my findings.

This very self-service approach helped me create my own small map to navigate the system as well as come up with targeted questions with educated assumptions. Hence my questions were more like clarifications "Is X module/api for so and so purpose?" rather than "What's the purpose of X module/api?". This helped me get answers for dozens of questions in a single meeting and was appreciated by my team members as well since it valued their time.

In addition to that, this unearthed the short comings, anti-patterns, bugs and QC challenges in the system quite early on and helped me significantly increase my proficiency in technical discussions just by the end of the second week of joining.

While I did not think much of it then, but looking back, that initial head start mixed with some luck, a great boss and team members triggered a set of events that paid back dividends to our team and myself.

Because I brought in a new pair of eyes to the code and combed the system in such an aggressive manner for my own sake, by the end of the first month I was able to identify key improvements to the codebase which I documented in a detailed RFC.

With the support of my team we ended up implementing the proposal which resulted in improved code quality and productivity for everyone on the team. This happened right before things picked up significantly for the company leading the team size to double. The timing of all this helped the new engineers onboard into far a more structured code base and workflow from the get go.

Key learnings and ideas

For individual contributors

? No one asked me to take the approach I took, which means had I taken a less aggressive route to my onboarding I may have done just averagely, would have failed to make an impact, lost out on learning and a great first impression and would not have stood out as much for a promotion.

? Your team members recognize when they see you are making an effort to respect their time, this goes a long way when you genuinely do need to seek out help, so...

? Try to seek out an answer on your own

? Try asking for a clarification/confirmation rather than an explanation

? Try to batch several questions together

? Be the change you want to see in the team. Young teams are often in the process of forming their culture and a team genuinely looking to form a good culture will adopt positive traits regardless of who initiates them.

? If you are a junior or intermediate engineer don't let that discourage you. Exhibiting ownership and initiative are as important as technical ability to getting promoted.

For managers & leads

? The culture and open mindedness of my boss and team played a key role in achieving a positive outcome. Young teams may not have their culture nailed down but having some general guiding principles in place can go a long way in preventing toxic and suppressive cultures from forming.

? No one asked me to do what I did but what if we as managers consciously front loaded certain ideas and making new joiners comfortable with the team's culture by...

???Conveying openness e.g "We really appreciate a fresh set of eyes"

???Highlighting areas of improvement and high leverage e.g "We are looking to improve our testing / pipeline / docs / tracking / logging etc"

? Sometimes just advertising your culture is not enough. Once during a 1-1 meeting I found out that a new joiner had some really excellent ideas to share, but we did not hear much from him during team discussions. Further inquiry revealed that this was due to his experiences at a past company where him being vocal had backfired hence I needed to do a bit more to ratchet up his confidence.

What other steps do you think we can take to super charge onboarding of new talent into our engineering teams?