The solutionist mindset needs a stopping rule

By Zaynah Danquah. Lead instructional designer and co-founder, 24/7 Teach. Reading time: 10 minutes.

A client asks for a 45-minute compliance course. You are fairly sure a two-page job aid would work better. The subject matter expert stopped answering email nine days ago, the deadline did not move, and you have tools on your desktop that can draft the whole module by Thursday.

Five years ago that situation forced a conversation. Today it does not. You can just build the thing.

That is the part the popular version of the solutionist mindset misses. Instructional design writing has spent years telling designers to adapt, pivot, and stop waiting for perfect conditions, and the advice was correct when production capacity was the binding constraint. It is now incomplete in a way that is starting to cost people. A solutionist who cannot say when to stop adapting is not a problem-solver. They are an order-taker with better vocabulary.

What a solutionist actually is

The core idea is sound: orient toward outcomes rather than obstacles. When a plan derails, ask what the real goal is, what is available right now, and how to move forward with value.

It also has a research lineage worth claiming, because the lineage contains the correction.

In 1986, Giyoo Hatano and Kayoko Inagaki drew a distinction between two kinds of expert. The routine expert executes known procedures with speed and accuracy inside familiar conditions. The adaptive expert holds the same domain knowledge but adds the conceptual understanding to invent new procedures when the situation is unfamiliar. Both perform well on familiar work. The difference only shows up when the task, the method, or the desired result is not known in advance, which is a fair description of most instructional design projects.

Here is the part that gets dropped. Researchers building on that work describe the adaptive expert as high on both efficiency and innovation, able to select between a routine approach and an adaptive one, and able to explain why they chose it.

Selection is the skill. Not adaptation. Adaptation is what you do after you decide the situation calls for it. A designer who adapts to everything has not demonstrated adaptive expertise. They have demonstrated that they never run the decision.

Why this matters more now than it did a year ago

The old constraint on instructional design was production. Building the thing was slow, so the constraint conversation happened by force. You could not quietly absorb a bad brief, because absorbing it meant six weeks of visible work you could not finish.

That pressure is gone.

Synthesia's AI in Learning and Development Report 2026, conducted with learning scientist Dr. Philippa Hardman across 421 respondents, found roughly 87% of teams using AI in training and development, only 2% with no adoption plans, and 36% running AI inside defined instructional design workflows rather than experimenting at the edges. Treat the headline number carefully, because the report says so itself: it was distributed through Synthesia's audience and Hardman's network and likely overrepresents early adopters. A separate survey of 587 instructional designers run by Dr. Luke Hobson between April and June 2026 found close to half using AI daily, with time as the leading motivation.

The direction is not in dispute even if the exact percentage is. Production got cheap.

The failure mode moved with it. The old one was paralysis, a designer stalled waiting for a platform, a signoff, or a subject matter expert. The new one is fluent wrongness: a polished, well-structured, on-brand deliverable that lands on time and does not change what anyone does at work. It survives review because it looks finished. Hardman has warned about exactly this, that AI makes it possible to "efficiently produce ineffective learning experiences."

And the check that would catch it was already the field's weakest link. Hardman's 2024 survey with Synthesia found instructional designers spending under 10% of their time on evaluation, the last phase of ADDIE and the one most often cut. Speed up production tenfold against an evaluation practice that thin and the gap does not stay the same size. It widens. EDUCAUSE's June 2026 report, based on 438 faculty and staff, found real movement toward using AI inside assessment design alongside genuine uncertainty about how to verify what students can actually do.

Prototyping fast is still good advice. It is only good advice when something downstream catches the prototype that should not ship.

Where solutionism turns into order-taking

Cathy Moore has spent most of a career on this problem. Action mapping exists because "build me a course" is usually not the real request, and her guidance to designers is to trace the business goal, ask why the request exists, and refuse the role of order taker. She has a running joke about a meter that shows how far toward order taker a designer has drifted.

Set that against a common framing in solutionist writing, which lists a designer's options when a client requests the wrong thing as: wait, stall, push back, or pivot, with pivot as the mature choice.

Three of those are failures. One of them is the job.

The fix is not to abandon the mindset. It is to sort constraints before you decide how to treat them. In practice there are three kinds.

Resource constraints. The platform is down, the budget got cut, the timeline compressed, the subject matter expert vanished. You know the outcome you need and something in the way of producing it is missing. Design around these. This is where solutionism earns everything it claims, and where a designer who moves while others wait is genuinely more valuable.

Scope constraints. The request is larger, longer, or heavier than the outcome requires. Forty-five minutes of content for a behavior that needs a checklist. Negotiate these. You are not blocked, you are being asked to spend the learner's attention on something that will not pay it back.

Validity constraints. The requested solution cannot produce the requested outcome, or nobody can state what the outcome is. Escalate these. Designing around a validity constraint is not resourcefulness. It is producing an artifact that documents effort instead of causing change, and doing it faster than anyone can notice.

Almost every argument about instructional designers being treated as order-takers is a validity constraint that got handled like a resource constraint.

The stopping rule

Three questions, in order. Any no stops the work.

One. Can I still name the behavior this is supposed to change? Write the sentence: this exists so that [role] will [observable action] on the job. If you cannot finish it, you do not have a design problem. You have an analysis gap, and no amount of resourcefulness closes it.

Two. Under this constraint, will what I ship still move that behavior? Not "will it be defensible." Not "will it look complete." Will it move the behavior. If the honest answer is no, building it faster makes the problem worse, because the finished artifact will be read as evidence that the need was addressed.

