Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Chapter 4: Executive Function in Practice

Executive function is the set of cognitive processes that manage, direct, and coordinate other cognitive processes. It is the project manager of the brain — handling planning, organization, time management, task initiation, working memory, flexible thinking, and self-monitoring. It is also one of the most consistently documented areas of difficulty in autism (Hill, 2004; Demetriou et al., 2018).

This matters enormously for STEAM education because STEAM tasks place heavy demands on executive function. A science experiment requires following a multi-step procedure while tracking variables. A coding project requires planning an architecture, writing code, debugging, and iterating. An engineering build requires managing materials, timelines, and sequential construction steps. A mathematical proof requires holding a chain of logic while deciding the next step.

The autistic learner who has the knowledge and intelligence to excel at STEAM content may still struggle with the executive demands that surround it. This chapter provides strategies for supporting executive function without dumbing down the STEAM content.

What Executive Function Looks Like in STEAM

Executive function is not a single ability. It is a family of related skills that interact in complex ways. Here are the components most relevant to STEAM education:

Planning and Organization

What it involves: Breaking a large task into steps, determining the order of operations, gathering necessary materials, and creating a roadmap from start to finish.

Where it shows up in STEAM:

  • Designing an experiment with multiple variables and controls
  • Planning a coding project before writing the first line
  • Organizing an engineering build from concept to completion
  • Structuring a mathematical proof or a research paper
  • Managing an art project across multiple sessions

Common difficulties:

  • Not knowing where to start on a multi-step task
  • Jumping into execution without planning, then getting stuck
  • Creating a plan that is either too vague to follow or so detailed it takes longer than the task itself
  • Difficulty estimating how long steps will take
  • Losing track of the overall goal while working on individual steps

Task Initiation

What it involves: Starting a task, especially one that is not immediately engaging or has unclear first steps.

Where it shows up in STEAM:

  • Beginning a lab report when all the data is collected but the writing feels overwhelming
  • Starting a programming assignment when the problem seems too large
  • Taking the first cut on raw materials in an engineering project
  • Beginning a complex calculation when the solution path is not obvious

Common difficulties:

  • Paralysis in front of a blank page, blank screen, or raw materials
  • Repeatedly gathering more information instead of beginning the task
  • Starting with a non-essential subtask (reorganizing files, sharpening pencils) instead of the actual work
  • Needing very specific instructions to begin, even when the student understands the overall goal

Working Memory

What it involves: Holding information in mind while using it — the mental workspace where active thinking happens.

Where it shows up in STEAM:

  • Following a multi-step lab procedure while recording observations
  • Debugging code while remembering what the code is supposed to do
  • Performing mental math within a larger calculation
  • Holding multiple design constraints in mind while building

Common difficulties:

  • Losing track of where you are in a multi-step process
  • Forgetting earlier steps while executing later ones
  • Needing to re-read instructions repeatedly
  • Making errors not from misunderstanding but from losing information mid-task

Flexible Thinking

What it involves: Shifting between strategies when one is not working, adapting to changed requirements, and seeing problems from multiple angles.

Where it shows up in STEAM:

  • Adjusting an experimental design when initial results are unexpected
  • Refactoring code when the original approach hits a dead end
  • Redesigning an engineering solution when materials or constraints change
  • Considering alternative proof strategies in mathematics

Common difficulties:

  • Persisting with a non-working strategy rather than switching
  • Distress when plans change or requirements are modified
  • Difficulty generating alternative approaches without prompting
  • Rigidity about “the right way” to solve a problem

Self-Monitoring

What it involves: Tracking your own progress, evaluating the quality of your work, and adjusting effort and strategy in real time.

Where it shows up in STEAM:

  • Recognizing when experimental data does not look right
  • Testing code as you go rather than writing everything and debugging at the end
  • Stepping back during an engineering build to check alignment and fit
  • Checking mathematical work for errors before submitting

Common difficulties:

  • Not recognizing when a strategy has failed until far too late
  • Difficulty judging “how done” a task is
  • Over-perfecting certain aspects while neglecting others
  • Not recognizing the need for a break until after a meltdown

Strategies That Work

For Planning and Organization

Provide explicit project templates. Rather than saying “plan your experiment,” provide a template with sections: Hypothesis, Variables (independent, dependent, controlled), Materials, Procedure (numbered steps), Data Collection Method, Analysis Plan. The template is not a crutch — it is how scientists actually organize their work. Making it explicit rather than assuming students will develop it independently is good teaching for everyone.

Use visual project management. Kanban boards (columns of sticky notes: To Do, In Progress, Done) make abstract project status concrete and visible. Digital versions (Trello, GitHub Projects) work well for technology-oriented learners. Physical versions work well for hands-on learners. The key is externalizing the project state so it does not have to live in working memory.

Teach backwards planning. Start with the due date, then work backwards to identify milestones. “If this is due Friday, when does the code need to be done? When does testing need to start? When do I need to have the design finished?” This is a learnable skill, and it is more concrete than “make a timeline.”

Break projects into deliverables, not just steps. Instead of a single due date for a complete project, create checkpoints: “By Tuesday, show me your design sketch. By Thursday, show me your first prototype. By next Monday, show me your tested solution.” Each checkpoint is a finish line, not just a waypoint.

For Task Initiation

Provide a first step. Not the whole plan — just the first step. “Open the IDE and create a new file called experiment.py.” “Get out the breadboard and the resistor kit.” “Write just the first sentence of your hypothesis.” Starting is the hardest part, and a concrete first action reduces the activation energy.

