Introduction

You’ve hired a smart developer from a tier-2 college strong fundamentals, eager to learn, and importantly, more cost-effective than a Bangalore-based counterpart. With a structured 30-60-90 Day Onboarding approach, they start contributing meaningfully by month three. By month six, however, they submit their resignation taking with them the knowledge you invested in, the velocity they built, and the momentum your team depended on.

If this feels familiar, you’re not alone. This scenario plays out thousands of times across Indian organizations every year. With tech sector attrition hovering around 25% and e-commerce nearing 29%, the first 90 days of a developer’s journey are no longer just an onboarding phase they are a high-stakes retention battleground.

What makes this different is that the cost of losing a developer isn’t about paying replacement. The bottom line is that when a developer leaves, you lose institutional cognition, lose a 2-3 workweek productivity pickpocket across your team, and restart the expensive leasing cycle. For an inauguration burning cash to scale, this compounds quickly, sacrificing your ability to make your sprightliness easygoing and replacing a single software.

What makes this different is here’s the particular newsworthiness: a structured 30-60-90 day design can reduce this rubbing dramatically. Here’s what you should know: companies with warm programmes see 82 % issuing-edge hire retention rates. This is exactly what you require: an enquiry from early-stage inauguration bands shows the first 90 days specify a developer abides for 18 months or leaves at the 6-month mark.

Why Onboarding breaks in Indian engineering teams

Individual onboarding vs. batch onboarding:

When you bring on 20–200 new employees at once, you get speed, but not direction. People get lost, stop doing anything, and start talking in other places without being seen.

There is a real skill gap (heavy hiring in tiers 2 and 3):

A lot of new developers don’t know much about practical development processes like Git, debugging, PR, or how to think like a tester. This is not a judgment; it is a design limitation that your plan needs to work with. Concerns about employability and skill mismatch have been raised over and over again in reports and news for non-tier-1 cohorts. IIT Bhubaneswar+1.

The “learning by osmosis” approach was changed to hybrid/remote:

In India’s IT job market, hybrid and remote roles are important enough that training must go smoothly without any help from coworkers. For instance, analyses of job postings have shown a large share of hybrid and remote work in IT tasks.

Stress for holding on is always there:

At a “India Inc.” level, turnover slows down, but tech teams still fight for the same talent pools, and managers are always aware of the risk of churn. It’s not enough to “welcome them warmly.” The goal is to get developers to work quickly, feel confident, and stay linked without getting burned out. The Economic Times+1.

What “good onboarding” means

By Day 90, a well-onboarded developer should be able to:

• Ship production-grade work with minimal handholding.
  
• Explain your system at a high level (components, data flow, risks).
  
• Follow your quality bar (tests, reviews, security, performance basics).
  
• Have a support network (buddy + manager + team).
  
• Feel a future here (growth path + clarity + belonging).

The Onboarding Operating System 

Before we go into 30-60-90, set up these 6 building blocks. This is what makes onboarding scalable for fresher batches and hybrid teams.

A) One owner, one scoreboard

• Owner: Engineering Manager (EM) or Tech Lead
  
• Support: HR + IT + Security + L&D
  
• Scoreboard: 6–10 onboarding KPIs (provided below)
  

B) A “Single Source of Truth” onboarding hub

Use Notion/Confluence/Google Sites, anything, ensure:

• Setup checklist (laptop, VPN, repo access)
  
• Engineering handbook (coding standards, branch strategy)
  
• Architecture 101
  
• Dev environment guide (video + written)
  
• “First 2 weeks” agenda
  
• Team contacts + escalation paths
  

C) Buddy system with real accountability

Buddy isn’t a “nice-to-have.” Buddy is the daily unblocker.

• Buddy = 30 minutes/day for first 2 weeks, then 2–3 check-ins/week till Day 60
  
• Buddy KPI = “unblocked within 24 hours” target
  

D) Role-based onboarding tracks

Make 3 tracks:

• Fresher track (more fundamentals + guided tasks)
  
• Lateral hire track (faster ownership + system deep dive)
  
• Intern-to-FTE track (bridge gaps + production readiness)
  

E) A real “first task” system

New devs should not “read docs for 10 days.”
Give them:

• 2-3 micro tasks (docs, small UI copy, lint fixes)
  
• 1 small bug fix
  
• 1 scoped feature by Day 45-60
  

