Case Study 2 — Meridian Insurance Group: The Company That Didn't Do Knowledge Transfer

The Warning Signs Nobody Heeded

Meridian Insurance Group was, by every external measure, a well-run mid-size insurance company. Founded in 1962 and headquartered in Hartford, Connecticut, Meridian served 3.2 million policyholders across 18 states. Its mainframe-based policy administration system — POLARIS — had been in continuous operation since 1984, processing premiums, claims, and policy changes with the quiet reliability that mainframe systems are known for.

What Meridian's management team did not see — or chose not to see — was that POLARIS's reliability was not a property of the code or the hardware. It was a property of the people who maintained it.

By 2019, Meridian's mainframe team had dwindled to six people:

The average age was 53.7 years. Five of the six were within ten years of retirement. Carlos Rivera, the sole junior developer, had been hired in 2017 after a two-year vacancy — Meridian's first mainframe hire in a decade.

The warning signs were unmistakable:

2016: Harold Becker, in his annual performance review, wrote: "I strongly recommend that Meridian begin a formal knowledge transfer program for the POLARIS system. I am 60 years old. Tom is 57. Neither of us has a successor. If we leave simultaneously — through retirement, illness, or any other cause — Meridian will lose the ability to maintain and operate its core system." His manager noted the recommendation and took no action.

2017: Meridian hired Carlos Rivera to begin building bench strength. Carlos was eager and capable, but the team was too busy with operational work to invest in his training. He learned by reading code and asking questions when senior staff had time — which was rarely.

2018: Tom Jennings requested funding for a DB2 knowledge transfer initiative — two weeks of structured sessions where he would document and teach his DB2 administration knowledge. The request was denied because "Tom isn't going anywhere." Tom, whose wife had been diagnosed with a chronic illness, had privately begun thinking about early retirement.

2019: Meridian's CTO commissioned a technology modernization study. The study recommended a cloud migration for POLARIS. The senior mainframe team warned that the study significantly underestimated the complexity of the business logic embedded in 4 million lines of COBOL. Their objections were overruled. The cloud migration project was approved with a two-year timeline and a $15 million budget.

The Unraveling

The unraveling began in March 2020, when the pandemic disrupted everything. The cloud migration project, dependent on in-person workshops and on-site vendor consultants, ground to a halt. Meanwhile, POLARIS — the "old" system that was supposed to be replaced — experienced unprecedented transaction volumes as policyholders filed claims and requested policy modifications.

June 2020: Harold Becker, working from home, suffered a heart attack. He survived but was unable to work for four months. During his absence, the team realized how much operational knowledge lived exclusively in Harold's head. Three production incidents that Harold could have resolved in minutes took days because no one else understood the affected subsystems.

September 2020: Tom Jennings gave three months' notice of retirement. His wife's condition had worsened, and he wanted to be home with her. Meridian offered a retention bonus; Tom declined. "It's not about money," he told his manager. "I need to be with my family."

December 2020: Tom retired. His DB2 knowledge — 32 years of configuration decisions, performance tuning expertise, vendor relationships, and system-specific know-how — walked out the door with him. No formal knowledge transfer occurred. Tom spent his last two weeks writing documentation that covered basic operational procedures but could not capture the depth of his expertise.

Tom's departure documentation was 47 pages long. When Priya Ramachandran, an external DB2 consultant hired to replace Tom's expertise, reviewed it, she described it as "a map drawn from memory by someone driving at highway speed. The major landmarks are there, but the details — the turn-by-turn directions that actually get you where you need to go — are missing."

March 2021: Harold Becker returned to work, but at reduced capacity. He could no longer handle the 60-hour weeks that had been his norm. Management asked him to "focus on the most critical items." They did not ask him to focus on knowledge transfer, and Harold, overwhelmed by the backlog that had accumulated during his absence, did not volunteer.

August 2021: Elaine Cooke retired. Like Tom, she gave notice and left without a formal knowledge transfer. Her CICS knowledge — the only CICS knowledge at Meridian — departed with her. The team was now four people: Harold (reduced capacity), Diane, Frank, and Carlos.

November 2021: The cloud migration was officially cancelled after spending $8.3 million with less than 10% of the migration complete. The vendor's post-mortem attributed the failure to "unanticipated complexity in the legacy business logic." Harold's team had predicted this exact outcome two years earlier.

