Many of the biggest challenges in learning and development (L&D) aren’t learning challenges; they’re operational challenges. 

That realization started for me about five years ago on my first day at Sweetwater. I was given a simple directive: “Make training better.” Where do you even begin? 

Fortunately, I joined an organization with a strong training culture. The content was already excellent. Even the weakest programs would have been considered strong elsewhere. So the work became less about designing courses and more about designing the systems that made great training possible. 

I stopped thinking like an instructional designer and started thinking like a systems architect. Everything that followed — from scheduling, to automations, to our learning management system (LMS) strategy — flowed from that mindset shift. 

We Didn’t Set Out to Build an LMS 

The first real opportunity wasn’t instructional in nature, instead it was logistical. Scheduling training sessions was fragmented, manual and dependent on too many disconnected systems. 

At first, investing in a new platform felt hard to justify. So instead of asking what we should buy, I asked: How can we make what we already have work better together? 

We were already using configurable tools with automation, data relationships and integration capabilities. What was missing was workflow design. 

What began as a scheduling fix slowly evolved into an interconnected operational system supporting hundreds of training events each year. More importantly, it reshaped our thinking: Scalable training operations don’t come from a perfect platform, they come from intentionally designing the flow of information, people and learning experiences throughout an organization. 

Think Like an Operator Before You Think Like a Technologist 

Before evaluating platforms, we stepped back and identified the outcomes we were trying to achieve: 

• Schedule training at scale 

• Reduce manual coordination and communication 

• Standardize delivery across programs 

• Improve visibility for learners, managers and administrators 

• Reduce repetitive administrative work 

• Scale learning without scaling operational overhead 

One early example involved a technical onboarding program spanning five departments. Each new hire completed two to three weeks of full-time instruction. The training itself was effective, but the logistics behind it were almost entirely manual. 

Schedules lived in one system, instructor availability in another and coordination happened through constant back-and-forth communication. As hiring increased, the system didn’t scale. 

Using low-code tools already in place, we synchronized our training database with our enterprise calendar tool. Instructors gained automatic visibility into upcoming sessions, and onboarding cohorts could be scheduled through a repeatable cadence rather than manual coordination. 

Once we understood the workflow, decisions about automation, standardization and tooling became obvious. Technology stopped leading the design and started supporting it. 

Build in Layers, Not Giant Projects 

The next lesson was to avoid designing complete systems upfront. Instead of attempting a full rebuild, we iterated. A shared onboarding database became the foundation. From there, we added capability gradually — one automation, integration or improvement at a time. 

Over the next two years, that simple calendaring experiment gradually evolved into a robust operational system supporting registration, attendance tracking, QR check-ins, reminders, feedback collection, assessments, grading and reporting. 

For example, when a new hire was added to the onboarding dataset, our database automatically aligned them to the appropriate learning path, allowed us to register them for sessions, placed events on instructor and attendee calendars, generated attendance rosters and triggered reminder emails. After class, attendance, feedback, quiz scores and completion data flowed back into the same system with minimal manual entry. 

None of those capabilities were planned on day one. Each emerged in response to a real operational challenge. Had we tried to design the entire system upfront, it likely would have stalled under its own complexity. Instead, the system evolved one workflow at a time, with each layer making the next one possible. 

Eventually, what once required multiple people coordinating across multiple systems became a largely self-sustaining workflow, all built without introducing a new platform. 

The same layered philosophy shaped our eLearning strategy. We didn’t begin by purchasing a full-featured LMS. Instead, we intentionally matured our learning ecosystem in stages. 

• Layer 1: Prototype. We started by hosting simple HTML learning resources internally. We wanted to validate ideas, understand learner needs and habits and discover what worked before investing heavily in a long-term solution. 

• Layer 2: Organize. As our resources and content library grew, we expanded into a centralized knowledge base tool. This gave us a single source of truth, standardized documentation and a repeatable structure for managing learning resources. 

• Layer 3: Connect. Next, we linked our learning resources with the scheduling ecosystem we had already built using low-code tools and cloud-based databases. Lesson plans, enrollments, calendar invitations and communications became connected parts of a single workflow. Every manual step became an opportunity for automation. 

• Layer 4: Formalize. Only after we understood our workflows did we pilot a lightweight LMS. By this point, the LMS itself wasn’t defining our processes, it was supporting the ones we already had established.  

• Layer 5: Specialize. Finally, once we had years of operational experience under our belt, we were able to make a business case for a purpose-built LMS. We had documented our workflows, identified our operational gaps and created a detailed checklist of the capabilities that mattered most. Choosing the right platform became dramatically easier because we understood our processes first. 

What I Learned About Designing Training Systems 

Looking back at how our training systems evolved, a few principles kept showing up. None of them were obvious at the start. They came from repeated attempts to fix the same operational problems in slightly better ways each time: 

1. The first is simple: build processes that get the right message to the right people at the right time. That’s what training operations is. It’s the work of shaping systems so information reaches the people and systems that need it without friction, delay or manual chasing. 
2. Second, I learned to start with workflows, not platforms. Platforms don’t solve problems in isolation. When the workflow is unclear, even the best tool just automates confusion. 
3. Third, build once, benefit many times. Some work is repeated hundreds or thousands of times, so it makes sense to invest upfront in systems, automation and structure. Other work is one-off and should stay lightweight. That distinction is what turns training operations into leverage over time. 
4. Fourth, good systems absorb complexity so people don’t have to. The goal isn’t simplicity on the surface at all costs. Sometimes the system gets more complex behind the scenes, so the experience becomes simpler for everyone else. 
5. Finally, I learned that the goal isn’t maximum customization, it’s intentional customization. Every custom workflow creates long-term ownership. That’s not bad, but it must be deliberate. If you overbuild, you don’t just create a solution, you create future maintenance work that must be carried forward. 

Taken together, these ideas reshaped how I think about training operations. We didn’t set out to build an LMS, we set out to solve one operational problem at a time. Over time, those solutions became an interconnected, scalable learning ecosystem. That’s what systems architects do. When the system is well designed, the right technology becomes much easier to choose.