There’s a peculiar kind of silence that lingers in organisations that run purely on legacy knowledge. It’s not the silence of inactivity—it’s the silence of familiarity. Everyone knows what to do, but no one quite knows how they know it. Things just work—until they don’t.
When I first walked into such an environment, the company had been operating for decades without structured documentation. Processes were embedded in people, not paper. The ones who “knew how things worked” had been there for years, sometimes decades. SOPs, process maps, reference manuals are presented like habits, muscle memory, and the occasional Excel sheet that everyone swore was “the latest version.”
Gulp!
As someone whose professional grounding has always revolved around building structure, I have always believed that institutional excellence begins with clarity. But clarity doesn’t appear on its own—it needs to be designed, validated, and communicated. My mission was to turn tacit knowledge into explicit systems: to write the SOPs that never existed.
How did I do that?
Step 1 – Understanding the Unwritten
Before writing a single word, I needed to understand the unwritten rules. I learned quickly that legacy organisations don’t resist documentation because they’re careless—they resist it because it threatens the familiarity that makes their work feel stable.
So instead of starting with templates, I started with people. I spent time shadowing teams—sitting beside coordinators, analysts, and trainers; listening to how they explained things to new hires; and noting down what they did differently from what others claimed to do. These were not formal interviews but conversations of trust.
When I asked, “How do you usually do this?”, the answer often began with, “Normally we…” followed by a mix of “but sometimes…” and “it depends.”
That was my first insight — the SOPs didn’t just need to document the process; they needed to capture the logic behind the decisions.
Step 2 – Mapping the Chaos
Legacy processes are rarely linear. They grow organically—layer by layer, patch by patch. To make sense of them, I used a bottom-up process mapping approach.
Rather than starting with a departmental workflow, I identified process clusters—recurring patterns of activities that led to specific outcomes. For instance, in a learning operations environment, “course activation” could involve HR, content, logistics, trainers, and even finance. Everyone had a hand in it, but no one owned the end-to-end picture. Using visual process maps (I prefer Lucidchart or Miro), I traced each step as it was currently done, not as it should be done. That distinction was crucial. Documenting “ideal processes” too early can alienate those who actually run them. By mapping the reality first, I earned credibility, and most importantly, people saw that I wasn’t here to “change everything,” but to understand.
Once the as-is map was complete, I would gather the stakeholders in short, focused sessions to validate it. This often led to surprising discoveries: redundant approval loops, outdated forms, or responsibilities that had shifted over time without anyone realising it.
Step 3 – Defining Ownership and Accountability
In companies that run on legacy knowledge, ownership is fluid.
“We’ve always done it this way” often translates to “we’re not sure who’s in charge.”
So, the next step was to clarify process ownership. Every SOP, no matter how simple, needed to answer one key question – Who owns this process from start to end? This was not a matter of hierarchy—it was a matter of clarity. For example, if a process involved four departments, one had to be the process owner (responsible for ensuring compliance and improvement), while others were contributors.
Introducing this concept wasn’t easy. It required diplomacy and empathy. In some cases, it meant revisiting turf boundaries. But over time, people began to see the value—when ownership was clear, so were expectations.
Step 4 – Writing for the Reader
Once the groundwork was set, it was time to write.
I believe that SOPs are not just documents—they are learning tools. They need to be simple enough for a new hire to follow yet detailed enough for an auditor to verify. So, I structured each SOP with three key sections:
- Purpose and Scope – Why the SOP exists and what it covers.
- Roles and Responsibilities – Who does what, clearly stated.
- Step-by-Step Procedure – The actual process, written in a concise, active voice, supported by visuals or decision trees when needed.
For each procedure, I included “critical control points”. These are steps that could impact compliance, customer experience, or data accuracy. These would help transform the SOP from a static manual into a dynamic quality tool.
Step 5 – Validation and Continuous Feedback
No SOP should ever be written in isolation. Once drafts were ready, I organised validation walkthroughs, for example, live sessions where process owners would perform the tasks using the draft SOP as their guide.
This was often where the magic happened. Watching someone struggle to find a step or interpret an instruction revealed exactly where the SOP failed to communicate. One of the most important lessons I learned was this:
“The effectiveness of an SOP is not in how it reads, but in how it guides”.
Through each round of feedback, bear in mind that the documents will evolve not only in accuracy but also in voice, gradually beginning to sound like the people who use them rather than like corporate templates written by outsiders.
Step 6 – Implementation and Change Management
Documentation is the easy part. Adoption is the real challenge. I quickly learned that rolling out SOPs is a change management exercise, not just a documentation project. Legacy organisations have muscle memory and changing that requires more than a PDF upload to the shared drive.
To encourage adoption, I used three key strategies:
- Microlearning orientation: Short sessions introducing each SOP and why it mattered.
- Champion system: Appointing process champions within departments to answer questions and reinforce consistency.
- Feedback loop: Creating a formal channel (e.g., monthly review form or MS Teams chat) for users to flag inconsistencies or propose improvements.
Over time, what started as a documentation initiative evolved into a culture of accountability. Teams began using SOPs as a reference, not as a chore. The technical steps are one thing, but the human side was the real learning curve.
I remember one senior staff member telling me, “I’ve been doing this for 15 years. I don’t need an SOP to tell me how.” She was right, in a way. She didn’t need it—but the organisation did.
Even my own boss, once said, “SOPs are a waste of time – everyone already know how to do it from the back of their head. The rest should learn the same way – we don’t need to spoon-feed them!“
This moment reminded me of the delicate balance between respecting expertise and institutionalising knowledge. The goal was never to replace people’s experience, but to preserve it—so that when they move on, retire, or change roles, the organisation doesn’t start from zero again.
Through empathy, consistent communication, and genuine curiosity, I began to see attitudes shift. When people felt heard, they became open to documenting their own workflows. Some even took ownership by proposing improvements or volunteering to pilot-test new templates.
The success of an SOP initiative CANNOT be measured only by the number of documents completed. Real impact shows up in how people work differently.
At the end, what does success look like here?
- New joiners were able to onboard faster.
- Cross-departmental miscommunications reduced because everyone now had a shared reference.
- Quality checks became easier because expectations were clear.
- Most importantly, decision-making became more transparent.
Imagine, ISO auditors reviewing the documentation, and commented that your SOPs “reflected how people actually worked,” not just theoretical procedures.
That, to me, is the ultimate validation.
Writing SOPs in a legacy-driven company is less about writing and more about translating culture into structure. Writing SOPs is not just a technical task—it’s an act of transformation. You are, in essence, building the bridge between legacy and sustainability.
What began as a documentation project often turns into a cultural awakening. You start by asking, “How do you do this?” and end up uncovering why things are done this way. Along the way, you learn that documentation is not about control—it’s about continuity.
For me, this experience reinforced a belief I’ve always held – operational excellence begins with clarity, and clarity begins with people.
The most meaningful SOPs I’ve written were not those that ticked every compliance box, but those that gave people a sense of structure, pride, and confidence in their work. They became, in many ways, a mirror of the organisation’s collective wisdom—finally captured, finally shared, and finally ready to evolve.
Leave a Reply