Understanding the Role and First 90-Day Plans Questions

Situation: As a buddy for a new software engineer during their first month, my goal is to accelerate ramp-up while leaving the new hire ownership and clear escalation paths.

Practical responsibilities and actions:

• Scheduled check-ins:
  • Day 1 quick sync (90 min): orientation, dev environment, team norms.
  • Twice-weekly 30-min check-ins for weeks 1–2, then weekly for weeks 3–4; adjust frequency to their comfort.
  • Ad-hoc availability window (e.g., 30–60 minutes daily for week 1) for quick questions.
• Codebase walkthrough:
  • Guided tour of repo layout, key services, CI/CD, and local run/debug steps.
  • Pair on running the app and stepping through a simple request end-to-end.
  • Share high-value docs: architecture diagrams, README, style guides.
• Early PR support:
  • Help pick a small first ticket; pair-program and open the first PR together.
  • Review early PRs promptly and provide constructive, actionable feedback (focus on learning, not nitpicks).
• Introductions and context:
  • Introduce them to PM, designers, QA, and owners of adjacent services.
  • Point out recurring meetings, Slack channels, and stakeholders.
• Boundaries & time commitment:
  • Commit ~4–6 hours/week first two weeks, tapering to ~1–2 hours/week by month end.
  • Make availability clear in calendar; encourage asynchronous questions.
• Escalation:
  • If issues exceed scope (policy, blockers, performance), escalate to the manager or tech lead and loop the new hire in.

Result: This approach balances hands-on support, targeted teaching moments, and clear limits so the new hire gains autonomy quickly while knowing where to get help.

Structure the first 6 months as a progressive, intentional rhythm: weekly 1:1s for months 0–3, biweekly for months 4–6, plus formal checkpoints at 30, 90, and 180 days. Pair the hire with a mentor from day 1 and schedule weekly mentor syncs for the first 90 days.

Cadence and checkpoints:

• Weeklies (0–12 weeks): coaching, blockers, onboarding tasks, code reviews
• 30-day checkpoint (manager + mentor): onboarding status, knowledge gaps, short-term goals
• 90-day checkpoint (manager + mentor): performance vs. expectations, ownership of small feature, feedback summary, adjust development plan
• Biweeklies (months 4–6): growth coaching, stretch assignments
• 180-day review (manager + HR optional): promotion/readiness discussion, long-term plan

1:1 template (20–30 min):

• Wins: What went well this week? (2 min)
• Blockers: Any impediments? What do you need from me? (5 min)
• Learning: What did you learn? Where do you need practice? (5 min)
• Work alignment: What are you working on next? Do priorities make sense? (5 min)
• Career & wellbeing: How are you feeling about growth, workload, team fit? (3 min)

When to involve mentor vs HR:

• Mentor: technical ramp, code-review guidance, pairing, team norms, growth recommendations (always early)
• Manager: performance concerns, repeated missed expectations, roadmap/role clarity, career development conversations
• HR: serious conduct issues, accommodations/medical needs, legal or policy violations, formal performance improvement plans (PIP), or if hiring/role changes require paperwork

Success signals: writing clean PRs with minimal guidance, owning end-to-end tasks, positive peer feedback, meeting 90/180 goals. Use concrete goals and evidence at each checkpoint; document feedback and action items.

Situation: In my first month on a new team I want to ramp quickly without blocking others' work while building good habits and codebase knowledge.

Preference (frequency & channels):

• PR comments: Primary channel for substantive feedback. I prefer at least one focused review per PR within 24–48 hours so I can iterate. Use clear inline comments for specific lines and a summary comment at top with the overall judgment (approve, minor changes, request changes) and key areas to address.
• Chat (Slack/MS Teams): For quick clarifications or small suggestions that would otherwise bloat the PR thread. Use chat when a question can be resolved in <15 minutes.
• Pairing: I welcome short pairing sessions (30–60 min) for architectural decisions, unfamiliar codepaths, or recurring review items so I can learn patterns and ask real-time questions.

