My first day on a production team, I received a ticket described in three words: "Fix user login." No context about which login system, what was broken, or where to start looking. The expectation was clear: figure it out or prove you don’t belong. I managed to complete the work after hours of digging through undocumented code, but the isolation of that experience stayed with me.
Years later, as I built Vets Who Code to help military veterans transition into tech careers, I watched this same pattern play out repeatedly. Veterans would land their first engineering jobs after months of preparation, only to encounter onboarding processes that seemed designed to exclude them. Despite their proven ability to learn complex systems under pressure, they often struggled—not with the technic…
My first day on a production team, I received a ticket described in three words: "Fix user login." No context about which login system, what was broken, or where to start looking. The expectation was clear: figure it out or prove you don’t belong. I managed to complete the work after hours of digging through undocumented code, but the isolation of that experience stayed with me.
Years later, as I built Vets Who Code to help military veterans transition into tech careers, I watched this same pattern play out repeatedly. Veterans would land their first engineering jobs after months of preparation, only to encounter onboarding processes that seemed designed to exclude them. Despite their proven ability to learn complex systems under pressure, they often struggled—not with the technical work, but with navigating unwritten social rules and unstated expectations.
Traditional onboarding rewards people who already have advantages: existing relationships with senior engineers, unlimited time to decode legacy systems, or the cultural confidence to interrupt meetings with questions. Veterans, career changers, working parents, and first-generation professionals pay a hidden tax in stress and eventual attrition because the process wasn’t designed for them.
In this guide, you will learn:
- Why "trial by fire" onboarding systematically excludes underrepresented engineers
- How the "crawl walk run" framework makes learning explicit and paced
- How to design first tickets that build confidence instead of testing worthiness
- Why structured onboarding leads to faster shipping with fewer rollbacks
The hidden cost of sink-or-swim culture
The most talented veterans I’ve mentored—Marines who debugged million-dollar weapons systems, Air Force technicians who maintained satellite communications—often struggled most with their first tech jobs. Not because they lacked technical skills, but because they lacked the social capital to navigate unwritten rules.
Traditional onboarding assumes new hires have three luxuries: unlimited time to figure things out, existing relationships with senior engineers, and the confidence to ask "stupid" questions. Working parents don’t have evenings to decode legacy codebases. Career changers don’t have college roommates who now work at the company. Immigrants and first-generation professionals often lack the cultural fluency to interrupt meetings with clarifying questions.
The result: companies lose diverse talent and mistake systemic failure for individual weakness.
The "Crawl-Walk-Run" alternative
The solution isn’t lowering standards—it’s making learning explicit. I call this approach "Crawl-Walk-Run," and it transforms onboarding from a hazing ritual into a performance multiplier.
Crawl: Build confidence with structured first wins
A newcomer’s first ticket should feel like a guided workshop, not a treasure hunt. I design crawl tasks with four non-negotiable elements:
- A short explanation of why the change matters to users or the business.
- Pointers to every file they will touch, with line numbers when possible.
- A sample commit message that models our conventions.
- A link to a previous pull request that shows the expected structure.
One veteran’s first ticket was adding a single test case—I provided the exact file location, the function to test, and an example of our testing patterns. Another updated our README with clear instructions on formatting and tone. A former Marine told me that completing his first pull request felt like "finally being welcomed to the team instead of having to prove I belonged there." That psychological shift—from outsider seeking permission to insider contributing value—happens within days, not months.
Walk: Layer complexity with clear guardrails
Walk tasks introduce exactly one new concept: a small refactor that teaches your architectural patterns, a feature flag that demonstrates your deployment process, or a database migration that reveals your schema conventions. Each assignment builds on previous knowledge while expanding the contributor’s map of the codebase.
Resist the temptation to assign "real" work too early. I’ve seen managers hand career changers complex tickets to prove they’re not "coddling" them, only to watch those engineers struggle in isolation rather than ask for help. Walk tasks should feel challenging but achievable, with clear success criteria and defined scope.
Run: Enable autonomous contribution
By the run phase, contributors design their own solutions, break epics into manageable tickets, and mentor newer team members. But this autonomy emerges from competence, not desperation. They’ve internalized the team’s patterns through guided practice, not trial and error.
The change in their questions tells the story: instead of asking "What should I work on next?" they start proposing "I noticed this performance issue in the deployment pipeline—should I create a ticket to optimize it?"
The business case for equity
Structured onboarding isn’t charity—it’s performance optimization. Veterans who go through crawl-walk-run contribute meaningful features within weeks and reach full productivity within two months. Sink-or-swim often means six months of floundering before new hires find their footing—if they stay at all.
From individual inclusion to systemic change
One Air Force veteran from our program joined an aerospace startup that implemented structured onboarding after hiring him. Within six months, he was leading their deployment infrastructure and had convinced them to hire three more veterans. Another graduate landed at a fintech company where his first manager took time to explain not just what to build, but why it mattered to their business model. He’s now a senior engineer there and actively mentors new hires.
These outcomes compound. Over 300 veterans have gone through Vets Who Code, and many now lead engineering teams at Microsoft, Amazon, and dozens of startups. They consistently hire other veterans, creating a network effect that strengthens the entire ecosystem. The veterans who succeed become the strongest advocates for inclusive practices—designing hiring processes that welcome career changers, mentoring new graduates, building teams that value diverse perspectives.
This is how culture changes: one onboarding experience at a time.
Before your next hire starts, rewrite their first ticket with complete context. Assign a buddy who remembers what it felt like to be new. Track leading indicators—how quickly they ask clarifying questions, when they propose their first improvement. These behaviors predict long-term success better than lines of code or tickets closed.
Your industry needs the problem-solving skills of veterans, the perspective of working parents, and the resilience of career changers. Design their first ticket like you’re teaching a workshop, not administering a test. Watch confidence become velocity, and inclusion become innovation.
Support Vets Who Code
If this story resonates with you, consider supporting Vets Who Code to help more veterans transition into successful tech careers. Your donations can make a significant impact. You can also sponsor us on GitHub to get technical updates and support our mission. Together, we can make a difference.