The Consequences

With the cloud migration abandoned and the mainframe team reduced to four people (only three of whom had significant experience), Meridian began to experience the consequences of knowledge loss:

Increased Incident Frequency and Duration

In 2019, POLARIS experienced 7 production incidents with an average resolution time of 45 minutes. In 2022, the number rose to 23 incidents with an average resolution time of 4.2 hours. The incidents were not caused by system degradation — POLARIS itself was as reliable as ever. They were caused by human actions: changes made without understanding the system's implicit dependencies, configurations modified without understanding the historical rationale, and problems diagnosed slowly because the team lacked the pattern recognition that senior experts had developed over decades.

The most costly incident occurred in April 2022, when a routine DB2 utility job was run with incorrect parameters. Without Tom Jennings's knowledge of the specific DB2 configuration, the team used default parameters that were inappropriate for Meridian's environment. The utility corrupted an index on the policy master table, making the table inaccessible for 11 hours. During that period, Meridian could not process any policy changes, claims, or customer inquiries.

The incident cost Meridian an estimated $2.1 million in direct costs (emergency consulting, overtime, customer credits) and an immeasurable amount in customer trust.

Regression Errors

In September 2022, a COBOL program modification introduced a regression in the premium calculation for policies issued before 2001. The program had a special calculation path for these older policies, based on a regulatory requirement that Diane Marsh remembered vaguely but could not explain in detail. Without Harold's complete understanding of the historical context (he was on medical leave again), the developer who made the modification — a contractor — removed the special path as "dead code."

The error was not detected for six weeks. During that time, 12,400 policyholders received incorrect premium notices. The correction required individual recalculation of each affected policy, manual notification letters, and a regulatory filing. Total cost: $1.8 million.

Vendor Relationship Degradation

When Meridian's IBM software license renewal came up in 2022, no one on the team understood the pricing model well enough to negotiate effectively. Harold had handled vendor negotiations for twenty years; with him on reduced capacity and focused on operations, no one filled the gap.

Meridian accepted IBM's proposed renewal terms without meaningful negotiation. A subsequent audit by an external consultant determined that Meridian was paying approximately $400,000 per year more than necessary because of pricing model changes they had not taken advantage of — changes that Tom Jennings had been tracking before his departure.

Project Delivery Stagnation

By 2023, Meridian's ability to deliver new mainframe capabilities had essentially stopped. The remaining team could barely keep the lights on; enhancements were out of the question. Business requests for system changes accumulated in a backlog that grew by 15 items per month and shrank by 2.

The CTO, in a board presentation, described the situation: "We have a system that serves 3.2 million policyholders, processes $4.8 billion in premiums annually, and is maintained by a team of four people, only two of whom have deep expertise. Our system is not failing — it is frozen. We cannot change it without unacceptable risk, and we cannot replace it without expertise we no longer have."

The Recovery Attempt

In January 2023, Meridian's board approved a $5 million emergency program to address the knowledge crisis. Priya Ramachandran, the external DB2 consultant who had been brought in after Tom's departure, was asked to lead the effort.

Priya's assessment was blunt:

"You cannot recover knowledge that has left the building. Tom's DB2 expertise is gone. Elaine's CICS knowledge is gone. What you can do is stabilize what remains — Harold and Diane's knowledge — and begin rebuilding. But it will take three to five years and cost far more than it would have cost to do knowledge transfer proactively."

The recovery program included:

Emergency knowledge capture: Intensive sessions with Harold and Diane to document as much of their remaining knowledge as possible. Harold, now 66 and in declining health, participated for 10 hours per week. The sessions were recorded, producing approximately 80 hours of video content.

External expertise: Hiring three experienced mainframe consultants at $250/hour to fill immediate knowledge gaps. Annual cost: approximately $1.5 million.

Accelerated training: Sending Carlos Rivera and two new hires to intensive mainframe training programs. Cost: $120,000 per person.

Vendor re-engagement: Hiring an IBM pricing consultant to renegotiate the software license and recover lost savings.

System documentation: A six-month initiative to document POLARIS's architecture, business rules, and operational procedures from the ground up — work that should have been done incrementally over years.

The Reckoning

By 2025, Meridian had spent approximately $12 million on the recovery program — more than it would have cost to run a proactive knowledge transfer program for a decade.

