Learning content in a large company has to keep changing, because the business it describes keeps changing. Products ship, processes move, and the people who knew why a course was built a particular way leave.
Most learning functions are set up to produce that content. Material gets made in bursts: a need is identified, budget is found, work is scoped, and a body of content is delivered. After that it will often sit there, because between those production bursts nobody formally owns it. And it goes out of date gradually rather than all at once (so no single month produces a problem big enough for anyone to raise). Eventually enough of it is wrong to justify another burst, and the cycle continues.
Breaking that cycle takes something material can’t supply: a route for changes in the business to reach the content, a person accountable for making that happen, and a working rhythm behind it. Those are all architecture questions.
How to tell a content problem from an architecture problem
A content problem sits in the material itself. The material is wrong, or thin, or out of date, and fixing the material resolves the complaint permanently.
An architecture problem can produce the same complaints as a content problem, which is why it often gets misdiagnosed. The material gets rebuilt, the complaints stop for a year or two, and then they start again.
Three questions usually settle which one a team is looking at.
Does the problem recur? Content problems stay fixed. If the same complaint returns two years after it was dealt with, the first fix treated a symptom.
Does adding people help? If the team doubles and the backlog doesn’t halve, headcount (and production capacity) was never the problem.
Where does the failure actually sit? A badly written course is a content problem. An update that never happened, a handover nobody owned, a task that was never assigned to anyone — these are architecture problems that sit ‘between’ the work rather than inside it.
What architecture problems look like in practice
Architecture problems don’t look the same from one company to the next. Across four engagements with global technology companies we have worked with, we saw the same underlying failure surface in four different places.
- Production. At a Fortune 100 networking company, certification content had to meet the standard set by its most senior certified engineers, keep pace with a technology portfolio that kept growing, and exist in four delivery formats. What was missing was a way to run certified experts and instructional designers in parallel without either one becoming a bottleneck for the other.
- Retrieval. At a global digital infrastructure company, the sales enablement material was accurate and current, and it sat in repositories the sales team couldn’t search during a live customer call. The content existed and never reached the conversation it was written for.
- Reuse. A large cloud partner organization ran its training as events. Sessions were built once, delivered once, recorded and uploaded, and the recording then counted as online training. Updating any of that library was slow enough that new material arrived more slowly than existing material went out of date.
- Measurement. At a global collaboration software company, partners passed the certification exam and still couldn’t be trusted to run an enterprise migration inside a maintenance window. The exam tested what they knew rather than what they could do under those conditions.
The arrangement around the material is what failed in each case: how content got produced, where it was stored, whether it was refreshed, and how readiness was checked.
More on these case studies in our blog: When Good Training Can’t Scale.
Three ways to get help with an architecture problem
Each of the following suit a different situation and come with different costs.
Build the capability internally. Hire or reassign someone to own the update route, the standards and the platform. The knowledge stays inside the business. The difficulty is funding a role whose main output is that nothing degrades, then protecting that person from being pulled onto whatever is urgent.
Buy a project. Professional services will get you bandwidth against a defined scope, with a team, a deliverable and an end date. This is the right instrument when the work genuinely has an end: a migration, a rebuild, a body of content that has to exist by a certain date. The limitation is structural. A brief gets written against whichever symptom hurt enough to require a paid solution.
Buy a managed service. In this case, the provider takes standing responsibility for something that runs, with a recurring fee, agreed service levels, a governance rhythm and a renewal. Somebody is accountable for the state of the content (rather than the delivery of a batch of it). This works only with recurring budget, a named internal counterpart, and a provider whose own delivery is mature enough to be measured.
Why teams usually default to project-based solutions
It’s simple math. Project budget is often easier to get than a recurring line, so a budget cycle with twelve months of visibility settles which model is chosen long before anyone examines the cause. Procurement is built to approve a scope, a price and a finish date. A managed contract needs service levels and governance terms agreed first, which takes longer and is harder to get signed off.
Personal risk matters too. If a project fails, the company loses a quarter. If a multi-year contract fails, the person who signed it is ultimately responsible. There is also what each request says about the team: asking for help to build something is routine, while asking someone else to run the work suggests the team cannot manage. That is a harder case to make to key stakeholders.
What to check before buying a managed service
Bought badly, the managed option can be worse than a project. We commonly hear of three types of failures:
- Governance becomes a formality. Governance is supposed to be the point where problems get caught and acted on. A managed services provider will regularly report on what got updated, what is overdue and where standards slipped — and both sides then decide what to do about it. When governance fails, the reporting continues but the deciding doesn’t. Content flagged as out of date one month is still out of date the next.
- The service levels measure the wrong thing. Service levels set out what the provider is accountable for. Most get written around speed: how quickly an update is turned around once somebody asks for it. That measures responsiveness, not accuracy. A provider can meet every deadline in the contract while the library falls further out of step with the product, because nobody agreed a standard for how current the content has to be.
- A good service can hide a broken process. Learning teams depend on other parts of the business telling them when something changes, and that handover often doesn’t work. A capable partner compensates by watching the product and updating content without being told. The complaints stop internally, so nobody looks at why the product team wasn’t passing changes over in the first place. The gap, howeve,r stays open, and the services arrangement becomes the only thing covering it.
When looking for a services provider, a solid track record is the only useful filter. A portfolio of delivered projects says very little about whether a provider can hold a service together over time. Look for evidence of success such as accounts held over years and long-term relationships, and multi-year use cases around how a service managed changing conditions, growth, and AI.
Breaking the cycle
Getting out of the cycle means forever up to date content so nothing has to be rebuilt again from scratch. Teams that manage this tend to do one thing first. They make the condition of existing content somebody’s job, and they report on it the way they report on delivery. Once that exists, choosing between building the capability, buying a project or buying a service becomes a practical question about scale and budget.
Sify Digital Learning provides professional and managed services to Fortune 100 technology companies, Get in touch to talk through which model your program needs.
