I’ve been building operations infrastructure since 2017. I found out much later what it’s called.
While I was in my second year at Nottingham, I reworked an assignment at my tutor’s request. After making changes, all the reference numbers in my document were out of order. I still passed, but the messy sequence bothered me for reasons I couldn’t quite explain.
I discovered Zotero, learned how to use it, and taught others. With it, I could reorganise my document as needed, and the reference numbers remained correct.
Since then, I’ve been drawn to solutions like that—ones that fix the problem at its source.
When I began my new job at a London-based luxury events company, my manager walked me through the building before introducing me to the systems.
Photo: Apothecaries’ Hall interior via Open House London / The Worshipful Society of Apothecaries
Stepping into the Great Hall at Apothecaries’ Hall always feels like a time warp—easily making it one of my absolute favourite livery halls to work at. Rebuilt immediately after the Great Fire of London in 1668, it stands as the oldest extant livery hall in the City of London, wrapped in original 17th-century oak panelling.
Sales cared most about speed. Every minute between a verbal agreement and a logged booking put the deal at risk. Event operations needed headcounts and dietary details before prep started because late information led to mistakes—such as incorrect kitchen orders, staffing briefs, or table counts. Accounts needed accurate invoice fields; otherwise, end-of-month reconciliation became a scramble across three departments.
She wasn’t telling me what people ought to care about. Instead, she was showing me what each team valued, what they were willing to compromise on, and what they would resist if I asked them to change their routines.
Back then, I hadn’t heard the term ‘stakeholder motivation audit.’ What I understood was simpler and, I think, more lasting: every important piece of information in the company had a place it needed to end up. There was always a gap between where it started and where it needed to go. Most of the time, no one had figured out how to bridge that gap.
So I created the path. I made sure the client brief had required fields so dietary information couldn’t be missed. I set up a structured handoff to the kitchen sheet so prep could start without a phone call. I designed table cards that showed the right information at the right time. The fields got filled in because I built the system around what each team needed, giving them what they needed before asking for anything in return.
Six months later, I moved on. The systems kept working without me.
I didn’t have a name for what I had built.
I kept noticing the same kinds of gaps everywhere I worked.
At BP Shipping, during my first graduate rotation, there were 69 vessels, 1 unanswered regulatory question, and a financial model I was asked to build before any investment decisions could be made. I built the model and handed it over.
At PwC, I worked with financial institution clients whose database extracts were messy: access records stayed open long after users left, and figures didn’t match the ledger. The real question wasn’t if the numbers were wrong. It was what the system behind those numbers looked like and why no one had mapped it yet.
At a Series A SaaS data startup in Lagos, I saw valuable knowledge walk out the door every time an analyst left. The real insight wasn’t in the reports. It was in the institutional knowledge that never got written down: patterns someone noticed but didn’t document or thresholds they watched for but never named. When those people left, their knowledge left with them.
At a heritage music non-profit I co-founded, we had 22 volunteers, no dedicated staff, and governance decisions made verbally, only to be disputed months later. I set up documentation before anyone asked because I knew what happened when institutional memory lived only in the people making decisions.
Different industries, different problems, but always the same gap between where information started and where it needed to go.
A few years ago, I started seeing this vocabulary in job descriptions.
Customer Success Operations. Revenue Operations. Product Operations. I started seeing terms like health scoring, data flow architecture, and onboarding instrumentation. When I read these, I felt a sense of recognition rather than surprise. These roles described the kind of work I naturally enjoy and notice everywhere.
Having the right words didn’t change what I could do. It just made it easier to explain—to a hiring manager, a client, or someone building a team and trying to describe what was missing. Before, my work only showed up in its results: the system that kept running, the process that lasted after I left, the record that outlived its creator. With the right vocabulary, the work became clear. I could point to it.
Now I see something I missed back in 2017: the gap between where information lives and where it needs to go isn’t just an operational issue. It’s also about trust.
If a system relies on one person’s availability, memory, presence, or judgement, it isn’t really a system. It’s a performance. It works when the performer is there but falls apart when they’re not. Most organisations have more performances than they realise. What looks like a process is really a performance—until the person leaves, at which point it becomes a gap.
A system earns trust because of the care put into its design: knowing which signals really matter, which data fields must be filled in, where information is most likely to get lost, and which metrics look right but measure the wrong thing. For example, a health score based on the wrong signals might give a customer success manager only 30 days’ warning before a renewal, instead of 90—or worse, give them false confidence. If no one compares contracted seat counts to active seat counts, an account might look healthy but actually be at risk of churn. The gap between these numbers is where revenue loss hides until someone points it out.
Now, before I design anything, I ask myself the same question I did in 2017, before I had the words for it: Where is the gap? What needs to cross it? What should the path be made of so it holds up when I’m not there?
I’ve spent nine years building paths that are meant to last after I’m gone.
Not because I always planned to leave—though sometimes I did. It’s because a path that depends on one person isn’t really a path; it’s a dependency. In operations, just like in engineering, you design around dependencies, not into them.
The vocabulary came later, but the instinct was always there.
Nobody had designed the path; I now know that was the job all along.