The results were mixed. The system was stable, the immediate knowledge gaps were partially filled, and the new staff were developing capability. But significant knowledge had been permanently lost:

• Tom Jennings's understanding of the DB2 optimization history — which configuration changes produced which results, and why the current configuration is specifically tuned for Meridian's workload patterns — was unrecoverable.
• Elaine Cooke's knowledge of CICS transaction routing and session management — built over 26 years of troubleshooting — was gone. The consultants could maintain the current configuration but could not explain why it was designed that way.
• Harold Becker's deep understanding of the business rules embedded in the oldest COBOL programs — rules written in the 1980s by developers who retired in the 1990s — was partially captured but inevitably incomplete. Harold's health continued to decline, and he could not always recall details that he once knew instantly.

Priya Ramachandran's final assessment:

"Meridian will survive. POLARIS will continue to run. But the system is now a black box to the people who maintain it. They can operate it, but they do not truly understand it. When something goes wrong in an area where the institutional knowledge was lost, they will respond slowly and expensively. And there are business rules embedded in this code that no living person can explain. Those rules will be treated as immutable — not because they should never change, but because no one understands them well enough to change them safely."

What Meridian Got Wrong

The Meridian case study is not a story of negligence. Meridian's managers were not malicious or incompetent. They were busy, focused on immediate priorities, and operating under a set of assumptions that turned out to be wrong:

Assumption 1: "Our people aren't going anywhere." Harold was 60 in 2016. Tom was 57. Their retirements were not surprises — they were actuarial certainties. But management treated them as unlikely future events rather than planning horizons.

Assumption 2: "We can replace expertise with documentation." Tom's 47 pages of documentation, produced in two weeks, could not capture 32 years of DB2 expertise. Documentation is a supplement to knowledge transfer, not a substitute for it.

Assumption 3: "The cloud migration will solve the problem." By betting everything on replacing the mainframe, Meridian neglected to preserve the knowledge needed to maintain it. When the migration failed, they had neither the new system nor the expertise to sustain the old one.

Assumption 4: "Knowledge transfer can wait." Every year that Harold recommended a knowledge transfer program, it was deferred in favor of more immediate priorities. Each deferral seemed rational in isolation; cumulatively, they were catastrophic.

Assumption 5: "We can hire expertise when we need it." External consultants at $250/hour could fill immediate operational gaps but could not replace institutional knowledge. They could maintain the system; they could not explain it.

The Financial Analysis

The total cost of Meridian's knowledge loss, estimated by Priya Ramachandran:

Compared to the estimated cost of a proactive knowledge transfer program:

The proactive program would have cost approximately $450,000 per year. The reactive recovery costs approximately $7 million per year. The return on investment for proactive knowledge transfer is approximately 15:1.

Or as Harold Becker put it, less diplomatically: "They saved $450,000 a year by not doing knowledge transfer. Now they're spending $7 million a year because they didn't. That's not a budget decision. That's a cautionary tale."

Discussion Questions

1. At what point should Meridian's management have acted on Harold Becker's 2016 warning? What organizational dynamics cause warnings like this to be ignored? How can similar warnings be made more effective?

2. Tom Jennings's departure was accelerated by personal circumstances (his wife's illness). How should organizations plan for unplanned departures of critical knowledge holders? What is the difference between planning for retirement and planning for sudden departure?

3. The cloud migration project consumed $8.3 million and failed. How did the failure of this project interact with the knowledge crisis? Could the migration have succeeded with better knowledge transfer? Or was the migration itself a symptom of the same management failure?

4. Priya Ramachandran describes POLARIS as a "black box" to its current maintainers. What are the long-term consequences of operating a critical system that no one fully understands? How does this differ from a system that is well-understood but technically outdated?

5. Calculate the ten-year cost differential between Meridian's reactive approach and a proactive knowledge transfer program started in 2016. What non-financial costs should be included in this analysis?

6. Harold Becker recommended a knowledge transfer program annually for at least three years before any action was taken. What organizational changes would make it more likely that such recommendations are acted upon? Consider incentive structures, governance models, and risk assessment practices.

7. Carlos Rivera was hired in 2017 but received minimal training due to the team's operational workload. Design an alternative onboarding and development plan for Carlos that could have been implemented within the constraints of the team's workload. What tradeoffs would be required?