Level of detail & tone:

• Actionable and educative: Prefer comments that explain the why and include examples (suggested code snippets or links to style docs). E.g., “Instead of mutating X here, return a new object — this keeps reducers pure. Example: [code].”
• Prioritized: Mark which items are blocking vs optional improvements.
• Respectful and constructive: Use curious, collaborative language (“I’m wondering if…”, “Could we consider…”) not prescriptive or dismissive phrasing.
• Highlight positives: Call out things done well to reinforce good behavior.

Examples:

• Blocking: “This function can throw when input is null — please add validation or a test. See failing scenario: …”
• Non-blocking: “Nit: rename var for clarity; consider extracting helper for reuse.”
• Teaching: “We prefer async/await across service layer — here’s a one-line rewrite and link to our pattern doc.”

Result: This mix keeps me unblocked, accelerates learning, and helps integrate me into team conventions quickly while maintaining code quality.

Core training resources and short comparison:

• Internal workshops (brown-bags, tech talks): Low cost, high relevance (company codebase/process), good ramp impact for common tasks, scalable via recordings.
• Online course subscriptions (Coursera, Pluralsight, O’Reilly): Moderate cost per seat, broad topic coverage, asynchronous—scalable but less tailored.
• Mentorship / pairing: Very high impact on learning and culture, low monetary cost but high time cost and limited scalability per mentor.
• Conference budgets: High cost per person, great for exposure and networking, lower direct ramp-to-productivity.
• Rotational programs (team rotations, internships): Medium cost/time, excellent for breadth and systems understanding, harder to scale quickly.
• Certifications/bootcamps: Variable cost, isoled skills, good for structured learning but may not map to product needs.

Top 3 to prioritize for a junior engineer (considering cost, ramp impact, scalability):

1. Mentorship/pair programming — highest ramp impact; personalized feedback accelerates real-world skills. Time investment scales via formal mentor ratios and office hours.
2. Internal workshops + recorded sessions — low cost, directly aligned to codebase/process; immediate applicability and reusable for many hires.
3. Online course subscriptions — fills gaps (algorithms, testing, cloud) asynchronously; scalable and measurable via learning paths and assessments.

This mix balances immediate productivity (mentoring + tailored workshops) with scalable, cost-effective long-term skill growth (subscriptions).

Situation: In a six-month cross-team retrospective I ran, we discovered onboarding varied widely across teams, causing uneven ramp times and new-hire frustration.

Task: I needed to propose a solution to standardize core onboarding so new engineers ramp consistently, while letting teams keep role-specific practices.

Action:

• Defined scope: core onboarding (company culture, infra access, CI/CD, coding standards, testing, observability, security basics) vs team-specific modules (domain knowledge, stack details, sprint rituals).
• Governance: formed a lightweight Onboarding Council (one eng rep from each team, HR/People Ops, and an onboarding champion). Council meets biweekly for maintenance and quarterly for strategic changes. Ownership: People Ops owns sequence/timing; eng reps own technical content.
• Templates & artifacts: created a Core Onboarding Checklist, 30-60-90 day goals template, buddy/mentor guide, and a Team Module template (learning objectives, required tasks, key docs, sandbox links).
• Automation: automated access provisioning via IaC scripts (Terraform/Ansible) triggered by HR new-hire event, created a self-serve "new hire" Confluence page with checklists and embedded runbooks, and a tracked Trello/Jira onboarding board with automated reminders and progress metrics.
• Rollout plan: pilot with two teams for 4 weeks; collect feedback (surveys + time-to-first-PR metric); iterate one sprint; expand to remaining teams over two months. Train team reps in a 1-hour workshop and provide a migration plan for existing hires.
• Metrics & feedback: track time-to-first-PR, time-to-pass-probation checklist, new-hire NPS, and monthly compliance on core checklist. Council reviews metrics and retrospectives to improve.

Result: Expected outcomes: reduced average ramp time, higher new-hire satisfaction, and predictable baseline knowledge across teams while preserving team autonomy.