Writing · Safety by design and operations

You can't moderate your way out of a systems problem

One of the biggest mistakes companies make with Trust & Safety is treating it primarily as an operations function.

Hire moderators. Write policies. Build escalation queues. Respond when something goes wrong.

Those things are necessary.

But at scale, you cannot moderate your way out of a systems problem.

Trust & Safety has to become part of the product architecture. That means moving beyond individual moderation decisions and designing systems that understand risk across the entire user journey.

Reputation, account history, age, behavioral signals, content signals, prior enforcement, and appeals should not exist as disconnected workflows. They should inform a broader risk model that helps determine how the platform responds.

The same is true for automation. The challenge is not simply building a classifier or automating more moderation decisions. It is knowing where automation should act, where it should escalate, and where human judgment is worth the cost.

Over the last several years, I’ve worked across moderation operations, policy, child safety, investigations, compliance, and product.

The biggest lesson I’ve taken from that work is that mature Trust & Safety programs are not built around a moderation queue.

They are built around systems.

Reputation systems that change how risk is evaluated. AI-assisted moderation that surfaces content and behavior humans would otherwise never see. OCR, audio transcription, behavioral signals, and content classification working together instead of operating as isolated tools.

Policy translated into product requirements, enforcement logic, and measurable outcomes. And human review reserved for the places where context and judgment actually matter.

Trust & Safety will always require strong operations.

But the future of the field is not simply better moderation.

It is designing products where safety is part of the architecture from the beginning.

That intersection between Trust & Safety, AI, policy, and product is where I’ve spent much of my career, and it’s something I plan to write about more here.

Related

  1. Run the abuse pre-mortem at design review

    At design review, changing a default is a quick edit. After launch it means taking something away. T&S earns the invite by being selective and fast, and accepted risks get an owner and a date.

    1 min read · Essay · Safety by design and operations

  2. Launches get a security review. Almost none get an abuse review.

    Introducing the free abuse pre-mortem: 12 questions, rated risks, safeguards with owners in priority order, likely laws, and a launch plan for Jira, Linear or GitHub.

    1 min read · Tool launch · Safety by design and operations

  3. Automation rate isn't a measure of maturity

    Automate as much as the evidence supports. Where a wrong decision can't be reversed or someone's safety is at risk, automation prepares the case and a person closes it.

    1 min read · Essay · Automation and decision quality