From Onboarding to Onwarding

Most companies are pretty good at the first twelve weeks of onboarding. There's a plan, there are check-ins, someone's assigned to help. The new hire has a buddy, a mentor, maybe a Slack channel full of folks telling them to ask questions anytime. After a while, that all quietly goes away. Nobody announces that support is over. The structured check-ins just taper off. The buddy moves on to other things. The assumption, usually unspoken, is that if something was going to go wrong, it would have surfaced by now. In my experience, that assumption is wrong a lot. Survival vs. effectiveness The first few months are about survival. Can this person set up their environment? Do they understand the basics of how the team works? Most onboarding programs answer those questions reasonably well. But survival and effectiveness are different things. Once formal onboarding winds down, a different set of challenges shows up. The new hire starts hitting problems that require deeper context. They need to understand not just how the codebase works, but why it works that way. They're navigating relationships they're only now becoming aware of. And they're trying to close the gap between "I technically have access to everything" and "I actually know how to be effective here." That gap is where folks get stuck. And it shows up right around when most organizations stop checking in. The data gap What surprised me when I started looking at this was how little visibility most teams have after the initial onboarding period. No structured check-ins, and no real way to tell the difference between "this person is growing" and "this person is stuck but hasn't said anything." We just assumed that if things looked fine at week twelve, they'd stay fine. The industry average for time-to-productivity is around five and a half months. So most new hires are hitting their stride right around the time all the support infrastructure has been taken away. The timing is rough. What I keep seeing A few patterns show up in that post-onboarding gap: Silent struggling. The new hire is stuck but doesn't feel comfortable raising it because "onboarding is over" and they think they should be self-sufficient by now. They spend weeks circling a problem that a single conversation would have resolved. Lead assumptions. The lead assumes the new hire is fine because they were fine at the twelve-week mark. When performance issues surface at month six, they feel sudden, but they've usually been building quietly for weeks. Early work doesn't test later skills. Early tasks are intentionally simple, which is good. But it means the new hire's first three months don't prepare them for the harder work ahead. The real challenges arrive after the scaffolding is gone. Re-onboarding without a net. When someone moves to a new area of the codebase or takes on a different type of work, they're essentially onboarding again. But there's no structure for it. When I came back from extended leave, I ended up writing my own 30/60/90 plan because nothing existed. I had the seniority to give myself permission to spend the first month just learning (which, for the record, still felt a little indulgent). A newer engineer making their first internal move probably wouldn't feel comfortable doing that, even though it would help. What I think should happen I don't think the answer is extending formal onboarding. Twelve weeks of structured support is reasonable. What's missing is the bridge between "onboarding is over" and "this person is actually integrated." A few things I've found helpful: A six-month growth conversation. Talk to the new hire and their lead separately, then together. The question is "are you on a growth trajectory, or are you still building foundation?" Someone on a growth trajectory needs space and maybe a stretch opportunity. Someone still building foundation needs more support and clearer guidance about what to focus on next. A twelve-month retrospective. Look back on the full arc. What worked, and what would have helped at month six that nobody thought to offer? This creates a feedback loop that makes onboarding better for the next person. Shared artifacts for lead transitions. Leads change (and they will). When they do, the incoming lead shouldn't have to start from scratch. Even simple documentation of where someone is in their journey and what growth areas they've identified makes the handoff smoother. Partnership framing. "What do you need from us?" is a better starting point than "how are you performing?" You're trying to understand what the person needs, not grade them. The hardest part of all of this is earning enough trust that someone will actually tell you when they're stuck. Most folks won't unless they believe the conversation is there to help them. That trust has to be built before it can be useful, which is sort of the whole challenge.