The Sankofa Principle: Why Your Digital Transformation Keeps Forgetting Its Purpose

What Happens When You Erase Institutional Memory in Pursuit of Innovation

By Chinenye Egbuna Ikwuemesi

Your organization announced digital transformation three years ago. Legacy systems would be replaced. Processes would be modernized. Everything would move to the cloud. The future was digital, agile, automated. The old ways were holding you back.

So you rebuilt everything. New platforms, new workflows, new tools. You migrated data, retrained staff, redesigned processes. The technology is modern. The interfaces are sleek. The architecture is cloud-native. By every technical measure, the transformation succeeded.

Except nothing works better than it did before.

Claims processing that took three days now takes five. Underwriters who could assess complex risks quickly now struggle with rigid workflows that do not accommodate nuance. Customer service representatives who knew how to solve unusual problems now follow scripts that break when situations do not match templates. The tribal knowledge that made your operation work has disappeared. The new system is technically superior but operationally worse.

You digitized the processes but lost the intelligence. You modernized the tools but erased the wisdom. You built the future by destroying the past without understanding what the past actually did.

I have watched this pattern repeat across twenty years in insurance technology. Organizations pursue digital transformation like it is inherently good, as if newer is automatically better, as if the old systems had no reason for being the way they were. They approach transformation as replacement rather than understanding. Then they wonder why adoption fails, why productivity drops, why the people who actually do the work are frustrated with solutions that were supposed to help them.

The problem is not the technology. The problem is that you forgot to look back before you moved forward.

What Sankofa Actually Means

In Akan culture of Ghana, Sankofa is represented by a bird with its head turned backward while its feet face forward, often carrying an egg in its mouth. The word means "go back and get it" or "return and fetch." The teaching is that you must understand your past to move forward effectively. Wisdom is not found only in what is new. The future you are building depends on knowledge from where you came.

This is not nostalgia. It is epistemological method. You cannot know what to preserve, what to change, and what to build new unless you understand what exists and why it exists that way. The egg the bird carries represents the future. Protecting that future requires remembering your source.

Western management theory treats history as burden. Move fast and break things. Disrupt or be disrupted. The past is legacy, and legacy is technical debt to be eliminated. This philosophy drives most digital transformation. Out with the old, in with the new. The assumption is that what exists is inferior simply because it is old, and what is new is superior simply because it is modern.

This assumption kills institutional knowledge. And institutional knowledge is often the only thing keeping your operation functional.

What Actually Lives in Legacy Systems

Your legacy insurance platform is twenty years old. The code is outdated. The interface is clunky. Younger developers refuse to work on it. Everyone agrees it needs replacing. The business case for modernization is obvious.

But that legacy system encodes twenty years of learned behavior. Every time an edge case broke the process, someone figured out how to handle it and the solution got built into the system. Every time a regulation changed, someone adapted the workflow. Every time customers complained about something, someone added a feature to address it. The system is not elegant because it was not designed. It evolved through contact with reality.

The underwriters who use it have developed profound expertise. They know which fields matter for which types of risk. They know when the system's recommendation should be trusted and when it should be overridden. They know the workarounds that make the clunky interface efficient for people who understand what they are doing. This knowledge exists in their heads, not in documentation, because it was learned through years of practice.

When you announce you are replacing this system, you are not just replacing technology. You are disrupting an entire ecology of knowledge. The official requirements gathering will capture the formal processes. It will not capture the informal intelligence that makes those processes actually work.

I watched this happen with an insurance transformation project. The new system was technically superior by every measure. Modern architecture, beautiful interface, better performance. But claims processing slowed dramatically after launch. Investigation revealed that the old system had accumulated hundreds of small adjustments that handled edge cases. The new system was designed for the happy path. When reality diverged from the happy path, which it constantly does in insurance, the system had no answers.

The underwriters knew how to handle these situations. But their knowledge was embedded in interaction with the old system. The new system operated on different logic. Their expertise did not transfer. They had to learn everything again from scratch while also learning new tools and new workflows. Productivity collapsed.

Management blamed change resistance. The real problem was that transformation destroyed institutional memory without understanding what was being destroyed.

Why Tribal Knowledge Matters More Than You Think

Organizations talk about tribal knowledge dismissively, as if it is primitive compared to documented process. Tribal knowledge is what the expensive consultant cannot capture because it is not written down anywhere. It is what makes your organization actually function despite the official processes.

