Every company that expands into new markets eventually learns the same thing. There is a gap between “we have a process for this” and “the process actually works when it matters.” That gap only becomes visible under pressure – a missed filing, a departing employee, an auditor’s question you cannot answer as quickly as you would like. At Glints, I run HR and payroll operations for teams across multiple countries. Over the years, I have had my own share of moments where that gap showed up. Some built up slowly. Others arrived without warning.
I could have treated these as one-off incidents and moved past them quietly. Instead I sat down with my team and asked a harder question – what do these moments have in common? What would have to be true structurally to stop them from repeating? A few patterns kept surfacing, and I think they are useful beyond our own walls. They apply to any organisation running people operations across multiple markets, whether in-house or through a partner. What follows is not really a checklist. It is closer to an argument – operational resilience gets designed in advance, not summoned in a crisis.
What Operational Resilience Looks Like in Practice
1. A Market is Only as Strong as Its Local Leadership
The earliest signs of trouble are almost never formal. A missed deadline here. A client comment there. A team member quietly mentioning that something feels off. On their own, none of these look like an escalation. Together, they are a pattern. And patterns only get caught by someone close enough to the ground to notice them, and senior enough to know they matter.
What makes this hard is that these signals rarely arrive labelled as urgent. A recruiter mentions someone seemed stressed in a meeting. A client asks the same question twice because the first answer did not quite land. Each one is easy to explain away on its own. That is exactly the problem. It is only in hindsight, once they are laid out together, that the pattern becomes obvious. The discipline is not about reacting to any single signal. It is about someone deliberately holding the whole picture, and being willing to say “several small things feel off” before there is one big thing to point to.
This is why every market needs an experienced local lead, not just a capable operator. Someone who has seen enough elsewhere to recognise a warning sign before it becomes a formal problem. Someone who feels able to raise it early, without first building an airtight case. That last part matters more than it sounds. If raising a concern early and turning out to be wrong carries real cost, people learn to wait until they are certain. By the time anyone is certain, the informal window has already closed. Regional or HQ oversight should reinforce that person’s judgment, not replace it, and should actively reward flagging things early even when they turn out to be nothing. The moment local ownership becomes purely reactive to instructions from above, you lose more than decision-making speed. You lose your earliest warning system, because the people closest to the signal stop bothering to send it up.
2. Institutional Knowledge has to Live in Systems, not in People
Even in well-run teams, it is common for a handful of critical, recurring tasks to be fully understood by exactly one person. It works fine until that person is unavailable, whether through leave, departure, or something more disruptive. Then everyone else is left reconstructing the process from fragments – half-updated documents, scattered credentials, and institutional memory that has walked out the door.
This is not a failure anyone can point to and fix in the moment. It builds up slowly, and nobody notices, because the person holding the knowledge is, by definition, doing their job well. Good performance quietly hides the risk. Teams tend to document the easy, stable parts of a process, the parts least likely to ever cause a problem. The messy, judgment-heavy exceptions are the ones that really matter when something goes wrong. Those stay undocumented, because they are harder to write down and do not feel urgent, until the day they suddenly are.
The fix sounds obvious, and it still gets skipped under the pressure of day-to-day delivery. Every critical, recurring process needs a current SOP, a clearly assigned owner, shared access (not personal access) to the systems and credentials it depends on, and a tracker that anyone on the team could pick up cold. But documentation alone is not the real test. A document nobody has tried to follow can look complete and still be useless. The test I now apply is more active – could someone who has never touched this process run it for a week, using only what is written down, with no side conversations to fill the gaps? Treat it like a fire drill. Run it on purpose, occasionally, rather than finding out the answer for the first time during a real emergency. If the honest answer is no, that is a gap worth closing before it gets forced on you. Closing it costs far less in a calm week than in a chaotic one.
3. Specialist Experience Pays for Itself Almost Immediately
I have noticed a consistent pattern across our markets. When I hire someone with real hands-on experience in the specific systems, regulations, or workflows a role requires, they do not just execute faster. They question things the rest of the team had stopped questioning. A process everyone assumed was “just how it is done” turns out to be an unnecessary manual workaround. A report that used to take hours to prepare by hand turns out to already exist, correctly formatted, inside the system the team was already using.
This is not simply because specialists work harder or know more facts. It is because they carry a mental library of what “normal” looks like, from having seen the same systems operate correctly elsewhere. That reference point is what lets someone spot an anomaly instantly, where a capable generalist would read it as routine. A generalist has nothing to compare it against except what they have always seen internally, and that internal baseline may already be the broken one. This is also why relying purely on internal training to grow someone into a specialist role is risky, for anything with real compliance or financial exposure. The learning curve of a specialist role is not a good place to discover a gap. You are asking someone to learn what normal looks like and keep live, high-stakes operations running at the same time, with no reference point to tell the two apart.
There is a flip side, and it is a real failure mode, not a hypothetical one. Specialists sometimes bring in practices from their last context that do not actually fit yours. A tool your team does not use. A regulatory assumption that applies elsewhere but not here. A workflow built for a scale you have not reached. The value of hiring a specialist is not “defer to their instincts blindly.” It is “give their pattern recognition a fast, deliberate onboarding into your specific context,” so their instincts get calibrated to your reality instead of their last one. Done well, this is one of the highest-leverage moves you can make with a team. Done carelessly, it just imports someone else’s blind spots into yours.
4. High-risk Activities Need a Real Second Set of Eyes, Before The Fact
Payroll runs, bank transfers, and statutory filings are exactly the kind of activities where a single point of failure is most costly. Yet it is easy for review to quietly turn into a formality. Someone signs off simply because someone else prepared it, without a genuine independent check of the purpose, the amount, and the supporting documents. The clearest sign this has already happened is when clarifying questions only get asked after a payment has gone out, instead of before it was approved.
This erosion follows a predictable shape, so it is worth watching for. It usually starts reasonably. A trusted colleague prepares something, a reviewer checks it thoroughly, and everything is fine. Over time, that repeated “everything was fine” becomes its own kind of evidence. The review quietly shifts from verifying the work to simply trusting the person, especially once the reviewer is stretched across too many approvals to genuinely examine each one. At that point, the sign-off still happens. The process on paper still says two people were involved. But only one set of eyes looked. You are left with the appearance of control and none of its substance – arguably more dangerous than having no control at all, because it creates false confidence.
A proper maker-checker process is not bureaucracy for its own sake, and it is not about trusting people less. It is a structural acknowledgment that everyone, however careful, has blind spots that a second, genuinely independent look can catch. For anything involving money leaving the company, the reviewer’s job is to verify against the source documents, not against the preparer’s summary of them, and to do it before release, not after a question happens to surface. Two small structural choices help keep this real instead of theoretical – rotate who reviews what, so no single pairing gets too comfortable with each other’s work, and keep each reviewer’s workload light enough that they can actually look, rather than skim.
5. Standardise by Default and Treat Every Exception as a Cost
When you manage operations across multiple markets or multiple clients, it is tempting to accommodate every preference. A custom report format here. A bespoke workflow there. Each accommodation feels small and reasonable on its own, and saying yes is almost always the path of least resistance in the moment. Over time, these add up. What should be a repeatable, teachable process turns into something only tenured team members can navigate. Every new hire has to relearn the exceptions from scratch, usually the hard way, by making a mistake first.
The trap is not that flexibility is bad. Some exceptions really are necessary, particularly where local regulation genuinely differs. The trap is that exceptions usually get granted without anyone deciding, in a considered way, that this particular case is worth the added complexity. Once granted, they are rarely revisited. What was meant to be a one-off accommodation quietly becomes permanent complexity. A year later, nobody remembers which exceptions still have a real reason behind them, and which have simply never been questioned since the day they were agreed to.
My rule now – standard workflows are the default everywhere. An exception only gets made where there is a genuine contractual or regulatory reason for it. It gets logged explicitly as an exception, rather than quietly absorbed into “how we do things,” and it gets revisited on a regular cadence, with a default expectation that it sunsets unless it is re-justified. That last part is the piece most teams skip, and it is the one that really stops exceptions from becoming permanent. Consistency is not just an efficiency play. It is what makes an operation resilient to people changing roles, because a standardised process transfers with the work, while an exception-riddled one only ever lives in someone’s head.
Why I Am Sharing This
None of these lessons are exotic on their own. Most HR and operations leaders would nod along to all five if you read them out loud. What is harder, and what I am being honest about here, is that knowing a principle is one thing. Having it actually hold under real pressure, in a market you are less familiar with, with people you have not worked alongside for years, is another. Each of these gaps was survivable because we caught them on time and had the resources to respond. The same gap in a smaller team, or in a market where you have even less on-the-ground context, can be a lot less forgiving.
That is a big part of why Glints TalentHub exists, as an Employer of Record and HR outsourcing partner across Southeast Asia and beyond. When you expand into a new market, you are not just solving for “can we legally hire here.” You are inheriting all five of these problems, plus the people-risk lesson, on day one, often without the local context to know where the risk actually sits or how quickly it can move. Working with a partner who has already run into these gaps, and has already built the systems, local leadership, and controls to close them, means you skip straight to operations that work the way they are supposed to. You do not have to pay tuition for lessons someone else has already learned.
I will keep sharing what I learn as I keep learning it. If you are navigating similar challenges scaling a distributed team, I would genuinely like to hear what has worked for you too.
