Your first ninety days running Trust & Safety

So you've just been put in charge of a Trust & Safety team. Congratulations, probably. The job comes in two versions. In one, you inherit a team and a lot of habits that were there long before you. In the other, you're the first real safety hire and the team is whatever you build.

Both start the same way. The day-to-day work already knows things you don't, and the costly mistake is changing something before you understand why it's like that. There's usually a reason. Occasionally it's even a good one.

Weeks one to four: learn the work

Review cases yourself for at least a few hours a week, however senior you are. Nothing else shows you as fast what actually comes in, where the tools get in the reviewer's way, and which rules cause arguments. Around that, go find the history. Before you change anything, find out:

• What comes in, and how much of it. Look at the cases themselves, not the dashboard's summary of them.
• Which decisions get reversed, and by whom. Read the record of hard cases sent up for a second opinion, one by one.
• What the team quietly stopped doing. It's in the pile of unfinished work, and in the goals nobody mentions anymore.
• Who else deals with safety. Legal, customer support, product, communications: one conversation each.
• What the last bad week taught anyone. Find the write-up afterward, or notice that nobody wrote one.

Then block out a few days for reading. A good first-week list:

• The written rules, next to ten real cases. Note every place they disagree.
• The last three months of hard cases sent up the chain, and who reversed what.
• The checklist used to grade reviewers' work, plus three recent low scores. Was it fair?
• The contract with any outside review company: how much work, which languages, and what quality it actually promises.
• Anything a government regulator has ever sent you, however thin the folder.

That reading gives you the map: where the written rules and real practice have drifted apart, and where the real risk is. It's almost never where the org chart says it is.

Weeks five to eight: fix one thing people feel

Pick something the team will notice within a week. The saved reply that's been broken for months, the meeting that produces nothing, the goal that was set wrong and can't be hit. Small, visible, done.

In the first two months, a team decides whether its new boss gets things done or just talks, and it decides based on what it sees. Nobody has ever been won over by a roadmap slide.

Weeks nine to thirteen: write the plan

Now you know enough to write it down: what the team will own, what it will stop doing, what it needs, and the few numbers you want to be judged on. Pick those numbers yourself before someone outside the team picks them for you. Make at least one of them about quality, so speed never becomes the only thing that counts.

Promises not to make

• Zero. Harmful content never goes to zero, and the first executive who hears you promise it will remember forever.
• A launch date for a detection tool or system you haven't planned out. Say how long it will take to figure that out instead.
• Coverage you can't staff: a language, a time zone, weekends. Name the gap and what it would cost to fill, instead of quietly stretching the team.
• A wellbeing program you haven't priced. Announcing it and then canceling it is worse than waiting.
• Silence in a crisis. Agree now on who speaks and how quickly, well before the day it matters.

Spend the first ninety days learning what the work already knows. The changing comes after, and it goes a lot better for it.