Three. Does the person who owns this constraint know what I am about to absorb? This is the question people skip, and skipping it is the actual failure. Absorbing a constraint silently transfers its consequences from the person who created it to you.

Escalation is the word people flinch at, so be precise about what it means here. It is not refusal, and it is not a complaint. It is one sentence:

I can deliver X by Friday under this constraint. It will do A. It will not do B. Confirm that trade works and I will build it.

That sentence moves the work forward and names the cost at the same time. It is the most solutionist thing in this article. It is also, quietly, the thing that protects you, because the designer who absorbed a bad constraint in silence owns the outcome, and the designer who documented the trade does not.

<div id="ctStage" aria-live="polite">
  <h4 class="ct-q" id="ctQ"></h4>
  <p class="ct-hint" id="ctHint"></p>
  <div class="ct-answers" id="ctAnswers"></div>
</div>

<div class="ct-foot">
  <button type="button" class="ct-text-btn" id="ctBack" hidden>Back</button>
  <button type="button" class="ct-text-btn" id="ctReset" hidden>Start over</button>
</div>

How we run this at 24/7 Teach

A stopping rule without a standard is just a mood. Most designers cannot say when to stop because they have nothing to measure "good enough" against, so the deadline decides for them.

Our production workflow puts the standard in the middle of the process rather than at the end. AI drafts first. A designer evaluates that draft against a defined rigor standard. A second AI pass critiques the evaluation itself, looking for what the first pass accepted too easily. Then a realism check with someone who has actually taught the material, because a draft can be pedagogically clean and still be unrunnable in a real room with real time limits. Then iterate. We call it produce, evaluate, iterate with triangulated QA, and the triangulation is the point: three different kinds of error get caught by three different reviewers, and no single pass is trusted.

The rigor standard itself uses two lenses, not one. Bloom's taxonomy for the kind of thinking a task demands, and Webb's Depth of Knowledge for how deep that thinking actually goes. Designers who use only Bloom's get fooled constantly, because a task can carry an impressive verb and sit at the shallowest depth available. "Evaluate the following three options" is a Bloom's-level-five verb attached to a recall task if the options are trivially different. One lens lets that through. Two do not.

This is also what we teach in the Instructional Design Bootcamp, and it is the part career-changers tend to underestimate. Portfolio pieces get people interviews. The ability to say why a design decision was made, against a standard, is what gets them hired. A recent cohort had 4 of 4 hired, with the fastest offer landing 16 days from program completion.

The strongest objection: you are describing a seniority privilege

This is the fair one, and it deserves more than a nod.

A contract designer on a three-month engagement, a career-changer eight weeks into their first role, a junior on a team with a stakeholder who does not take input: these people get told to push back by people whose standing makes pushing back safe. That is not advice, it is a description of someone else's job. It gets worse in a market where staffing patterns have shifted toward flexible capacity, which several 2026 industry observers have noted, and where being the person who raises friction feels like being the person who does not get renewed.

Two honest responses.

First, the stopping rule is not a veto. It is a documentation requirement. "I will build it, and here is what it will and will not do" is available to a first-week contractor and it is career-protective rather than career-risking. Devlin Peck made a related point reviewing Moore's Map It: sometimes the client really does want to buy a course, even knowing it will not fix the performance problem, and that is their call to make. Naming the trade and building it anyway is a legitimate outcome of the rule. Building it without naming the trade is not.

Second, and less comfortably, the research is partly on the objector's side. Hatano and Inagaki identified conditions under which adaptive expertise develops, and among them were working contexts that value quality over efficiency and environments where rewards do not hang on immediate performance. Many instructional design roles are the exact inverse. If your environment punishes the stopping rule, the honest diagnosis is that no mindset article is going to fix it. That is a job problem wearing a skills problem's clothes, and pretending otherwise does you no favors.

What to do this week

1. Take your active project and write the sentence. This exists so that [role] will [observable action] on the job. If you cannot finish it in one try, that is your escalation and it goes out today.
2. Find the constraint you absorbed silently in the last two weeks. There is one. Send the trade sentence to whoever owns it, even late. Late documentation still beats none.
3. Add an evaluation pass before you add another generation tool. If AI is drafting for you and nothing downstream checks the draft against a standard, more tools will only increase throughput on unverified work.
4. Pick your standard and write it down. Bloom's plus Webb's Depth of Knowledge on every assessment item is a workable starting point. Any standard beats the deadline making the call.
5. Start a constraint log. Date, constraint, whether you designed around it, negotiated it, or escalated it, and what happened. Six months of that document is your performance review, your portfolio narrative, and your interview answer when someone asks how you handle ambiguity.

Being a solutionist is still the right ambition. Obstacles are design opportunities more often than people treat them as such, and the designer who moves while others wait for permission is genuinely more valuable.

Just know which obstacle you are looking at. The ones worth designing around are the ones between you and a goal you can still name.

About the Instructional Design Bootcamp

24/7 Teach runs an Instructional Design Bootcamp built for career-changers, with real portfolios and real client work rather than practice exercises. Career services include coaching through job transitions and consulting on high-level performance to secure placement or readiness for promotion once hired. More than 600 adults have been placed in new careers through our programs. See the bootcamp curriculum and next cohort dates

About the author

Zaynah Danquah is the lead instructional designer and a co-founder of 24/7 Teach, where she designs programs and curriculum across the company's teen, adult, and organizational tracks. Through 24/7 Teach, she and her team have supported more than 50 organizations and placed more than 600 adults in new careers. Full bio

This article was researched and written by Zaynah Danquah with AI assistance, then reviewed and edited by our team. External studies and sources are credited to their original authors. Examples from our own work reflect our organizational practice.