F) Feedback loops (weekly)

A simple pulse works:

• “What’s unclear?”
  
• “What blocked you this week?”
  
• “What should we improve in onboarding?”
  

Metrics that matter 

Track these weekly for each cohort:

Speed & contribution

• Time to dev environment ready (target: 1–2 days)
  
• Time to first PR merged (target: 7–14 days)
  
• Time to first production release contribution (target: 30–60 days)
  

Quality

• PR rework rate
  
• Test coverage added (where relevant)
  
• Bug rate in first 60 days (trend, not blame)
  

Engagement & retention risk

• Onboarding satisfaction (weekly pulse)
  
• Manager confidence score (weekly)
  
• 90-day retention rate (cohort)
  

Hybrid health

• Of “blocked >24 hours” incidents
  
• Attendance in ceremonies + pairing sessions
  

NASSCOM and business coverage have highlighted attrition and retention levers as central priorities for Indian tech employers. Your onboarding should directly support that. NASSCOM Community+1

Day 1-30: Foundation and First wins

Days 1-3: The Important First Week

The first three days will show you if your new worker likes order or chaos.

Pre-Day-1 Setup (The Step That People Often Miss)

This is where most Indian companies get lost. The worker starts on Monday, but their laptop won’t be ready until Wednesday, after you hire them on Friday.

Don’t keep doing this.

Before your developer starts, make sure:

• The hardware is ready: The laptop is set up, the development environment is loaded, and all of the access credentials work.

• A physical desk (if it’s a hybrid) or help with setting up at home (if it’s remote) is given as a workspace. Send them a welcome package with business swag, a note from the CTO written by hand, and a “first week checklist.”

• Active means of communication: Be sure to add them to your internal wiki, Slack groups, and email lists before the first day. Send a simple welcome message so they can see who’s on the team before they come in.

• Assign a buddy: Find the best senior worker on your team, not just the one who is available the most. Let them know what their job is as a mentor. Pre-boarding cuts down on problems by 80% in the first week.

Day 1: Registration and getting to know each other

The first day isn’t a flood of knowledge. Its presence with form.

Morning:

• 15-minute welcome from the CEO or founder (shows that the company cares)
• An overview of the team structure and current tasks by the engineering lead
• The co-founder or product lead lays out the next 90 days’ worth of product plans.
• A tour of tools (Slack, GitHub, Jira, and your development stack) by IT support

Afternoon:

• Their assigned buddy shows them around the software (either virtually or in person).
• Talk one-on-one with the direct manager about goals, objectives, and preferred ways of working
• Lunch with the team or a casual, low-pressure virtual coffee chat.

Days 2 and 3: Commitment and Mastery of the Environment

For developers, this is the step between “I have access” and “I understand the landscape.”

Day 2:

• During a pair programming session, your partner shows you how to set up the local development environment. The goal is for them to test the app locally and see how it works.
• Deep dive into the documentation: look over the coding standards, deployment processes, code review methods, and any internal libraries that are unique to your stack.
• Along with a different top engineer in the afternoon, you should show them how your team works in various ways.

Day 3:

The first commit of code by the end of the day on day 3: This can’t be changed. It’s not about how complicated it is, but how fast it moves. Change a word in the documentation, add to the readme, or fix a small bug. The goal is to feel like you’ve done something good. They’ve added on the third day.

Why? Because top startups have found that workers who ship code by day three are 60% more likely to stay 18 months or longer. It has a strong effect on the mind. They’re not just watching; they’re taking part.

Four to ten days: Integration Phase

By day four, the worry of the first week has gone away. Now you’re getting better and making links.

Bootcamp for Cohorts in Technology

If you hired a lot of new people, which is usual for Indian startups, hold a one-week technical bootcamp at the same time you’re training each one individually. This cohort-based method:

• Helps new students get to know each other and form networks of support.
• Make sure that all new hires have the same basic information.
• Lessens the workload for top engineers (one bootcamp instead of five separate training sessions).
• Makes a common point of reference for learning and asking questions.

What should the boot camp cover?

• Your tech stack in depth, not just on the surface.
• How to get comments and the rules for code reviews.
• Methods for testing and fixing bugs.
• How code gets to production and your release pipeline.
• Pair of computer rules

Programming Rotations in Pairs

