In my career as a BCBA®, I had a moment where I caught myself building programs around what my software could do instead of what my learner really needed. I'd been adjusting to the system's limitations for so long that I'd almost stopped noticing I was doing it.
That realization is what got me thinking about a bigger question: when your ABA software forces you to adapt, what do those adaptations end up doing to your clinical practice?
What happens when what's easy to measure becomes what you measure
Think about baseline data. Before you start an intervention, you want to know the learner's actual performance level. That's the clinical question. But in some ABA data collection systems, setting up a true baseline phase takes extra configuration. Maybe the software doesn't make it obvious, or you don’t trust it to transition from baseline to teaching, so you skip baseline altogether and start in teaching. Either way, the path of least resistance becomes writing “0%” in the report and moving on.
The graph has a starting point, but the true pre-intervention performance level was never captured.
This is a small example, but the pattern behind it isn't small at all. In ABA, decisions about what happens next for that learner are driven by data we measure, collect, graph, and analyze. So when the technology we’re using makes one kind of data easy to collect and another kind harder, it shapes what information is available when the BCBA sits down to make a clinical call.
When programming has to fit the software
Imagine you want to build one program with three targets. Each target needs its own teaching procedure. Each has mastery criteria tailored to this specific learner's history.
But the system you're using can't hold different teaching procedures within a single program. So you split the targets into separate programs and apply one procedure across all of them. Or you keep the program together but move your clinical rationale into separate notes that your RBTs® may or may not read before running the session.
Either way, the program that gets delivered ends up being the version the software could accommodate, structured by a technical limitation, not a clinical decision.
The software didn’t intend to change your clinical approach purposefully, but when the alternative is hard enough, most people stop trying. And over enough sessions, what was once a workaround starts to be how you build programs.
How one quick fix becomes how everyone practices
A BCBA at your organization runs into one of the limitations I just described. They adapt their programming to work within the software.
Now they supervise RBTs. Those RBTs watch how they set up programs, collect data, and structure goals. They're learning what “normal” looks like from watching. The adaptation they made because of a software limitation is now being modeled through supervision.
Other clinicians at the organization adopt the approach, too. It spreads to other teams, other locations. And at one point, a person's workaround has become how the organization practices. It's written into onboarding materials, and it’s how new hires learn to build programs. A software-driven adaptation became an unintended organizational norm.
I want to be clear about something: not every workaround is wrong. Clinicians adapt constantly, and many of those adaptations are thoughtful responses to real constraints. The concern is when a software constraint shapes programming in ways that limit individualization.
How to tell whether your team's practice reflects clinical decisions or inherited workarounds
If you're a Clinical Director or a practice owner, there's a question worth sitting with: how much of your organization's clinical practice was deliberately chosen, and how much was inherited from the tools you happened to be using when you built your processes?
A few places to look:
- Look at how targets are grouped, how teaching procedures are assigned, how mastery criteria are set. Are these configurations driven by the learner's profile, or by what the software makes convenient? The answer might be “both,” and that's fine, as long as someone made that call intentionally.
- When you ask a BCBA why programs are structured a certain way, listen for the reasoning. ‘This is what the learner’s data showed us’ is a clinical answer. ‘That’s how the system works’ or ‘that’s how we’ve always set them up’ tells you something else.
- Check whether your baseline practices actually produce baseline data.
- Pay attention to what your team does during onboarding. When a new BCBA joins, are they learning your clinical model, or are they learning the software's constraints?
These questions tie back to treatment fidelity. Measuring whether a technician delivered what was prescribed is valuable. And it’s even more valuable when you can also be confident that the prescription itself reflects what the learner needs.
What it looks like when the tool follows the clinician
The principle behind all of this is simple enough: clinical standards should come from clinicians. From clinical leadership and judgment, evidence-based practice, ethical responsibilities, and the needs of the individual learner. Not from what a platform happens to make easy or difficult.
That sounds obvious, but it’s only obvious until you try to find a data collection system that actually works that way. Kathy Tuthill, Director of Autism Services at Rivermont Schools, described it this way:
“I have not found anything we could not build out in Motivity the way we wanted it to.”
That’s what happens when the clinician’s judgment gets to come first and the technology accommodates it, instead of the other way around.
In practice, that means inside Motivity, a BCBA can build a program with three targets, three different teaching procedures, and individualized mastery criteria without splitting anything apart or burying the rationale in a separate place. Baseline gets captured as actual data points on the graph, and supervisors can see what was prescribed versus what was delivered across sessions and across staff.
If the questions in this post made you want to go check how your team builds programs, that’s a good sign. And if you want to see what it looks like when the software follows the clinician, we're happy to show you.
