Onboarding Salesforce Developers Without Burning Your Seniors' Time

To onboard Salesforce developers without burning your seniors' time, stop using shadowing to teach the platform. Separate what a new hire needs into platform knowledge (Apex, SOQL, triggers, testing, LWC, security) and org knowledge (your data model, your conventions, your clients). Teach platform knowledge with a structured curriculum and a 30/60/90 plan with reviewable deliverables. Spend senior time only on org knowledge and on code review. This post covers the cost of the shadowing approach, a concrete 30/60/90 plan, and how team licences work if you use Salesforce Casts for the curriculum part.

I'm writing this for engineering managers and consultancy leads. I've seen both sides: the senior developer whose sprint disappears into onboarding, and the new hire who learned "the way we do it here" without ever learning why.

The real cost of shadowing-based onboarding

Shadowing feels free. Nobody raises a purchase order for "sit with Ravi for two weeks". But the cost is real, and it lands in the worst possible place.

It spends your scarcest people. Your seniors are usually the ones holding the architecture together, unblocking releases and handling the hardest client conversations. Every hour they spend explaining what a governor limit is comes out of that work.

It's interrupt-driven. Shadowing rarely happens in scheduled blocks. It happens as a stream of "quick questions" across the day. Each one is small, but the context switch isn't. A senior who's interrupted every half hour isn't doing deep work at all.

It copies habits, good and bad. A new hire learns whatever their shadow does. If that senior writes SOQL inside loops under deadline pressure, or skips bulk tests, the new hire learns that as normal. Nobody explains why, because explaining why takes longer than doing it.

It's inconsistent. Two new hires shadowing two different seniors come out with two different trigger patterns, two testing styles and two sets of gaps. Six months later, your code review is arguing about conventions that should have been settled on day one.

It doesn't scale. At a consultancy that takes on a batch of graduates or contractors when a big project lands, shadowing simply runs out of seniors.

None of this means shadowing is useless. Watching a senior debug a real production issue in your real org is irreplaceable. The mistake is using it to teach things that aren't specific to your org at all.

Platform knowledge vs org knowledge

This split is the whole idea, so here it is in a table.

Everything in the left column is the same whether the new hire joins you or a competitor. Your seniors shouldn't be its main teachers. Everything in the right column is where their time is irreplaceable.

A 30/60/90 plan built from a curriculum

Here's the plan I'd give a new developer, built from the Salesforce Casts curriculum. The principle works with any sequenced curriculum, though. Each phase ends with a deliverable a senior reviews, so the senior's time goes into feedback rather than explanation.

Days 1–30: platform foundations

Goal: the new hire can write a bulkified trigger with a test class, and explain every line.

• Data model and security. Salesforce Administration Training (free) covers objects, relationships, record types, validation rules and Sharing & Security. Developers who skip admin fundamentals write code that fights the platform.
• Apex, SOQL and DML. The SOQL, DML, collections and Apex Test Framework sections of Salesforce Development (Visualforce & Apex).
• Triggers. Apex Triggers Framework 101 (free) takes them from trigger basics to a framework. Compare it with your own framework in week four.
• Tooling. Dive into Salesforce DX and Mastering Visual Studio Code, so they work in VS Code and source control from day one.

Deliverable: a trigger with a handler class and a test class that inserts 200 records and asserts on the results, in a scratch org or sandbox. One senior review, 45 minutes.

Org knowledge in parallel: a one-hour walkthrough of your data model and a written list of "automation that already exists on our core objects".

Days 31–60: components, automation and real tickets

Goal: the new hire ships small, reviewed changes to your real codebase.

• JavaScript and LWC. Javascript for Lightning Web Components [FREE] (free) first, then Lightning Web Components Development: events, Lightning Data Service, LWC with Apex, Lightning Message Service.
• Testing in depth. Apex Test Fest: exceptions coverage, async coverage, runAs, the Assert class and callout tests.
• Flows. Learn lightning flows with me, so they know when not to write Apex.