Every day from Day 4 to 10, pair the new developer with a different experienced engineer. Each time you pair up, you should have a goal:

• Day 4: Engineer A teaches codebase design to new employees
• Day 5: Engineer B teaches new employees about the theory and standards of code review
• Day 6: Engineer C shows new employees how to do testing
• Daily 7: A product engineer shows the logic behind a feature that customers see.
• Days 8-10: Explore on your own with check-ins

This movement does a several things, including:

• The new employee sees different ways of writing code and learns what the team values.
• Senior engineers stay up-to-date on hiring best practices (this keeps things from getting old).
• The new worker gets to know everyone on the team.

First Small Change or Addition

By day 8-10, give them a small task that they can do on their own. For example:

• You need to fix a known small bug (tier-2 importance).
• For an established feature, add a test case that isn’t there yet.
• Add missing options to the API documentation.
• Change how a small utility tool works.

The objective is for them to do something on their own, but with a clear list of things to do and a buddy nearby in case they need help. You should be able to make or almost make this by day 10.

Point of Check: Last day of Week 1 (Day 10) 

Manager Review:

• Has the coder sent the code out?
• Do they take part in Slack and team meetings?
• Any technical problems or holes in your knowledge?
• Fit: Do they get along with the rest of the team?

Feedback from developers:

• “How’s your first week?” is a quick way to check in.
• Are there any problems or frustrations?
• Are they sure what their goals are for next week?

Advice from a buddy:

• How ready are they? (1–10)
• What parts need to be strengthened?
• Do they ask good questions or stay quiet?

Days 11–30: Gradual rise in responsibility

Month one’s second and third weeks change the focus from “learn the system” to “start owning outcomes.”

Weeks 2 and 3 Tasks

Assign traits that get more complicated:

• The second week has one small feature (an API endpoint, a UI component, or a database move).
• Week 3: Either one medium-complexity feature or two small features at the same time

Write down clear guidelines for each task’s success:

• The code review goes through on the first or second try.
• The feature goes live without rollbacks.
• 80% of problems are fixed by the developer on their own.
• It is easy to deploy to staging or production.

Culture of Code Review

By week two, five or more code reviews should have been given to the new coder. Make sure that these reviews are used to teach and not to keep people out.

Set a standard for code review:

• Reviews in four hours (async-friendly, especially for tier-2 and tier-3 remote teams).
• Just saying “change this” is never enough. Always include specific ideas.
• Recognize and praise good behavior.
• Reviews can help your team stay true to its ideals (like performance, readability, and testing).

Cadence for Mentorship

Set up a regular pace for one-on-one:

• Days 1-7: Check in with a buddy every day for 15 minutes (you can do this asynchronously through Slack).
• Days 8 through 21: two to three 30-minute meetings a week with boss or buddy
• Days 22-30: Meet with your manager once a week for 45 minutes to talk about your success.

This is not a status talk. They help people have conversations:

• “What’s been the biggest learning curve?”
• “Where do you feel most confident?”
• “What would make your daily work smoother?”
• “Are you building a connection with the team?”

Day 30: First Month Evaluation: 

The developer should do the following:

• Shipped two or three small or medium features on their own.
• Code review score: 80% or more for first pass.
• Completed training in coding standards and testing methods.
• Takes an active role in meetings and team standups.
• Baseline output: about 40 to 50 percent of what a senior engineer does.

What the manager thought:

• Are they technically ready? Can they take full responsibility for a small feature?
• How quickly they are learning: Are they asking good questions, or are they stuck?
• Cultural fit: Can they talk to each other? Work together? Take the lead?
• Warning signs: Are there signs of anger, loneliness, or being out of sync?

Enjoy the first month if they’re on track. Send them a note thanking them for their help. In the second month, take on more responsibility.

If they’re having trouble, step in now. More help from a trainer, new tasks, or more information about what is expected. Don’t let problems get worse.

Day 31-60: Acceleration and Independence 

In the second month, your new developer moves from “learning the system” to “driving outcomes.”

Weeks 5 and 6: Medium-Complexity Features

Assign traits that need to:

• Understanding of the design of a system as a whole, not just its parts.
• Working together across teams (with QA, design, or product).
• Making trade-off choices.
• Thoughts on performance or scalability.

For example:

• Create an API route that works with other services.
• Refactor an old module to make it run faster.
• Take charge of a small movie from planning to production.