Tribal knowledge is how experienced people know which rules to follow strictly and which rules to interpret contextually. It is how they know which customers are going to be difficult before the difficulty manifests. It is how they route unusual cases to the person who has solved similar problems before. It is the shortcuts that make clunky processes efficient. It is the relationships that get things unstuck when formal channels fail.

This knowledge is called tribal because it spreads through practice and relationship, not through documentation. Junior people learn it from senior people by watching and asking questions. It accumulates over years. It is valuable precisely because it is hard to formalize.

Digital transformation typically destroys this knowledge in three ways. First, by replacing systems that encoded learned behavior with systems designed from scratch. Second, by reorganizing teams so that experienced people are scattered and relationships that enabled knowledge transfer are broken. Third, by retiring or pushing out senior staff who carry institutional memory because they are expensive and resistant to change.

Then the organization discovers that the new system cannot handle situations the old system managed routinely. The documented processes do not work without the undocumented adjustments people made. The junior staff do not know what the senior staff knew. Problems that were previously solved quickly now escalate to management because no one remembers the solution.

You saved money on technology and headcount. You lost capability that took decades to build.

The Questions You Should Have Asked First

Before any digital transformation, there are questions that must be answered. These questions are rarely asked because the assumption is that transformation is inherently good and the details will work themselves out during implementation. This assumption is why transformations fail.

What problem does the current system actually solve? Not what it was designed to solve when it was built. What does it solve today, after years of evolution and adjustment? This requires observing how people actually use the system, not just reading requirements documentation from the original project. The current system may solve problems no one remembers creating a system to solve.

Why do people work the way they work? Every workaround exists for a reason. Sometimes the reason is that the system is badly designed and the workaround is purely defensive. But often the reason is that reality is more complex than the system anticipated and the workaround handles complexity the system cannot. If you eliminate the workaround without understanding what complexity it was handling, you create new problems.

What gets lost if we erase this and start over? Institutional memory lives in systems, in relationships, in practices that have become automatic. When you break everything at once, you lose knowledge that was embedded in the old patterns. Some of that knowledge was useless legacy that should be discarded. Some of that knowledge was critical capability that is hard to rebuild. You need to know which is which before you destroy it.

Where is the intelligence actually located? Official process documentation describes what people are supposed to do. Actual practice is often different because the documented process does not work in real conditions. The intelligence that makes things work despite bad process lives in people's heads and in their relationships. If you design new systems based only on documented process, you recreate the problems the unofficial practices were solving.

Who are the people who make this actually work? In every organization there are people who are not managers or subject matter experts officially but who everyone goes to when something breaks. They are the ones who remember how to handle the weird edge case. They are the ones who know which person in the other department can expedite something. They are the relationship nodes that make the informal organization function. If you reorganize without understanding who these people are, you break critical connections.

These questions take time to answer. They require humility to ask because they imply you do not already know what you need to know. Most transformation projects skip them because they are in a hurry to implement. Then they implement solutions that do not work because they did not understand what they were replacing.

How I Watched a Transformation Destroy Itself

I was brought into an insurance technology transformation after the new platform had launched and productivity had collapsed. Management could not understand why. The technology was superior. Training had been thorough. The design had followed best practices. But claims processing was taking twice as long as before and error rates had tripled.

I spent time with the claims adjusters actually doing the work. Within hours the problem was obvious. The old system had terrible interface and outdated technology but it had been tuned over fifteen years to handle the specific complexity of this company's products and customer base. The adjusters had learned to navigate it efficiently. They knew where every piece of information lived. They knew which fields would auto-populate based on other fields. They knew the sequence that made data entry fastest.

The new system was designed based on generic claims processing workflows. It was technically better but it did not match how this company actually worked. Simple tasks now required navigating through multiple screens where the old system had everything on one page. Fields that used to auto-populate now needed manual entry. Validations that used to catch errors before submission now triggered after the claim was already processed, requiring rework.

The experienced adjusters were trying to work the way they had always worked. The new system punished their expertise. Everything they knew about being efficient was wrong in the new environment. Meanwhile junior adjusters who had recently been hired had no experience with either system. They could not perform basic tasks without constant supervision because the institutional knowledge about how to handle unusual cases did not exist in the new system or in documentation.

I documented all of this and recommended either significant redesign of the new system to incorporate the intelligence from the old one, or a phased approach that preserved the old system for complex cases while gradually building capability in the new one. Management rejected both options. They had invested too much in the new platform to admit it was not working. They decided the solution was more training.

