Over the past four years of my career, I have worked with multiple early and middle stage startups and all of them wanted to move at a tremendous speed.
There will be high expectations from your manager. They may want you to move efficiently, understand things precisely, and ship that feature quickly.
As a new hire, you might find it difficult to hit the ground running on Day 1 or even after 2 weeks of sinking your teeth into the codebase, infra setup, CI/CD pipelines etc. Many times, this problem is exacerbated due to lack of proper onboarding, mismatch of timezones, poor documentation, etc.
You will, slowly but surely, painstakingly find out how one infrastructure component goes with the other by trying and failing. You will take time to understand how authentication among microservices work. If you are changing project domains (going from backend to mobile apps), it will be even harder.
To avoid bad feedback or perception, you need to set expectations. Make sure that your manager and other stakeholders know:
- If you have switched domains, let them know that you are new to this tech stack and are adapting to it on the job.
- There is no documentation on local setup, staging or prod deployment. This will slow down your work.
- If there is a lack of knowledge sharing between people, point this out. You need the knowledge and support from existing engineers to succeed in your job in the estimated task deadline.
- Pad your timeline expectations with extra time. You don’t know the codebase so you will hit into a lot of unknown variables. Make sure that your manager knows that you have accounted for some extra time if they ask “Why will this take so long?”
If you work in isolation and try to be a hero, you will fail or your work will considerably get delayed. Seek help from team members and communicate the expectations.
If you want to adapt quickly, you will need to put in some extra hours to get up to speed. Try and fail. That’s the only option.
Pro Tip: As you discover steps to do different things, make sure to document these in a README or Confluence or wherever. This will help future engineers!