Measuring junior onboarding by the first incident, not the first commit

A narrow dirt trail climbs through dry golden grass and desert shrubs toward a ridge under a clear blue sky.

Time to first commit used to be a fair onboarding signal. With AI coding tools in the loop, I think it has stopped measuring the thing that matters. An engineering leader writing on LeadDev describes what six months of mandatory AI coding tools did to her junior engineers: velocity and cycle time improved, yet they could not explain the services they had shipped features against.

Her fix combined four practices: learning tasks attempted without AI first, weekly decision walks, a codebase read, and debugging practice. The idea I would take first is none of those. It is her new finish line. Onboarding ends when a junior engineer can work through a production incident alone, not when they ship a feature. By that measure, her team went from seven months to four.

I suspect most teams have never measured that at all. A dashboard counting merged pull requests will keep reporting success right up to the outage nobody knows how to debug.

In fifteen years around front-end teams, I have come to believe that what you measure in someone's first months becomes what they think the job is. If the number is commits, they learn to produce commits.

What is the first thing a new engineer has to do alone before your team considers them onboarded?

Photo source: https://photos.robertstowe.com/coronado-national-memorial