Training did not help because the problem was not user capability. The problem was that the new system was designed without understanding what the old system actually did or why people worked the way they worked. No amount of training fixes architectural mismatch.

Two years later the company was still using workarounds and unofficial processes to make the new system functional. The transformation had cost tens of millions and reduced capability. But no one in leadership would admit failure because they had committed publicly to the initiative.

This is what happens when you move forward without looking back.

What Sankofa Would Have Changed

If this organization had applied Sankofa principle, the transformation would have been different. Before designing the new system, they would have spent time understanding what the old system actually did beyond its official documentation. They would have observed experienced users working and asked why they worked that way. They would have mapped the tribal knowledge that made the clunky system functional.

This investigation would have revealed that the old system's terrible interface actually encoded valuable domain knowledge. The reason everything was on one screen was not bad design. It was learned behavior. Claims adjusters need to see multiple data points simultaneously to make good decisions. The single screen was ugly but efficient for experts. The new system's multiple screens looked modern but forced experts to remember information across contexts, creating cognitive load that slowed them down.

It would have revealed that the auto-population logic in the old system was not just convenience. It was error prevention developed through years of fixing mistakes. Certain combinations of policy type and claim type only made sense with specific coverage codes. The old system enforced these relationships invisibly. The new system required manual entry of every field, creating opportunities for errors the old system prevented.

It would have revealed that the experienced adjusters were not resistant to change. They were trying to maintain quality and efficiency standards the new system made difficult. Their workarounds were not sabotage. They were defensive adaptation by people who cared about doing good work.

With this understanding, the design could have preserved what worked while modernizing what did not. The new system could have been built to enhance expertise rather than negate it. The tribal knowledge could have been captured and encoded so it was not lost when senior people retired. The transition could have been managed so that capability was maintained throughout the change.

Instead, the organization treated the transformation as replacement. Out with the old, in with the new. The result was expensive failure that everyone was too invested to acknowledge.

How This Applies Beyond Insurance

Every industry has versions of this problem. Healthcare organizations replace patient record systems and lose clinical knowledge that was embedded in old workflows. Financial services modernize trading platforms and lose the edge cases that experienced traders handled intuitively. Government agencies digitize services and lose the ability to handle situations that do not fit standardized processes.

The pattern is consistent. Organizations pursue digital transformation as if technology alone solves problems. They design based on documented requirements without understanding actual practice. They assume that what exists is inferior and what is new is superior. They move fast, break things, and discover that what they broke was more important than they understood.

Then they face a choice. They can acknowledge that transformation destroyed valuable capability and invest in recovering what was lost. Or they can insist that the transformation is working and blame users for not adapting properly.

Most organizations choose the second option because the first requires admitting expensive mistakes. So they live with reduced capability, higher error rates, frustrated staff, and systems that are technically modern but operationally inferior. They call this innovation.

Sankofa teaches different approach. Before you transform, understand what you have. Before you replace, know what you are replacing and why it exists that way. Before you move forward, look back to see what you need to carry with you into the future.

This does not mean never changing. It means changing with intelligence instead of ideology.

What Organizations Should Do Instead

Digital transformation should start with archaeology, not architecture. Before you design new systems, excavate understanding of current systems. Not just the technical specifications. The actual usage patterns, the tribal knowledge, the workarounds, the edge cases, the relationships that make things work.

This requires different questions than typical requirements gathering asks. Do not just ask people what they need. Ask them what they do when the system does not work. Ask them what they know that is not written down anywhere. Ask them who they go to when they encounter unusual situations. Ask them what they worry about losing in the transformation.

The answers reveal where intelligence actually lives in your organization. Some of that intelligence should be preserved. Some should be improved. Some should be discarded. But you cannot make intelligent decisions about what to keep and what to change if you do not understand what exists.

You should also identify the people who carry critical institutional knowledge. These are not always the people with impressive titles or the longest tenure. They are the people everyone depends on when things break. In transformation planning, these people should be protected. Their knowledge should be captured. Their input should guide design. If transformation makes their expertise obsolete, you are probably destroying valuable capability.

You should design transitions that preserve capability throughout change. This usually means phased approaches where new and old systems coexist temporarily. Yes, this is more complex than ripping everything out and starting fresh. It is also more likely to succeed. Running parallel systems creates learning opportunity. Users can compare approaches. Designers can see what works and what does not. Problems can be fixed before the old system is completely gone.

