Pre-Onboarding (Before Day 1)

• Gather Available Info:
  • Research the company’s products, customer value propositions, and any public documentation.
  • Review the team’s online presence (e.g., wiki pages, repositories, internal tools) if accessible.
• Set Up Your Note System:
  • Choose your preferred tool (e.g., Logseq, Markdown files, a digital journal) to keep daily notes and observations.
• Prepare Mentally:
  • Remind yourself of the “Chesterton’s Fence” principle—resist the urge to fix things until you understand why they are the way they are.
  • Adopt a mindset of curiosity and humility.

Day 1: Getting Started

• Establish Your Workspace:
  • Set up your workstation and local development environment.
  • If onboarding documentation is lacking, note every step to later propose improvements.
• Initial Introductions:
  • Meet your immediate teammates (even brief hello’s count).
  • Identify key contacts (your manager, team leads, and any designated onboarding buddies).
• Learn the Landscape:
  • Browse existing documentation, code repositories, and internal tools.
  • Get a rough sense of the project’s history (even using tools like Gource, if appropriate).

Week 1: Laying the Foundation

• Meet with Your Manager:
  • Discuss Goals: Ask about the 90-day and 1-year plans for the team.
  • Clarify Role Expectations: Understand what success looks like for you in this role.
• Schedule Introductory 1:1s:
  • Team Members & Peers: Learn what each person is working on, their pain points, and what they appreciate about the current processes.
  • Non-Technical Stakeholders: Set up brief meetings with people in sales, product, support, or design to grasp the “why” behind the product.
• Begin Active Listening:
  • Focus on absorbing how the team currently works and why certain processes exist.
  • Avoid suggesting major changes or new technologies until you have full context (a good rule is to wait at least 90 days before proposing significant rewrites or process overhauls).
• Take and Organize Notes:
  • Document your observations in daily entries or a weekly folder structure.
  • Note who does what, why certain decisions were made, and any areas that seem unclear.
• Small Contributions:
  • Identify low-risk tasks (e.g., fixing minor bugs or updating docs) to familiarize yourself with the codebase and development process.
  • If you make a “token” commit (even if it’s just documentation), ensure it demonstrates your ability to deliver without being overly showy.

Weeks 2–4: Deepening Your Understanding

• Expand Your 1:1s:
  • Dive Deeper: Ask colleagues what they believe is the single most important thing you should know.
  • Focus on Work Processes: Keep conversations work-centric—learn about project histories, challenges, and existing practices without prying into overly personal areas.
• Map the System & Processes:
  • Review architectural documents and read code to build a mental map of the system.
  • Consider visualizing the code history if it helps understand the evolution of the project.
• Document Your Learnings:
  • Continue updating your notes with insights from meetings and observations.
  • Start drafting improvements for onboarding docs if you notice gaps.
• Observe Team Dynamics:
  • Identify informal influencers and learn the “pecking order” beyond the org chart.
  • Be careful not to challenge legacy processes prematurely; ask “why” before suggesting alternatives.
• Engage Publicly:
  • When asking questions, consider using public channels (like team Slack) so that others can learn from your queries.
  • Avoid coming off as overly critical or arrogant—curiosity and a genuine desire to understand are key.

First 90 Days and Beyond: Earning Impact

• Reassess and Prioritize:
  • Review your notes and identify where your expertise can add strategic value.
  • Gradually propose improvements—but first, ensure you have the buy-in from key stakeholders.
• Build Cross-Functional Relationships:
  • Schedule follow-up meetings with non-developer peers (e.g., product managers, customer support) to understand broader business needs.
  • Use these relationships to help bridge the gap between technical execution and business objectives.
• Share Your Insights:
  • If appropriate, publish internal blog posts or summaries of what you’ve learned to help shape team practices.
  • Consider contributing to the evolution of onboarding documentation so that future hires benefit.
• Focus on Long-Term Goals:
  • Stay aligned with the manager’s vision and the company’s strategic objectives.
  • Demonstrate your ability not just to deliver code, but also to understand and contribute to the business strategy.
• Keep Listening:
  • Continue to listen more than you speak, especially in meetings.
  • Earn trust by asking thoughtful questions and by being collaborative in proposing changes.

Additional Considerations

• Respect the Past:
  • Acknowledge that legacy systems exist for reasons. Don’t dismiss “legacy code” as inherently bad; instead, learn its history.
• Stay Humble & Patient:
  • Even if you have deep expertise, recognize that each organization has its own nuances.
  • Avoid being the “new senior guy” who immediately suggests radical changes.
• Balance Visibility with Caution:
  • While it’s important to be visible (through demos or early contributions), ensure that you build credibility by fully understanding the context first.