About

I build learning systems,
not just content.

I’m an instructional designer, technical communicator, programmer, and systems-oriented problem solver. That means I tend to look at learning problems a little differently:

When someone asks for a course, I want to know if that's actually the answer.
When a team needs a new tool, I want to know how it fits into the rest of their learning ecosystem.
When a process works because someone knows the twelve weird steps to keep it working, I want to redesign the process—not write better instructions for twelve weird steps.

I work across the full learning lifecycle: analysis, architecture, design, development, implementation, evaluation, and iteration. (ADDIE on steroids.) But I'm equally comfortable moving beyond the traditional boundaries of instructional design. Some learning projects need a different approach and the flexibility to adapt to the project needs rather than force a single instructional design approach.

I can talk to a SME about performance objectives, dig through an LMS configuration, map a workflow, prototype an interaction, troubleshoot HTML and CSS, read code, work with APIs and data structures, program an Excel macro with VBA, design reusable components, define a true knowledge base taxonomy, throw together an icon, design a layout, and translate technical constraints into decisions that actually make sense for learners and the people supporting them.

I thrive in the spaces between disciplines

Some of the most interesting problems don’t belong neatly to instructional design, software development, UX, operations, or learning technology.

They live somewhere in the middle.

My technical background gives me enough understanding to work effectively with developers and technical systems without treating technology like a magic black box.

My instructional design background keeps the technology grounded in what people actually need to learn and do.

And my systems orientation makes me think beyond the immediate deliverable to the ecosystem around it.

The question isn't just: Does this work?

It's also:

Will this still work when there are 200 courses instead of 20?
Can someone other than me maintain it?
What happens when the requirements change?
Are we solving the underlying issue, or just making the workaround prettier?

Built-to-last beats built-to-get-by

I care deeply about maintainability and sustainability.

Not because everything needs to be engineered into an enormous enterprise system, but because "we'll fix it later" has a habit of becoming permanent architecture.

I build reusable patterns. I document decisions. I think about naming, structure, governance, ownership accessibility, scalability, and what happens after launch.

Sometimes the right solution is sophisticated...

...sometimes it's remarkably simple.

The important part is understanding the system well enough to know the difference.

What I bring to the table

Broad enough to connect the pieces. Deep enough to build them.

Instructional Design

Analysis through evaluation. Not just content development. I can identify the performance problem, design the intervention, build it, implement it, and determine whether it worked.

Learning Technology

LMS administration and architecture, learning ecosystems, integrations, content standards, technical troubleshooting, platform evaluation, and implementation.

Technical Fluency

Programming concepts, web technologies, data structures, version control, APIs, and component-based development. Enough depth to collaborate meaningfully with engineers.

Systems Thinking

I look for dependencies, patterns, bottlenecks, failure points, and opportunities to turn one-off solutions into sustainable systems.

Making Things

Ultimately, I'm a builder. Courses, tools, processes, components, architectures, prototypes, documentation—whatever form the solution needs to take.

I'm interested in hard problems

Especially the ones where learning and technology collide.

I'm at my best when there's something to untangle: a learning ecosystem that has grown organically, a platform that no longer fits the organization, a manual process that should probably be a system, a new learning function that needs an architecture, or a problem where nobody is quite sure whether the solutions belongs to L&D, IT, product, or somewhere in between.

Give me the messy version.

That's usually where the fun start.

I build learning systems, not just content.