What to expect in weeks 5 and 6:

• One medium-level story was finished and sent out.
• There have been at least five code reviews (not just received).
• There were no rollbacks or production problems.
• 60–70% more work done than a senior engineer benchmark.

Weeks 7 and 8: Technical Leadership and Multi-Feature Ownership

By week seven, your developer should be able to work on two projects at the same time. What’s more, they should start coaching.

Elements of technical leadership:

• Lead technical talks about designing features.
• Do your own code review for a junior coder, if you have one.
• Make suggestions for design changes or improvements.
• Find their domain’s technical debt and fix it.

Parallel Feature Management: 

Give two middle features at the same time. One is their main property, and the other is a minor one. This teaches you how to set priorities and switch between tasks, which are important skills for any coder after the first 90 days.

Integration of Culture in Month Two

Your new worker should no longer feel like a hire but like a member of the team. Make this possible by:

Informal Points of Contact:

• Coffee or lunch with more than just their buddy on the team.
• Participation in talks about making team decisions.
• Being invited to team reviews and brainstorming talks.
• When they ship something important, let them know in team channels.

Opportunities to learn:

• Junior engineers will lead tech talks or lunch-and-learns that are optional.
• Being exposed to customer input (such as calls, feature requests, and usage data).
• Taking part in planning the architecture for future sprints.

Managing work and personal life (especially for hybrids):

• Follow their hybrid plan (if you agree to it).
• Skip talks that aren’t necessary and use async communication instead.
• Help them find their rhythm (e.g., early morning coding vs. late afternoon focus).
• Check in on work-life balance, especially for tier-2 developers who are getting used to living in new places.

Taking Care of Signs of Employee Loss in Month Two

Between days 45 and 50, look out for signs that you might be leaving:

Stick with it (green flags):

• Enquiring about chances to learn and advance in their job.
• Taking part in social and team-building events.
• Making suggestions for ideas and changes.
• Getting to know everyone on the team.

Red flags:

• Away from people during standups and quiet.
• Not doing tasks that aren’t given.
• Making a complaint about pay or perks.
• Not sure about their future or how much they want to learn.
• Not part of the team’s socials or culture.

If you notice red flags, be honest: “I’ve noticed you seem a little uninterested.” Is something wrong? What can I do to help?” It’s not always a technology problem; sometimes it’s a personal matter, and sometimes it’s an offer from someone else. Deal with it straight.

Milestone for Day 60: Mid-Point Review 