Most importantly, you should measure transformation success by capability maintained or improved, not by technology deployed or processes documented. If your new system is technically superior but operationally worse, the transformation failed. If productivity drops, error rates increase, and experienced people are frustrated, the transformation failed. The question is not whether you implemented modern technology. The question is whether your organization can still do what it needs to do, better than before.

This requires honesty about outcomes that many organizations are not willing to practice.

The Real Cost of Amnesia

Organizations that forget their past face predictable problems. They make mistakes that were already solved. They recreate solutions that already exist. They destroy capability they do not realize they have. They lose competitive advantages that were embedded in practice rather than documented in strategy.

This is expensive in obvious ways. Failed transformations cost money. Reduced productivity costs money. Higher error rates cost money. Employee turnover costs money when frustrated experts leave.

It is also expensive in subtle ways. When you demonstrate that institutional knowledge is not valued because you destroy it in pursuit of innovation, people stop building it. Why invest years learning how to handle complex situations if that expertise becomes obsolete whenever technology changes? Why develop deep understanding of your domain if surface knowledge of new tools is what gets rewarded?

Organizations that repeatedly demonstrate that experience does not matter end up with workforces that lack depth. Everyone knows the current system. No one understands why things work the way they work. When new problems emerge, no one has context for solving them. The organization becomes dependent on consultants and vendors because internal capability has been systematically destroyed through transformation after transformation.

Then leaders complain about lack of innovation, about inability to respond to change, about needing to hire expensive outsiders for knowledge that should exist internally. They do not connect these problems to their own transformation philosophy. They do not recognize that treating history as liability rather than asset creates organizations with no memory and therefore no wisdom.

Sankofa teaches that you cannot build sustainable future by erasing your past. The bird looks backward for a reason. The egg it carries needs protection. That protection comes from understanding where you came from.

How to Know If You Need This

Your digital transformation probably needs Sankofa perspective if you recognize these patterns. Your new system is technically better but people find ways to avoid using it. Your experienced staff are frustrated while your junior staff are overwhelmed. Simple tasks that used to be quick now take longer. You have more process documentation than ever but people constantly ask how to handle unusual situations.

Your transformation team keeps discovering requirements that were not in the original scope because they are finding problems the old system handled that the new system does not. Your training programs are not working because the issue is not that people do not understand the new system, the issue is that the new system does not understand the complexity of your work.

Your error rates increased after transformation even though the new system has better validation. Your customer satisfaction declined even though the new system has better features. Your best people are leaving even though you invested in modern tools specifically to retain talent.

These patterns indicate that transformation destroyed institutional knowledge without understanding what was being destroyed. Recovery is possible but it requires acknowledging the problem first.

What Needs to Happen

You need someone to do the archaeology before more transformation happens. Someone who can observe how work actually happens, document tribal knowledge, identify where intelligence lives, and assess what was lost in previous changes. This is not requirements gathering. It is institutional knowledge recovery.

Then you need honest assessment of whether your transformation philosophy is sustainable. If every change destroys capability that takes years to rebuild, eventually you have no capability left. If the organization has been through multiple transformations that all followed the same pattern of erasing the past to pursue the future, you have probably created an amnesia machine.

If the assessment reveals significant lost capability, you have choices. You can try to recover what was lost by capturing knowledge from remaining experienced people before they leave or retire. You can redesign systems to handle the complexity that current systems miss. You can change how you approach transformation so that future changes preserve rather than destroy institutional intelligence.

Or you can continue as you are, launching transformation after transformation, each one destroying more knowledge, until the organization has no memory of how to do anything well.

One path is difficult but leads to organizational learning. The other path is easy but leads to permanent amnesia.

I help organizations do the archaeology that reveals what they forgot in pursuit of innovation. Five days of investigation maps institutional knowledge, identifies capability lost in previous transformations, and determines whether recovery is possible or whether damage is permanent. Then you decide whether to invest in recovery or accept that your organization has amnesia as its operating model.

If your transformation made things worse despite better technology, if your experienced people are frustrated with systems that were supposed to help them, if you are constantly discovering problems the old system handled that the new system does not, contact me. You need to understand what you forgot before you forget more.

'Go back and fetch it!'

About the Author

Chinenye Egbuna Ikwuemesi has spent twenty years in technology transformation across insurance, finance, and government. Her work applies African knowledge systems to modern organisational challenges, helping organisations understand what they are destroying before they destroy it. Learn more at chinenye.co.uk, afrodeities.org, and africanmythology.com.