On building a full-stack career in Trust and Safety — from the moderation queue to platform governance, and why the path through the bottom matters.
My first job in Trust and Safety was content moderation. The job description was straightforward: review content, apply the guidelines, make a call. Two thousand five hundred cases a day. I didn’t write the policy, build the tool, or set the thresholds. Someone else had made those decisions. My job was to execute them accurately and quickly enough that the metrics held.
It was entry-level work. It was also one of the more instructive things I’ve done.
The gap nobody talks about
Every enforcement decision made at the policy level eventually reaches a person — or a model trained on decisions made by people — who has to apply it to something real, ambiguous, and time-pressured. Whether that application holds depends on how well the original decision translated into something workable at scale.
Most of the time, it doesn’t translate cleanly. Guidelines written by policy teams are coherent in the abstract. In practice, edge cases multiply. The guidance that held up in a workshop falls apart at case 1521 when the content in front of you fits three categories at once and the shift isn’t over.
Working the queue means seeing this before anyone with the authority to fix it has noticed. The failure mode is visible from inside before it surfaces in any metric.
Most T&S professionals are handed one layer of the enforcement chain and asked to make it work. I worked every layer, in order, from the bottom up.
Building the stack, one layer at a time
After moderation came training. The job was to transmit policy to the people who would apply it. What that revealed quickly: the parts of the policy you only think you understand become obvious when you have to explain them. Teaching requires precision that application doesn’t always demand. You can’t gesture at ambiguity in front of a room of new hires. You have to say what the rule is, why it exists, and what to do when the case in front of you doesn’t fit the template.
From training I moved into disputes — the function that handles the cases the standard framework didn’t catch. Disputes is where the system’s failure modes become legible. Each escalation is a data point: the policy was unclear here, the tool didn’t surface the right context there, the guidance was internally consistent but inconsistent with what users actually experienced. After enough of them, you have a map of where the seams are.
The full-stack arc
01 - Content Moderation Enforcement at scale — where policy meets reality
02 - Process Training Translating policy into operational knowledge
03 - Disputes & Escalations Mapping where the system breaks down
04 - Quality & Workforce Management Owning the system that produces outcomes
05 - Platform Policy Governance Writing the frameworks I used to work under
06 - TnS Program Management Trust architecture end-to-end
Quality and workforce management was the layer where the frame shifted. At Shopee, the team was handling 250,000 cases a day across in-house and vendor operations. The relevant question was no longer whether an individual decision was correct. It was whether the system was producing consistent decisions and whether there was enough visibility to catch it when it wasn’t. That requires a different mode of attention — away from instances, toward distributions.
When I finally wrote the policy
By the time I was writing enforcement frameworks at TikTok, I had spent years working under frameworks written by people who had not done the jobs I had. That’s not a criticism — policy and operations draw on different skills, and the experience isn’t always transferable or necessary. But it produced a different approach.
Writing enforcement guidelines, I was writing for a specific person: the moderator at case 800, mid-shift, looking at something that doesn’t fit. I knew which questions the policy needed to answer because I had been the person asking them. I knew which kinds of ambiguity would produce inconsistency at scale because I had seen where it broke before.
What this means, practically
A policy decision has operational consequences. A tooling gap has policy consequences. A vendor quality failure has user experience consequences that eventually become regulatory ones. These are connected. The connections are visible from inside more than one point in the chain.
Most T&S professionals develop depth in one layer. That depth is useful. What’s rarer is range — the ability to see how a decision at one layer produces a problem three layers away. That’s not something you reason your way into. It comes from having worked the problem from multiple positions.
What I’ve built over seven years is not a specialty. It’s a map of the system. That turns out to be a different kind of useful.
The best T&S professionals I’ve worked with share one quality that has nothing to do with seniority: they treat every case as a signal about the system that produced it, not just a decision to be made. That instinct is available at every level of the enforcement chain. It doesn’t require a title. It requires paying attention to the right thing.