How We Built a Content Machine: From 50 to 637 Modules in One Year

When someone asks how we scaled from 50 to 637 modules in a single year, the reaction is almost always the same. Their eyes go wide. They ask if we hired a ton of people, or if we found some magic AI tool that basically writes courses. When I tell them the team barely grew, the follow-up question is always some version of: "So what's the secret?"

Here's the uncomfortable truth I've come to: there isn't one. The 12x number looks like a miracle from the outside. From the inside, it felt more like 12 months of discovering everything that was wrong with how we were making decisions about content. Not production decisions. Not tool decisions. Decisions about what to build, when to build it, who owned which step, and when to stop building something that wasn't working.

I'm going to tell you what we actually did, including what blew up in the first three months, the thing we kept avoiding that turned out to be the real bottleneck, and how "content machine" became the wrong metaphor almost immediately.

---

TL;DR

• We scaled from 50 to 637 modules in one year with a 26-person global team across three continents. The biggest unlock wasn't AI or headcount. It was treating content as a decision system, not a production system.
• Key moves: parallel development tracks, content deprecation to free capacity, compressing approval cycles from 6 weeks to 2, and using AI for the right tasks at the right stages.
• Chapman Alliance research puts eLearning development at 79-184 hours per finished hour. At that rate, 637 modules would be mathematically impossible without fundamental process change.

---

💥 What Blew Up First

In the first quarter, we tried to scale the way most teams do: we added projects to the queue, allocated more IDs to production, and told everyone to move faster. The output went up, but not by much. More importantly, the quality started drifting.

Our review cycles stretched. SMEs became bottlenecks. Modules started making it through development only to get flagged during QA for being misaligned with what the business actually needed. We were producing more, but we were also building more of the wrong things faster. That's not scaling. That's running harder in the wrong direction.

The breaking point was a project that took 11 weeks and got pulled before launch. The business need had evolved while we were building. By the time the module was finished, the process it trained people on had already been updated twice. Eleven weeks of development. Zero deployments. I had to tell the VP of Product that the team had spent significant resources on something we were shelving.

That conversation was the inflection point. It forced us to ask a question we'd been avoiding: are we building the right things? We were so focused on throughput that we'd never formalized how we decided what to build, when to build it, or when to stop. We had a production problem dressed up as a systems problem, or more accurately, we had a decision problem we'd been misdiagnosing as a production problem.

---

🧠 The Decision Problem Nobody Talks About

The research says it takes 79 to 184 hours to develop one finished hour of eLearning (Chapman Alliance). If you're building microlearning, that number comes down significantly, closer to 25-40 hours per finished hour, and about 300% faster development than traditional eLearning. Those numbers look like production inputs. But they're actually decision outputs.

Every hour we chose to spend on a traditional full-length eLearning module was an hour we weren't spending on something shorter, faster, more targeted. The format decision was actually a capacity decision. We just weren't framing it that way.

This is the insight that changed everything for us: scaling content isn't a production problem, it's a decision problem. Most teams I talk to are trying to get faster at building. What they actually need is a system for deciding what to build, in what format, at what priority level, and whether existing content could serve the need instead of new development.

We built a simple triage framework. Every new content request had to answer three questions before it entered the development queue. First: does this content already exist in some form, even if imperfect? Second: what's the minimum viable format that meets this learning need? A 4-minute microlearning module is not a lesser version of a 40-minute eLearning course. It's a different tool for a different job. Third: what does "done" look like, and who decides?

That third question sounds basic. It is not basic. We had dozens of projects sitting in perpetual revision cycles because nobody had agreed upfront on what "approved" looked like. The triage framework didn't add bureaucracy. It removed ambiguity. And removing ambiguity is how you make a team move faster.

---

⚡ Eliminating Waste Before Adding Speed

Before we touched any tools or technology, we did something uncomfortable: we mapped the full content development workflow from initial request to LMS deployment and found every place where work sat waiting. Not where work was being done slowly. Where work had stopped entirely.

Toyota's lean manufacturing principles have a useful vocabulary here. Muda (waste) shows up in eight forms. In content development, the ones that cost us the most were waiting (storyboards sitting in SME inboxes), over-processing (three rounds of review for a 5-minute module that needed one), and overproduction (building comprehensive libraries on topics that needed a single job aid).

When we mapped our pipeline, we found that roughly 40% of elapsed project time was not active development time. It was waiting. Waiting for SME availability. Waiting for manager sign-off. Waiting for a scheduling conflict to resolve so we could have a meeting that could have been an email. We weren't slow because we were bad at building. We were slow because we'd designed a process with wait time baked into every stage.