Use body doubling. The presence of another person working alongside the learner can dramatically reduce initiation difficulty. This is well-documented in ADHD research (which overlaps significantly with autism — Leitner, 2014) and works for many autistic learners. A tutor or peer who simply sits nearby and works on their own task can make it possible for the autistic learner to start theirs.

Allow warm-up activities. A student who cannot start the assigned coding project may be able to start by coding something easy and familiar first. Five minutes of warm-up coding — even on something unrelated — can transition the brain into the mode needed for the harder task. This is analogous to a musician’s warm-up scales and should be respected as a legitimate cognitive tool.

Name the avoidance without judgment. “It looks like getting started on this is hard right now. That is okay. Let’s find a way in.” This validates the experience without excusing the student from the task. It also distinguishes “I can’t start” (executive function) from “I don’t want to do this” (motivation), which are different problems requiring different solutions.

For Working Memory

Externalize everything. Write it down, draw it, display it on screen. Procedures should be printed and available at the workstation, not just demonstrated once. Formulas should be on a reference sheet, not memorized under pressure. Code templates and boilerplate should be provided so working memory is reserved for the novel thinking, not the routine syntax.

Checklists for procedures. Lab protocols, coding workflows, engineering build steps — put them in checklist form that the student can physically mark off. This offloads the “where am I in this process?” tracking from working memory to paper.

Reduce extraneous cognitive load. If you want to assess whether a student understands chemical reactions, do not also make them calculate molar masses from memory, decipher your handwriting, and navigate a cluttered worksheet. Isolate the skill you are testing and support everything else. This is Cognitive Load Theory (Sweller, 1988) applied specifically to learners with working memory constraints.

Teach note-taking and documentation. Many autistic learners do not naturally take notes because the act of note-taking competes with the act of listening/processing. Provide notes, or teach explicit note-taking methods that work with the learner’s style (typed vs. handwritten, outline vs. mind map, keywords vs. sentences). In STEAM, the documentation habit is also a professional skill — scientists keep lab notebooks, engineers keep design logs, programmers write comments and documentation.

For Flexible Thinking

Teach strategy switching explicitly. “When your code does not compile after three attempts, stop and try a different approach. Here are three alternative approaches you could try…” Making the trigger for switching explicit (three failed attempts, not just “when it’s not working”) removes ambiguity.

Normalize failure and iteration. In STEAM, failure is data. Experiments that disprove hypotheses are successful experiments. Code that does not compile is one step closer to code that does. Prototypes that break reveal design flaws. Frame these explicitly and repeatedly. The autistic learner who has learned that “wrong” means “bad” needs to hear consistently that in STEAM, “wrong” means “informative.”

Offer structured brainstorming. Open-ended brainstorming (“think of as many ideas as you can”) is often unproductive for autistic thinkers. Structured techniques work better: SCAMPER (Substitute, Combine, Adapt, Modify, Put to other uses, Eliminate, Reverse), constraint-based brainstorming (“what would you do if you could only use these three materials?”), or systematic variation (“change one variable and see what happens”).

Provide advance notice of changes. If requirements will change partway through a project (as they do in real-world STEAM), communicate this upfront: “I am going to give you a design change halfway through — this is part of the exercise, and it’s something engineers deal with all the time.” The change is still hard, but the surprise is removed.

For Self-Monitoring

Build in checkpoints. Do not wait until the end to evaluate. Regular check-ins (“Show me where you are every 20 minutes”) provide external monitoring that the learner can gradually internalize.

Use rubrics and success criteria. Define “done” concretely. “Your program is done when it passes all five test cases and you can explain how each function works.” Vague success criteria (“when it’s good enough”) are executive function traps.

Teach the review habit. Model it explicitly: “Before you submit, I always do these three checks: 1) Does it meet the requirements? 2) Did I test it? 3) Is it understandable to someone else?” Turn self-monitoring into a checklist and it becomes a procedure — which autistic learners are often very good at following.

Create progress visibility. Progress bars, completed checklists, growing portfolios — any mechanism that makes progress tangible rather than abstract supports self-monitoring by making the state of the work externally visible.

Executive Function Is Not Laziness

This should go without saying to this audience, but it bears emphasis because it affects how you respond to executive function difficulties in the moment.

A student who cannot start a task is not lazy. A student who cannot switch strategies is not stubborn. A student who loses track of a multi-step process is not careless. These are genuine cognitive difficulties with a neurological basis, documented across decades of research.

The appropriate response is accommodation and skill-building, not consequences for “not trying.” Executive function skills can be developed — they often develop later in autistic individuals than in neurotypical peers (Rosenthal et al., 2013) — but they develop through scaffolding and practice, not through punishment for their absence.

The Interaction Effect

Executive function difficulties do not exist in isolation. They interact with sensory processing (Chapter 3), cognitive style (Chapter 2), and emotional regulation. A student who is managing high sensory load has fewer executive function resources available. A student who is anxious about social evaluation has less capacity for flexible thinking. A student who is deeply engaged in a topic of interest may exhibit excellent executive function in that domain and poor executive function in everything else.

This means that the strategies in this chapter are most effective when combined with the sensory accommodations from Chapter 3 and the cognitive strategies from Chapter 2. Reduce the sensory load, design instruction that works with the cognitive style, and the executive function demands become more manageable — often without additional intervention.


Previous: Chapter 3 — The Sensory Landscape of STEAM Environments Next: Chapter 5 — Science