`The developer should do the following:

• Four to six features were shipped separately (a mix of small and medium).
• In charge of design reviews or technical talks.
• Helped or reviewed code for one to two other coders.
• 70–80% of the senior engineer standard in terms of productivity.
• There were no unexpected rollbacks or production problems.
• Actively contributes to the culture of the team and shares information.

What the manager thought:

• Are they ready to do more difficult work on their own?
• Are there any technical holes or places that need more work?
• Cultural fit: Do they feel like they’re a part of the group?
• How likely is it that they will leave in the next six months?

Talk about renewal:

Have a clear talk about the next step on day 60. This is not a review of your work; it’s a check-in on your partnership:

• “How do you feel about your first two months?”
• “What’s been the biggest surprise, good or bad?”
• “What would make your role more fulfilling?”
• “What are your learning goals for the next 30 days and beyond?”
• “How can I support your growth?”

This conversation stops people from being quietly unhappy. You can find out if someone is looking somewhere else.

Day 61-90:Autonomy and Mastery

In the last month, your new worker has grown into a confident, self-sufficient contributor. They get things done. They work for the team. Now the question is: Will they stay?

Weeks 9 and 10: Complex Feature Leadership: 

Assign someone a big project or feature that needs:

• Making decisions on your own (with help, not acceptance at every step).
• Cross-functional working together.
• Fixing and fixing up technical problems.
• Performance improvement or thoughts on scalability.

For example:

• In charge of a new API or feature that touches many teams.
• Plan and carry out an efficiency improvement that affects production.
• Plan and be responsible for a database transfer or refactoring.

Framework for autonomy:

• You choose what will happen and what limits you can set.
• The developer suggests a technical method, and you give your opinion.
• They work with a few check-ins (weekly sync instead of daily).
• They get past their blocks by doing study, asking their peers, or reading written materials.
• You only step in if they’re about to make a bad choice.

Week 11: Mentoring and Sharing What You Know

By week 11, your new developer has enough experience to teach other developers who are just starting. Give them to:

• Teach the next group of new employees (reverse the buddy system) what you know.
• In charge of a technical training or lunch-and-learn event.
• Write down a complicated part of your system or codebase.
• Help other coders with code reviews.

Why? Because teaching makes you master it. People who have to explain something better understand it themselves. Plus, it makes people care about the health of the company.

Days 85–90: Reviewing and Making Plans for the Future

During the last week of the 90 days:

Formal 90-Day Review (not a “gotcha!” moment, but a celebration):

• Celebrate real successes like releasing new features, fixing bugs, and making team contributions.
• Use the 30-60-90 structure to guide your review. Where did they go over? Where did they have trouble?
• Measure efficiency by counting things like commits, code reviews, and feature velocity
• Get input from yourself, your manager, your peers, and your buddy.

Conversation about retention: 

Now is the most important time. We’re done with the first 90 days. You make it clear: “We want you to stay here for a long time.” How does that look to you?”

Cover:

• Compensation: Is there a gap in the market? It’s normal for Tier-2 developers to take 30–40% less pay, but they can’t keep doing that if they find out they’re being underpaid.

• Growth: What do they plan to learn over the next 12 months? For a new employee, do they get to see different areas, tools, or leadership styles?

• Stability: reassure them about the direction of the company and their part in it.

• Culture: Do they feel like they belong? Are they becoming friends?

• Flexibility: Can they make hybrid plans work for them?

Getting a Regular Job: 

After day 90, switch from organised onboarding to regular performance management. Don’t forget the lessons, though:

• Keep having one-on-one meetings every month.
• Keep the standards for code review.
• Encourage people to share their skills.
• Honour and celebrate accomplishments.

Indian-Specific Day 90 Things To Think About 

New Graduates:

• Certifications: Pay for courses or certifications that are related to their job.
• Rotation: Help them learn by putting them on different teams or projects.
• Mentorship: Make a long-term guide (not just a friend) official.

For developers in Tier 2:

• Help with moving: If they have to move for work, make sure they’re settled in.
• Peer network: Help people make friends within the company
• Clarity on permanent tenure (many tier-2 developers are unsure about the security of a startup at first)

For hybrid Teams:

• Take a look at the hybrid design again. Does it work? Change if you need to.
• Office bonding: Plan some in-person team events every so often.
• Timezone alignment: Make sure that they aren’t cut off by differences in time zones.

Adapting the Framework for Your Indian Startup Context

The 30-60-90 outline is not a strict rule. It’s just a guide. Change it so that it fits your situation.

Scenario 1: Leading large groups of new hires (10 to 20 people)

Problem: You don’t have enough top engineers to do everything. You can’t give everyone their own buddy task.

How to adapt:

• Run a bootcamp based on cohorts (all new employees together for the first two weeks).
• Assign cohort buddies: one senior engineer for every three to four new engineers (rotate weekly).
• A structured learning path with well-documented modules and automatic tests for major goals.
• Peer mentoring within the class (first-year students who are stronger help those who are weaker).
• Code reviews with feedback meetings for groups.
• Celebrate wins as a unit as a whole.

Changes to the timeline: The training shortens the time it takes to learn. By week 3, they’re ready to work on their own features.

Scenario 2: College graduates in Tier 2 (Strong Fundamentals, Different Context)

Problem: They are good at solving problems, but they haven’t worked with professional codebases or modern DevOps techniques much.

How to adapt:

• Put a lot of emphasis on coding standards and the practice of code review (days 2–14).
• Rotations of pair programming went on until week 3 (instead of day 10).
• Please give them a code owner to go over with every day (until week 4).
• It’s helpful for many tier-2 graduates to learn from books, so write down what your tech stack is.
• Loudly celebrate small wins (it builds confidence and helps you remember things).
• Link them up with other tier-2 workers on your team (this will help them feel less alone).

Once Tier-2 developers have spent time learning your system and made friends, they are 20–30% less likely to leave than Bangalore developers. Spend money on this loyalty.

Scenario 3: Hybrid or Remote Team Post Covid

Problem: Not a physical office. Distributed teams. Timezone issues to think about.

How to adapt:

• As part of the pre-day-1 setting, a welcome package is sent to their home.
• A virtual tour has replaced the office tour. To make it more personal, the founder gives a 10-minute tour of their home as a way to break the ice.
• Schedule pair programming lessons for times that overlap with other time zones and use screen sharing tools a lot.
• Pair programming is taped for async review, Slack is used for quick questions, and Loom videos are used for more in-depth explanations.
• Standups every day: written updates sent in the background (4 hours to reply, not real-time meetings).
• The virtual team meets once a month for a casual, low-pressure meeting.
• Offsite meetings with the whole team every three months (if the budget allows; great for bonding).

Virtual integration: Set up one-on-ones with more than just their boss and other team members. These bring people together and make them feel less alone.

Scenario 4: High Attrition Environment (Bangalore, Competitive Markets)

Problem: Developers are getting offers all the time. After 6 months, they might leave.

How to adapt:

• Speed up their freedom and effect (get them to work that matters by week 4, not week 6)
• Early growth conversations: By day 60, be clear about their learning plan over the next 12 months.
• Peer relationships: Spend a lot of money on team social time, like monthly trips, lunches, and game nights.
• Share the company’s road map and their part in it to be clear about the direction it’s going.
• Market-rate pay: Compare rates to what the local market will bear (don’t lose them to a 15% raise somewhere else).
• Flexibility: If they ask for days off or different hours, you should agree (as long as it’s not too much).

To keep people working for you, make them feel like they’re not just writing code but also making something important. The best way to stop hunting is with this.

Common Onboarding Mistakes (What to do instead)

Get paperwork to read for two weeks:

Change it to “Ship a small PR in Week 1.

No owner

Swap out: One EM is responsible for the results of hiring.

Delays in access 

Please change it to: IT SLA + pre-boarding plan.

Buddy is symbolic

Change it to: Buddy time blocked on the calendar.

There is no 90-day growth plan.

Change it to: Expectations for the role and a skills plan for Days 60–75.

A 30-60-90 plan (template)

1–30 (Foundation)

• End of setup.
• Design 101 and workflows.
• First PR merged.
• Fixed one bug.
• Check-ins with a buddy once a week.
• Survey of new employees.

31 to Day 60 (Ownership)

• Delivered one item of the scope.
• Takes part in reviews.
• Basics of debugging and observability.
• Has a small service or part.
• Set times for pairing sessions.

61–90 (Impact)

• “Signature win” came true.
• In charge of a small technical talk.
• The quality bar was always met.
• Review in 90 days and next steps.
• Shared role path clarity.

Conclusion

In India, tech attrition is about 25%, and e-commerce is at 29%. Onboarding is no longer HR’s job; it’s a way for owners and engineering leaders to stay ahead of the competition.

Companies that keep coders don’t just pay them more. They are planning how the first 90 days will go. They’re making quick wins. They’re making culture stick around. They are letting writers know that they care about their growth.

For Indian startups in particular, the benefit is even greater. When you compete with the best in Bangalore, you have to work for less money. You’re hiring recent college grads who need a plan. In different places, you’re in charge of hybrid teams. With a well-thought-out 30-60-90 onboarding strategy, these problems can be turned into benefits.

The system works because it gives new developers what they need:

Clarity: I know what success looks like.

Connection: I work for this company.

Contribution: I sent code out, and it made a difference.

Growth: I can see how to move forward.

Implement it, measure it, refine it. In six months, you’ll look at your retention metrics and wonder why you didn’t do this sooner.

FAQs

What’s the best KPI for developer onboarding?

A practical one is time to first PR merged (7-14 days target) and time to meaningful features shipped (30-60 days), tracked with quality signals (rework rate, bug trend).

How do you onboard developers in hybrid teams in India?

Use async-first assets (videos + written docs), assign a buddy, run pairing sessions, and track “blocked >24 hours” events. Hybrid job-market signals show flexibility is common enough that onboarding must work without physical proximity. 

How do you onboard fresher batches from tier-2/3 colleges?

Use pods, rubrics, frequent feedback, and staged deliverables (docs → bug → small feature → module ownership). Skills mismatch and employability concerns are widely discussed and should be treated as a design input. 

Why do developers leave within 3–6 months?

Common reasons: unclear expectations, slow ramp, no growth visibility, weak manager cadence, and low belonging. Strong onboarding reduces early attrition risk, especially in competitive markets.