The first thing we did was attack the waiting, not the building. We set SLAs for SME reviews: three business days for a module section, five for a full course. We documented those SLAs in project kickoff agreements and gave SMEs a single-page review guide so they knew exactly what they were being asked to evaluate. We stopped sending 47-page storyboards with the instruction "please review" and started sending scoped chunks with specific questions attached.

That alone, reducing the wait time without changing a single authoring process, cut our average elapsed project time by about 15%. Before any AI. Before any new tools. Just removing the friction from human handoffs.

---

🔀 Parallel Tracks, Not Sequential Stages

The traditional ADDIE model is sequential: Analyze, Design, Develop, Implement, Evaluate. Each phase completes before the next begins. That structure made sense when design and development happened in different departments, or when "Implement" meant shipping physical materials. In a modern content operation, it's a bottleneck machine.

We restructured around parallel tracks. While one ID was completing storyboard development on a module, another was beginning multimedia production on the approved sections. SME review and visual design overlapped instead of waiting in line. QA happened in rolling passes rather than a single end-stage sweep.

Netflix operates on what they call "highly aligned, loosely coupled": teams have clear direction and shared objectives, but they don't require permission to move. We applied something similar to content development. IDs had clear lane ownership over their modules. The alignment happened at the brief and approval stages. Between those checkpoints, they moved without waiting for a committee sign-off on every micro-decision.

The result was that multiple modules could be at different stages of development simultaneously without them blocking each other. Instead of one sequential pipeline processing projects one-at-a-time, we had parallel tracks where several projects were in active development at the same time, each in its own lane.

This felt risky at first. What if someone moved forward on a design direction that got reversed in review? We had two projects where that happened in the first month. Both were painful. But we also finished four times as many modules in that same period as we would have under the old sequential model. The math still favored parallel development, even accounting for the occasional rework.

---

🗑️ Content Deprecation Is a Capacity Strategy

Here's one nobody talks about in the "scale your content library" conversations: the fastest way to free up capacity is to stop maintaining things that shouldn't exist anymore.

When we audited our existing content library at the start of the year, we found 23% of our modules were either outdated (the process they described had changed), redundant (two modules covering the same topic at nearly the same level), or unused (completion rates below 5% over the trailing six months). Those modules weren't just sitting there doing nothing. They were actively consuming maintenance capacity. Every quarter, someone had to review them for accuracy. Business partners asked about them. New hires were sometimes assigned them in onboarding paths even though the content was stale.

We built a deprecation protocol. Any module with a completion rate below 10% over 90 days went to the content owner for a decision: refresh, replace, or retire. Any module describing a process that had been updated by more than 30% got flagged for rebuild rather than maintenance. We retired about 40 modules in the first half of the year. That freed up roughly two IDs worth of maintenance time, which went immediately into new development.

There's a concept in software engineering called technical debt: accumulated shortcuts and workarounds that make the system harder to work with over time. Learning programs have the same thing. Call it learning debt. Old modules that technically exist but don't serve learning needs anymore. Every team has it. Most teams are afraid to touch it because deleting content feels like admitting the work was wasted. But that debt is costing you production capacity every quarter, quietly, invisibly, unless you're tracking it.

The deprecation conversations weren't always easy. Some of the modules we retired had been built by people who were still on the team. The language mattered: we weren't saying the work was bad. We were saying the need had evolved, and continuing to maintain a module that wasn't serving learners wasn't honoring the work. It was just preserving the artifact.

---

📊 Where AI Actually Fit In

By the time we started integrating AI into the workflow in a serious way, we'd already done most of the hard work. The decision framework was in place. The parallel tracks were running. The SME review process had been redesigned. The deprecation protocol was active.

That timing was not an accident. I was deliberate about not introducing AI tools until we had the underlying system working. Here's why: AI accelerates whatever workflow you put it into. If the workflow is broken, AI just makes you move through the broken process faster. You still end up in the same wrong place. You just get there sooner.

Research puts AI at roughly 50% faster course development time for certain task types. That tracks with what we saw. But the gains were concentrated in specific, well-defined stages: first-draft generation, assessment creation, formatting and structure work, and metadata. For nuanced scenario design, cultural adaptation, and complex technical content, AI consistently underperformed human judgment. We had one project where a Claude-generated draft was so confidently wrong about a technical procedure that it would have caused real problems if it had shipped. That project made us much more careful about where we deployed AI-generated content without heavy human review.

The model we landed on: AI handles the repeatable, well-defined tasks. Humans handle the judgment-intensive ones. The skill is knowing which is which. An ID writing a quiz question from scratch is a judgment-intensive task only at the level of deciding what to assess. The actual question generation? AI is faster and produces a solid starting point. An ID designing a branching scenario for a difficult manager conversation? That requires emotional intelligence and contextual understanding that AI can sketch but not deliver.

