How to separate intrinsic vs extraneous load in onboarding new engineers?

[Zoey.D]

I'm an instructional designer revamping our company's onboarding program for new software engineers, and I'm trying to apply cognitive load theory to reduce overwhelm. The current training dumps massive amounts of documentation and complex system architecture on day one. I want to structure the content into manageable schemas and use worked examples, but I'm struggling to identify what constitutes 'intrinsic' versus 'extraneous' load in this specific technical context. How have others successfully segmented complex technical information for beginners without oversimplifying?

[Olivia.P]

Nice goal. Start by separating what's truly hard (intrinsic load) from how you present it (extraneous load). Use bite-sized modules paired with simple worked examples to build mental models.

[Stella46]

Intrinsic load is the inherent complexity of the material—the APIs, authentication flows, deployment pipelines. Extraneous load is the way you present that info—the wall of docs, irrelevant details, poor navigation. To tackle this, map out core concepts into 'schema cards' (one idea per card) and enforce progressive disclosure: start with a high-level diagram, then add layers as needed. Use worked examples that walk through end-to-end tasks, then remove scaffolds as newbies gain competence.

[Olivia.G]

Propose a 4-week onboarding sprint: Week 1 give a compact 'system overview' diagram plus a learning path; Week 2 introduce a single end-to-end task with a guided worked example (input, steps, expected outputs). Week 3 swap in a new task but keep the same schema cards; Week 4 have the learner execute a mini project and present their flow. Include micro-assessments (short recall questions) to gauge understanding and avoid information overload. Gather feedback weekly to tune what's extraneous.

[Richard.G]

Use your existing docs but annotate them with cognitive-load cues: 'intrinsic notes' for essential complexity, 'explanations' for clarification, 'don't need to read' flags for non-critical sections. Create a one-page onboarding map per role.

[JasonS]

Make heavy use of worked examples: show the target outcome first, then step through the process, with decisions highlighted. For realism, keep the example grounded in a real task your new hire will do.

[Logan_A]

To know it's working, collect simple metrics: time to complete a task, questions asked per module, retention on a quick quiz, subjective cognitive-load rating after each module. Use A/B tests if possible between traditional dumps vs schema-based approach.