Taro Logo
2

Onboarding Successfully To A New Semi-Chaotic Engineering Org

Profile picture
Mid-Level Software Engineer [SDE 2] at Amazon8 months ago

Context Of Company

This is a really well funded company (Bank) that underwent a large scale leadership change. The company's primary source of revenue was never it's tech capabilities, however with the new leadership change they're looking for a large scale revamp on how the existing systems work and are working on setting upto a FAANG equivalent engineering environment. This is vision is consistent across the leadership upto the CEO. This org currently consists of multiple Staff engineers from Twitter, Meta, Amzn and Google leading big initiatives.

Personal Context

I'll be soon taking up an offer in this company and will be joining this freshly created Org, where I've opportunity to be among the first 10-15 engineers to join with potential of the org to grow over 100+ engineers. There are lot of existing tech that have been already deemed unscalable due to previous decisions and have been a known business blockers, these tech require either re-write or a large refactor or a completely different viewpoint on tackling this problem. This will involve me working with Engineers who've built this system (Not part of this new Tech Org, rather the old existing infra), I've been already given a heads up from my potential manager that there can be potential hesitancy that the existing engineers may feel and wouldn't be too open to provide all information necessary as our systems will be replacing their soon (Have been reported that this has happened). There isn't a concept of internal wiki similar to Amazon or other Big Tech, hence lot of this is just domain knowledge etc. Fortunately the leadership is aware of this and is taking steps to answer this, and takes into consideration when scoping for projects and setting up right expectations.

The following are certain concerns that I've, and wanted to understand what is the best course of action I can take up to make my onboarding successful.

This is my Current plan, given i'll be among first engineers to join this team.

  1. Understand domain, reach out to multiple PMs and document all pain points, problems we are solving in long term & Short term.

  2. Go through code base of relevant packages and start adding their UMLs, HLD etc to best of my abilities to a document to move towards creating a Knowledge base.

  3. Socialize with engineers from the related org and try to gain their confidence, and potentially get few KT sessions (Not sure how i'll go about this as the team is situated in different city).

  4. Work with manager to setup boy-scout rule, such that everyone onboarding will incrementally add more to the existing knowledge base.

Follow Up Questions :

  • I still haven't taken up the offer yet and still have a week before I can respond. The increase in pay and the growth opportunity in the new company is significantly big, I can see myself reaching Sr.SDE in < 2 years and Staff in < 4 years there due to the problem space being so fresh and getting a really early head start. However, I'm slightly concerned if the lack of co-operation from other org and lack of documentation, and the fact that the entire org is being setup fully freshly could be a concern. What's the best course of action i could take to minimize this risk?
  • Second, one would view moving out from FAANG to a not well known company as a downgrade, would this still hold true if the problem space and opportunities in the new company is more complex?
138
5

Discussion

(5 comments)
  • 4
    Profile picture
    Android Engineer @ Robinhood
    8 months ago

    Congrats on the new job! It's great that you're excited about the opportunities ahead and proactively thinking about how you'll hit the ground running.

    Unfortunately, planning too far ahead (especially without reputation or a clear structure with the team/company) won't end like you'll expect: it's very likely that you won't be able to execute on that plan at all (either due to the company putting you on previously committed priorities or because you don't have the reputation needed to get traction on suggestions). This is a wrong turn I've personally taken down and a common one I've seen among junior and mid level engineers. The more detailed you are with things without a nuanced grip of team/business context, the more likely you will fail and waste time for little yield. Things are constantly changing in any healthy team/company, and attempting to force structure into something preestablished will not work. If you fight against the natural flow, your time and energy will be spent for little value and the current will probably just plow you over (aka your manager or TL politely tell you to work on some other task/project instead). Don't get me wrong: the things you are proposing are nice and generally good things to do/have, but the question is: does the team/business actually need these things right now? And are you even the right person to solve it?

    If you want make the best impressiom you can and build a healthy path for senior, the main recommendation I have is to start out by being more passive and progressing with the flow of the team/company:

    • Be thorough with your onboarding tasks and projects. Ask questions around the tools and frameworks used in the company, and try to clearly understand their interfaces and why the company chose those tools/technologies.
    • Oberserve the people on your team and on your projects. Who is on your team? What responsibilties do they usually fulfill? How do they behave when they're interacting with different stakeholders?
    • Instead of introducing solutions and trying to find their problems, observe the problems and then fix them. If there are any technical/process gaps you've observed during your onboarding that you have the exact experience at that moment to efficiently fill them in, look to fill them. If the team has a problem with writing tests efficiently and you have experiences with a framework that solves that problem, introduce it. If your teammates have a hard time chasing xfn threads, own driving some xfn discussions into clear action items or outcomes. As a senior eng, I will say this is most important thing that makes or breaks if you're perceived as a senior eng/lead: it's very easy to tell the difference between a junior/mid-level engineer who's trying way too hard and thrashing around and a senior engineer who's passively identifying and resolving issues they encounter.
  • 2
    Profile picture
    Android Engineer @ Robinhood
    8 months ago

    As for your concerns about your growth and your career: thess is an opportunity you're clearly excited about, there's a comp increase, and the company is able to hire tenured talent from other notable tech companies. Just take the job: what determines your career growth is less about the companies you work for, and more about the behaviors and fundamentals you develop throughout your career. If you want to make sure you'll have the support needed in the new company, work with your manager to have a clear growth plan and maybe even find a mentor who's willing to take you on.

  • 1
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    8 months ago

    However, I'm slightly concerned if the lack of co-operation from other org and lack of documentation, and the fact that the entire org is being setup fully freshly could be a concern. What's the best course of action i could take to minimize this risk?

    1. Play a big role onboarding teammates - Become the newbie that rises quickly to the top and starts leading the other newbies. In hyper-growth orgs, you should get a lot of credit for this. I wrote an extremely in-depth explainer detailing this here: "How do you deal with the explosion of features and ensure that the knowledge is widely distributed/discoverable by the team?"
    2. Strive to claim credit for your work - Share weekly project updates and demos. In a chaotic org, visibility is key. To learn more, check this out: "How can I get my work better recognized by leadership?"
    3. Work with your manager to craft a growth plan - Of course, do this with the understanding that it will be super rough as things change super fast in a hyper-growth org. This is our crown jewel for this topic: [Masterclass] How To Navigate Your Performance Review In Tech
  • 1
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    8 months ago

    Second, one would view moving out from FAANG to a not well known company as a downgrade, would this still hold true if the problem space and opportunities in the new company is more complex?

    FAANG is never automatically an upgrade or a downgrade. There are so many terrible teams within FAANG. And there's so many amazing teams outside of FAANG.

    At the end of the day, your company's name brand, doesn't put food on the table: Money does. It seems like you're working in an exciting, hyper-growth organization with higher TC, so your new offer seems like an upgrade from FAANG. Congrats!

    Also, the important thing about FAANG is the "first touch". Once you have FAANG on your resume, you will reap the benefits of it going forward. People aren't going to look down on you for switching out of it - They're almost certainly going to assume that you're still a very talented engineer who decided to change career direction.

    In fact, most engineers eventually leave FAANG, generally within 3-5 years. I think your situation makes a lot of sense as you're an Amazon SDE 2, and that level is notorious for trapping engineers. We talk more about this here: "When does it make sense to leave big tech?"

  • 1
    Profile picture
    Mid-Level Software Engineer [SDE 2] [OP]
    Amazon
    8 months ago

    Thanks a lot for the responses, Jonathan & Alex.