We also built a prompt library over about four months. Standardized prompts for common content types, tested and refined across projects. That investment (roughly 40-60 hours of ID time collectively) was what made AI actually reliable in our workflow. Off-the-shelf prompts produce inconsistent results. Prompts calibrated to your content type, audience, and quality standards produce something you can actually build from.

---

🗃️ The Approval Cycle Was the Hidden Bottleneck

For most of the year, our approval cycle was six weeks. Six weeks from "content complete" to "published in LMS." That number, more than any production metric, was the ceiling on our throughput.

Here's the math: if you're producing 12 modules a month but each one takes six weeks to get approved, you're either running a massive queue of content in limbo, or you're slowing production to match approval speed. We were doing both.

Compressing that to two weeks required three things. First, we moved to parallel review instead of sequential. Instead of ID-to-manager-to-legal in a chain, everyone who needed to review got it at the same time, with clearly defined scopes. The manager wasn't reviewing for legal compliance. Legal wasn't reviewing for instructional accuracy. Everyone had a lane, and they moved simultaneously.

Second, we set an escalation rule. If a review wasn't returned within the SLA window and no extension was requested, the content moved to the next stage. This felt aggressive when we proposed it. In practice, it was used maybe three times in the entire year. The existence of the rule changed behavior more than we ever needed to enforce it.

Third, and this is the one people don't expect: we shortened what we were submitting for approval. We stopped asking reviewers to go through full 40-minute courses at once and started getting sign-off on module-level chunks as they completed. By the time a full course went to final approval, most of it had already been approved in sections. The "final review" became a confirmation, not a first read.

Going from six weeks to two weeks added roughly 4 weeks of deployment capacity per project. On 637 modules, that's a significant amount of time returned to the pipeline. That compression probably contributed as much to our throughput as any production process change.

---

🧱 The Infrastructure Beneath the Machine

None of this works without visibility into what's in the pipeline. Before we built the production system, we built the tracking system. That order matters.

We used a project management platform to track every module: its status, its owner, its next action, its review stage, and its target deployment date. This was visible to the whole team, including business partners and senior leaders. Not just to project managers. To everyone who had a role in any part of the process.

That visibility did two things. It created natural accountability. If your review was overdue, it was visible to everyone, not just flagged in a private status meeting. And it gave us data. After three months, we could see exactly where projects were stalling most often. That data drove the process changes. We didn't guess that SME review was the primary bottleneck. We measured it.

Cognota's research on learning operations finds that teams operating above 85% capacity utilization are at burnout risk, and that 3+ months of demand exceeding capacity is common. We hit that wall in Q2. Having the tracking data let us see it coming and make a case to the business that we needed either more capacity or a more deliberate intake filter. Without that data, we'd have been reporting anecdote. With it, we were presenting evidence.

We also ran sprint retrospectives every two weeks. Not long meetings. Thirty minutes as a team: what finished, what's blocked, what's changing. The pattern surfacing from those retros over time was more valuable than any single retrospective. Problems that showed up twice in a row got structural fixes. Problems that showed up once got acknowledged and watched.

---

🤔 What We'd Do Differently

If I'm being honest about the year, there are three things I'd change.

We waited too long to formalize the triage framework. The first three months of chaos could have been avoided if we'd spent two weeks upfront designing the intake and prioritization system before we started scaling production. We treated that as administrative work. It was actually the most strategic work of the year.

We introduced AI tools too broadly, too fast. We let enthusiasm drive adoption before we had the quality gates in place to catch where AI was producing unreliable output. The right order is: define the use cases, build the prompts, test on low-stakes content, establish review protocols, then expand. We compressed those steps and paid for it with a few expensive rework cycles.

We underinvested in change management for the team. Scaling from 50 to 637 modules changes what the job looks like. IDs who were doing deep, long-form instructional design for a single project suddenly found themselves managing multiple shorter-cycle projects simultaneously. Some people thrived. Some found it disorienting. We didn't give that transition enough deliberate attention until we started seeing it in the quality of the work.

---

🎯 The One Thing to Do This Week

Before optimizing any production process, audit your content library for learning debt. Find every module with below-10% completion over the last 90 days and put them in a single list. That list is your capacity conversation: each module you retire or deprecate is time returned to building things that matter. Start there, before you touch a single tool or template.

---

If you've built a content operation at scale, or if you're in the middle of trying to, I'd really like to compare notes. What's the thing that surprised you most? Find me on LinkedIn.

-- Eian