Your first 100 days in a new role will set the precedence for all the subsequent days. It’ll define how your team sees you and what they expect from you and see you as capable of. First impressions and all that. I’m approaching it from the angle of software engineering. However, some of the items are applicable to other roles.
Note that I’m counting working-days rather; so the first 100 days amounts to 20 work-weeks, or roughly 5 work-months.
Month 1: Understand
Meet people
Meet everyone on your team including your manager and (if culturally appropriate) your skip manager (manager’s manager). Also meet anyone else you expect to work with regularly. This includes people in product, sales, design, etc. Find the format that works best for you. My go-to’s are pair programming sessions, one-on-one’s, and group lunches.
Set up recurring one-on-ones with
- Your manager
- Your skip-manager (if that’s the culture)
- Your team lead (if that’s the culture)
- (If you’re remote) Set up times to “get coffee” or otherwise just chat over a video call with your peers
Understand the business
- What problem does your team solve? And why is that problem important to the company?
- Get a high-level understanding of the industry and your company’s place in it
Understand your team’s current and near-future focus
- Does your team have a project/feature roadmap?
Learn the organization chart in your immediate area
- What are your neighboring team’s responsibilities?
- Is your team a part of some larger team?
Set up your computer and local development environment
Understand the technical stack
The scope and depth of this task depends on the scope of your role and your level. A backend engineer needs to know a lot about the backend but should also know something about what their backend serves. A front-end engineer should know a lot about the front-end but should also know something about the backend(s) on which the front-end depends. Senior or staff+ engineers should understand the entire thing as their work will necessarily cross domains and be improved by a wider understanding.
You don’t know it unless you can explain it (Feynman technique). Be able to draw and explain the system diagram; not just the what but also the whys and the why-nots.
Be able to relate the system diagram to concrete locations in code.
Learn the processes
- How does a new feature or project go from idea to fully landed?
- Code review
- Local development / debugging
- Pushing to production / roll-out / deployment
- Experiments / AB testing
Where does code and documentation (if any) live?
Work on small bugs/tickets to get hands-on experience
People
- How does your manager like to interact with their reports? Management style?
Business
- Understand the type(s) of customers the company targets