Skip to content

Discover Journey Map: Workbench Developer Onboarding

Scenario

Workbench is an internal developer-experience platform. The platform team wants a journey map of the new-engineer onboarding experience to decide where to invest dev-experience effort. The persona is a newly hired engineer; the journey runs from offer acceptance to independent feature ownership. Grounded in a new-hire onboarding survey (n=22 engineers hired in the last two quarters) and 5 follow-up interviews [fictional]. The decisive moment of truth is the first merged pull request: it is the moment a new engineer feels both technically competent and psychologically safe. All figures and quotes are illustrative and tagged [fictional].

Source Notes:

  • Chip Heath and Dan Heath, “The Power of Moments” (Simon and Schuster, 2017) - the “first merged PR” is treated as an engineered peak moment; the Heaths’ point that organizations should deliberately create defining moments rather than leave them to chance drives the recommendations.
  • Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler, “DevEx: What Actually Drives Productivity” (ACM Queue, 2023) - the three dimensions of developer experience (feedback loops, cognitive load, flow state) frame the pain-point analysis, especially the cognitive-load cost of environment setup.
  • Kate Kaplan, “Journey Mapping 101” (Nielsen Norman Group, nngroup.com) - the journey-map anatomy (stages, touchpoints, emotional curve, opportunities), applied here to an internal-employee journey rather than a customer one.

Prompt

/journey-map
map the new-engineer onboarding journey so we can decide where to invest
dev-experience effort. persona is a newly hired software engineer.
stages: pre-day-1 (offer accepted, paperwork) -> day-1 (laptop + accounts)
-> week-1 (orientation + exploring the codebase) -> month-1 (first PR
merged) -> month-3 (owns a feature independently).
we have an onboarding survey (n=22 recent hires) + 5 interviews. the
recurring theme is tooling/access friction: env setup takes days, access
requests bounce around, docs are stale. the high point everyone remembers
is their first merged PR.
linear journey. include a mermaid timeline. recommendations should be
dev-experience investments.

Output

Customer Journey Map: New Engineer Onboarding - “From Offer to Ownership”

Executive Summary

This map covers a newly hired engineer from offer acceptance to independent feature ownership (roughly a 3-month arc). It is grounded in an onboarding survey (n=22) and 5 interviews [fictional]. The dominant pain pattern is tooling and access friction: environment setup, account provisioning, and stale documentation consume the first week and depress early confidence. The decisive moment of truth is the first merged pull request - the survey shows engineers who merged a PR in week 1 reported markedly higher confidence at day 30 than those who took three weeks [fictional]. The largest opportunity is compressing time-to-first-PR by fixing the environment-setup and access bottlenecks that block it.

Persona / Segment

Newly hired software engineer, mid-level, joining an existing team. Competent and motivated but unfamiliar with the company’s tooling, codebase, and conventions. Anxious to prove themselves and reluctant to ask “obvious” questions in the first weeks. Wants to ship something real quickly to feel like a contributor rather than a cost. This matches the “New Contributor” persona from the foundation-persona artifact.

Journey Scope

  • Journey type: Linear
  • Included: Offer acceptance through first independent feature ownership (roughly day -7 to day 90)
  • Excluded: Recruiting and interview experience (upstream), long-term career growth and promotion (downstream)

Stages

#StageEngineer goalDurationEntry triggerExit criterion
1Pre-day-1Arrive ready, not anxious~1 weekOffer acceptedFirst day begins
2Day-1Get set up and feel welcomed1 dayStartsCan log in and access core systems
3Week-1Understand the codebase and team1 weekAccounts provisionedEnvironment runs locally; first task picked up
4Month-1Ship a first real change~4 weeksFirst task assignedFirst PR merged
5Month-3Own a feature without hand-holding~8 weeksTrusted with a featureShips a feature independently

Touchpoints per Stage

StageTouchpointChannelWhat happens
Pre-day-1Welcome email + pre-boarding checklistEmailReceives logistics, sometimes hardware ships
Day-1Laptop setup + IT provisioningWorkbench / ITInstalls tooling, requests accounts
Day-1Team intro + buddy assignmentMeeting, chatMeets the team, gets a buddy
Week-1Local environment setupWorkbench, docsTries to build and run the app locally
Week-1Access requests (repos, secrets, staging)TicketingRequests permissions, waits for approvals
Week-1Codebase + onboarding docsWiki, repoReads docs of varying freshness
Month-1First task + code reviewWorkbench, PR toolOpens a PR, gets review feedback
Month-1First merged PRPR tool, CI/CDChange ships to main / production
Month-3Feature design + ownershipTeam processLeads a feature end to end

Emotional Curve

StageDominant emotionConfidenceSource
Pre-day-1Excited, slightly anxiousMedium5 interviews; mix of eagerness and “will I be ready?” [fictional]
Day-1Welcomed but overwhelmed by setupHighSurvey: setup was the most-cited day-1 friction [fictional]
Week-1Frustration (tooling and access friction)HighSurvey: env setup averaged ~3 days; access waits common [fictional]
Month-1Building confidence, peaking at first mergeHighSurvey: first-PR week correlated with day-30 confidence [fictional]
Month-3Competence, sense of belongingMediumHypothesis from 5 interviews; not broadly measured [fictional]

Pain Points and Moments of Truth

StagePain / Moment of TruthSeverity (1-5)EvidenceImplication
Week-1Environment setup takes days5Survey: ~3 days average to a running local env [fictional]Biggest single drag on time-to-first-PR; high cognitive load (DevEx)
Week-1Access requests bounce around4Survey: multiple hand-offs, multi-day waits [fictional]Blocks work and signals “you’re not trusted yet”
Week-1Stale onboarding docs44 of 5 interviewees hit outdated instructions [fictional]Erodes trust in all docs; new hires stop reading them
Month-1First merged PRMoment of Truth (5)Week-1 mergers far more confident at day 30 [fictional]The defining peak; everything before it should serve getting here fast
Month-1First code review feels harsh32 interviewees felt early reviews were blunt [fictional]Review tone shapes psychological safety at a fragile moment

Opportunities

StageOpportunityDev-experience investmentEffort (rough)
Day-1Eliminate setup toilOne-command / containerized dev environment in Workbench (golden path)Large
Week-1Remove access waitsPre-provision a standard new-engineer access bundle on offer acceptanceMedium
Week-1Stop stale docsA “last verified” date + a one-click “this is wrong” report on each onboarding docSmall
Month-1Engineer the first-PR peakCurate a “good first issue” queue so a new hire can open a real PR in week 1Medium
Month-1Protect psychological safetyA reviewer guideline for first-PR reviews (lead with what works, explain the why)Small

Visual

timeline
title New Engineer Onboarding Journey
Pre-day-1 : Welcome email : Pre-boarding checklist
Day-1 : Laptop setup : Account provisioning : Meet the team
Week-1 : Local env setup : Access requests : Explore codebase
Month-1 : First task : Code review : First PR merged (moment of truth)
Month-3 : Owns a feature independently

Research Gaps

  • The Month-3 belonging emotion is Hypothesis from 5 interviews [fictional]; a 90-day check-in survey would replace it with measured signal.
  • The first-PR-to-confidence correlation is self-reported [fictional]. Instrumenting time-to-first-merged-PR from Workbench and correlating with retention at 6 months would turn the central moment of truth into a hard metric.
  • No signal on contractors or fully-remote hires, whose setup and access friction may differ. A segmented cut of the onboarding survey would test this.