Deliverable: two or three small tickets from your backlog, each with tests, through your normal pull-request process. Code review replaces explanation as the main teaching channel.

Days 61–90: specialise by practice

Goal: the new hire owns a small feature end to end.

Pick the track that matches the work they'll do:

• Integration practice: Salesforce Integration Master Course (Advanced Apex). That means Named and External Credentials, REST from Apex, Platform Events and Bulk API 2.0, plus the Asynchronous Apex section of the Apex course.
• Revenue or quote-to-cash practice: Salesforce CPQ in the Wild.
• UI-heavy work: Build Real Projects with Lightning for complete, project-sized builds.

Deliverable: one feature, designed with a short written proposal, built, tested and released. The senior reviews the design before the build, which is when their input is cheapest.

Variations

• Interns and graduates: stretch the first phase to 45 days, and add the free admin course as week one on its own.
• Experienced developers from another stack: compress phase one. They already know classes and tests, so focus on governor limits, sharing and the order of execution.
• Contractors on short engagements: skip straight to the track they're hired for, plus the testing course. Your conventions doc matters more than anything here.

What your seniors do instead

With the platform layer handled, here's where senior time goes:

• A short weekly review of the phase deliverable. It's scheduled, so it isn't an interruption.
• Code review on real tickets, which is where your conventions actually get taught.
• Org walkthroughs, recorded once and reused for every hire after.
• Answering org questions only. If the question is "what is a governor limit?", the answer is a course module. If it's "why does this object have two record types?", that's a senior's job.

Team licences on Salesforce Casts

If you use Salesforce Casts for the platform layer, team licences work like this:

• 5 to 40 seats. Each seat is one person's account, because accounts are one per person.
• Seats never expire. That matters for onboarding, because hiring happens in waves. Interns in summer, a contractor batch when a project lands, two replacements in spring.
• Invoices in your company's name are available on request, so it goes through finance like any other tool.
• Every seat gets the full catalogue, the GitHub repo for every course, the discussion group and certificates of completion. The certificates give you a simple record of what each person has finished.

You buy a block of seats from the team licences section of the pricing page, then email me to fill a seat whenever someone new joins. Unused seats simply wait for the next hire.

The honest limitations matter more for teams than for individuals, so here they are. There are no refunds, so have one person watch a free course end to end before you commit. Videos stream only. There are no scheduled classes, trainers or 1:1 mentoring; questions go to the discussion group. And it isn't certification-exam drilling. If your partner tier depends on certification counts, pair the curriculum with Trailhead and practice exams.

Making the case to your manager

Most managers won't approve training because it's "good for the team". They approve it when the trade is clear. Here's how I'd frame it, with your own numbers:

1. Senior time saved. Estimate the hours a senior currently spends on platform questions in a new hire's first three months. Be honest, and include the interruptions. Multiply by what that senior's time costs you, or by what it would earn on billable client work if you're a consultancy.
2. Time to first useful change. If structured onboarding gets a new hire shipping reviewed tickets a few weeks sooner, that's a few more weeks of output per hire, every hire.
3. Consistency. Fewer code-review rounds spent on basic patterns. Fewer production incidents from code that was never bulk tested. These are harder to price, but every manager has felt them.
4. Compare against the licence. Put that total next to the cost of the seats you need. Seats don't expire, so one purchase covers several hiring waves.

I won't give you a number, because it depends entirely on your team. In most teams I've seen, though, a senior's time on even a single new hire is the bigger figure. Put the comparison on one slide, using your figures rather than mine.

How to tell if it's working

Track three things across your next few hires:

• Days to first merged pull request. It should drop.
• Review comments about platform basics. Bulkification, missing tests and sharing keywords should trend towards zero, leaving review time for design.
• Senior interruptions. Ask your seniors. They'll know within a month.

If those move in the right direction, the plan is paying for itself, whichever curriculum you use. If they don't, the problem is usually that phase deliverables aren't being reviewed. Fix that before you change anything else.