Onboarding: 40+ days to hours

The measure is simple: the time between an engineer's hire date and their first commit. Before the platform it was 40+ days, and almost none of that was learning the codebase. It was laptop imaging, then software access, data entitlements and role-based access groups, each its own request with its own approver, and each one discoverable only by already knowing it existed. The groups, the software and the permutations of both differed by team, and nothing listed them. A new engineer found out what they were missing when it blocked them, or when someone who had done it before thought to mention it.

The same days were paid again on every contractor start and every transfer between teams, because the setup lived in people rather than in anything a machine could replay. And because no one team owned the path from hire date to first commit, no one team saw the whole number.

The number did reach someone. The 40+ day figure came up in a monthly operating review, and the CEO took it as something to drive down. That became a CEO-sponsored initiative with a stated goal of an engineer being productive on their first day, and the developer platform, ATLAS, became the way the platform team delivers on it. The baseline is 40+ days. The first-day goal is a target, and it is written here as one.

A new engineer's laptop arrives with the CLI and the desktop agent already on it, as part of the standard developer software package. So does the core access an engineer needs on day one: GitHub, Copilot and the Nexus registry are provisioned out of the box, along with the software most engineers use every day, so the requests that used to open the first week are not filed at all.

The design rule for what follows was that onboarding never leaves the browser until it has to. The engineer opens the platform's site and starts a walkthrough. The first one sets up the machine with the CLI, in a terminal embedded in the page, so they are watching real commands run on their own laptop without having to know them yet. The desktop agent is what connects the two: a button on the site runs a native command on the machine. The second walkthrough opens a chat window on the site that talks to Copilot through the CLI on the engineer's own machine, by way of that agent, so AI help is part of day one rather than something to set up later. The third opens VS Code, installs the platform extension and walks through the parts of the editor that matter on the first day. Beginner and advanced CLI walkthroughs follow.

From there the engineer installs what the company has already vetted from a catalog of 120+ skills, 10+ MCP servers and 10+ agents, and builds their first project with one command that builds any project the same way on every laptop. Which tool versions and which scans run is decided by policy in configuration, so a new engineer never has to get that right by hand.

Not everything. Some access still needs the engineer to submit a request, and some still needs an approval on the other side. What changed is the default: the core is there on day one, and what remains is a request rather than a scavenger hunt.

The walkthroughs replace the wiki page that was right when it was written, because they are the setup, not a description of it, and when the setup changes the walkthrough changes with it. The catalog replaces the chat thread, because what is vetted is listed in one place. Policy as configuration replaces the colleague who knew which version, because the platform knows.

The walkthroughs were refined and certified by the platform's team in India, who went through them as a new engineer would and sent back what did not hold up. That is the part I would not skip: a walkthrough written by the people who built the platform is only correct for the people who built the platform until someone else has run it.

New hires, contractors and internal transfers take the same path. It has also turned out to be useful to engineers who were never new: experienced developers running the tool against their own applications have found stale repositories and pipelines they did not know they still had.

The initiative is judged on hire date to first commit. The hours figure is not that number: it is what the platform path delivers on a single machine, from unboxed to building. The enterprise KPI is a cumulative average over every engineer hired since the measurement began, whichever path they took, so by construction it moves slowly and has not yet caught up with the change. The number that will show the shift is the most recent cohort's, and the platform team expects it to. That figure is not in yet, so it is not here.

What is not claimed: the first-day goal, which is the initiative's target; any figure for the full 8,000-engineer organization, which the rollout is heading toward and has not reached; and any reduction in support tickets, which is not instrumented directly. Where a number does not exist yet, this page says so.

The platform team's own organization went first, as the pilot, and the enterprise followed. The unified surface of CLI, desktop app and IDE extensions reached 1,000+ active engineers in its first 90 days. The desktop agent reached the same number in a day, because it shipped to everyone who already had the CLI. Today the CLI is in use on 4,000+ machines and the agent on 2,000+ devices. The pilot that is still running is adoption itself: making this the standard day-one path for every team, not just the ones that chose it early.

The AI engineering team is now writing new walkthroughs for enterprise AI tools, such as the AWS and Jenkins MCP servers, as each is onboarded. The same engine that gets a new engineer to their first commit gets an existing engineer to their first use of a new tool.

I am the platform's tech lead. My manager acts as its technical product owner and still ships the first version of a feature himself at times. The desktop app was mine to design and build, and so was the idea it carries: a guided workflow that takes an engineer through setup instead of describing it, and a bridge between the browser and the CLI, so that one front end can carry everything the platform adds later, software delivery and DevOps intelligence included. I built the platform's UI, and I did a large share of the architecture and development of the event-bus ingestion pipeline behind its telemetry. The one-command build system was my manager's work; my part there was learning it and bringing the team along.

Define productive before you measure it. Hire date to first commit is a number anyone can check and no one can argue with. "Set up" is neither.

Make the first day a product. Onboarding was slow because it was nobody's product; it got fast when it got an owner, a surface and telemetry.

Stay in the browser until you cannot. An embedded terminal and a desktop agent let the engineer watch their own machine get set up without first learning how to do it.

Have someone who was not in the room run every walkthrough before it ships. The India team's certification pass is why the walkthroughs survive first contact with a real new hire.

Keep the target separate from the result, and say which number you are quoting. Hours on a machine and a cumulative enterprise average are different measures, and a reader who is handed one as the other will not trust either.