How Structured Communication Became TRM's Quiet Superpower

Terrorist financing gets flagged before the wire clears. A drug trafficking ring gets traced through a chain of wallets that looked clean on the surface. A CSAM network loses its financial infrastructure because an analyst knew exactly where to look. These outcomes don't happen by accident, and they aren't just a product story. They're the downstream result of TRM's quiet superpower: structured communication.

It's rarely written about, because frankly, it's unsexy. But at TRM, structured communication is an operating system that enables our horsepower. When the stakes are this high, fuzzy communication is both inefficient and a liability.

What "structured communication" actually means at TRM

Here’s an example of one way we think, communicate, and document in a structured manner.

In most companies, documentation happens after the decision is made. Someone schedules a meeting. The team talks through the problem live. A choice gets made. Someone, maybe, writes down what that decision was. Twelve months later, a new hire inherits the outcome with no sense of the reasoning behind it, and the team ends up re-litigating the same debate from scratch.

This isn't how it works at TRM, because we require any consequential decision to be worked through in writing first, in what we call a “decision doc.” These documents capture the people involved, the problem, the context, the options (with honest tradeoffs for each), the final decision, and the follow-up actions with clear owners.

Is it a bit of a pain to write one of these every time a decision comes up? Honestly, yes. But it's far less painful than being a company that can't remember why it made the choices it did, and has to slow down to reverse-engineer its own past to move forward. Decision docs force precision. As Ankush Sharma, an engineering manager on our core ingestion team, puts it, "If the problem statement is weak, if the options are fake, if the owner is unclear, it shows up immediately. You can't hide fuzzy thinking as easily in a decision doc.”

That precision also changes what meetings are actually for. Instead of using synchronous time to discover the problem live, people arrive having already reacted in writing. The meeting, if one is even needed, becomes about real disagreements and judgment calls, not about getting everyone up to speed.

Every function, not just engineering

Isabella Chase, who leads EMEA policy work at TRM, says structured communication across every function is what makes her role possible.

"At TRM, I'm never starting from scratch when I'm engaging with policymakers, because we have this culture of really structured communication and documentation across every single one of our teams," she explains. "When I can bring them all together, we become really trusted partners in the eyes of people making the decisions that shape the industry."

That consistency compounds over time. What the intelligence team learns about a threat doesn't evaporate at the end of the quarter. What product learns about why a feature was built — and why it wasn't — stays findable. By the time a regulator or policymaker needs answers, the evidence base is already there.

Why talent density requires this kind of discipline

People who have a lot of work to get done don't want to sit in meetings that could have been an asynchronous exercise in a shared document. They don't want to re-derive decisions every quarter because no one wrote anything down.

A culture that demands documentation attracts people who think clearly. It filters, gently but persistently, for the self-directed: people who can take a Notion page, a public-channel thread, or an ambient sense of where the team is going and turn it into forward motion without waiting to be told.

"Working this way creates a more inclusive environment — people who think carefully and write well, not just people who are fastest on the mic," says Ankush.

Structured communication in action

A two-week project that landed cleanly

Earlier this year, TRM shipped a project called Segments for Transaction Monitoring. Maggie Drinkwater, a senior product manager at TRM, points to the technical feasibility doc an engineer wrote mid-project as the reason the whole thing held together.

"The open questions were very clear — what the questions were, and the implications of the answers," Maggie says. "It was easy to skim. Easy to see exactly what the decision was and what the tradeoffs were."

Two things happened because of that document: The product spec got meaningfully sharper because it absorbed the technical realities the engineer surfaced early. And when a different engineer joined the build mid-flight, they ramped from the doc alone.

The project shipped in two weeks, with no bugs since.

When the audience is a regulator

Structured communication at TRM isn't only about how teammates talk to each other. Isabella points to TRM's public-private partnership programs — the T3 Financial Crimes Unit and Beacon Network — as examples of documentation that lives and breathes in real time.

Isabella explains, "I can be sitting in a live meeting with a policymaker and draw up the dashboards we have about the live success of these projects and give them real-time figures on how many flows we've disrupted, the countries that are being impacted, the types of crime."

The payoff is trust. When she meets the same policymaker a second time, the numbers have moved. Nothing signals credibility quite like a dashboard that's visibly fresher than it was two weeks ago. "I often see their jaws drop as I recount the success of these programs, and that is all because of our culture of documentation and structured communication.”

Writing for a regulator demands a different register than writing for a teammate. Internally, Isabella says, TRM prioritizes brevity and speed — short messages that unblock a decision or initiate an action, using internal language when it's efficient. Externally, the defaults invert. "When I'm writing for regulators, it's really the opposite. We take the extra time to use as little jargon as possible, give the necessary background, anticipate where questions might be asked, and get ahead of that — the 'so what' and the 'and then what.'"

The small habits that distinguish strong communicators from weak ones

Ankush coaches his team on a pattern that's become something of a TRM signature: "Instead of 'What should I do?' — it's 'I think X because Y. Am I missing something?' That small difference in phrasing signals ownership, reasoning, and momentum,” he explains.

Strong communicators at TRM lead with the bottom line, up front. They show reasoning instead of escalating a blank question, and they post in public channels so the team doesn't depend on private context. Weak patterns are the mirror image: too much context before the point, questions with no visible thinking, important updates trapped in direct messages, and silence until something's already late.

Maggie says the same thing a different way: "Ask the question first, then give the rest of the context. The natural instinct is to build up to the ask, but it's far more effective to ask the question first, so people understand what end you're trying to get to."

Isabella makes the same move across a harder boundary — policy into engineering: "When you're communicating complex regulatory nuance to engineering or product teams, it's really important to lead with the ‘so what.’ Policy can be quite abstract, so stating the on-the-ground implication of this script you're writing or this product you're building is really important."

Magdalena Fumagalli, TRM's founding designer, lives the same muscle in reverse. Her team's job is to make design reasoning legible to engineers who don't spend their days thinking about interaction patterns or accessibility trade-offs. "Design isn't math, so we need to make an effort to translate our design process to documented rules engineers can accept," she explains. "Design decisions get challenged by engineers who don't understand why an extra click may be necessary or worth the effort — in those cases, we need to break down the trade-offs considered by design as well as other workflow insights."

Whether the boundary is product/engineering, policy/engineering, or design/engineering, the habit is the same: lead with the point, show your reasoning, and earn the reader's attention before asking for their context.

What async-first actually changes about structured communication and management

"At other companies where there are more meeting-heavy environments, a lot of management happens through live synchronization," Ankush says. "People wait for the meeting to get clarity, raise issues, or make progress."

At TRM, managers spend more energy on mechanisms: decision docs, clear written updates, explicit ownership, and enough context in the system that people don't need a manager to relay context between them.

Async also doesn't mean text-only. Magdalena's team shows what that looks like in practice: "We share thoughts and input on ongoing designs through short Looms, comments in Figma, and Slack threads commenting on screenshots. We also love to huddle to discuss details and implications of a design decision."

The surface follows the work. What stays constant is that someone captures the reasoning somewhere a teammate can read — or watch — later.

The compounding benefit

"The most underrated benefit is that this kind of rigorous, structured communication compounds," Ankush says. "Good writing turns individual judgment into organizational memory."

Onboarding speeds up, because new hires can see how decisions actually get made here. Cross-functional work gets better, because people can inspect the reasoning behind a decision rather than inherit an outcome they don't understand. Over time, the quality bar rises: ideas have to survive contact with documentation, not just charisma.

Magdalena points to a newer compounding mechanism: AI. Her team maintains the design system's decision-making rules as structured Notion pages and keeps them current with AI assistance. The product team then pulls those pages into its workflow as skills. "This is constantly updated with the help of AI, and gets consumed as skills by the product team's workflow,” she said.

What this signals if you're thinking about joining

Whether you're coming from government, law, a technical background, or a different industry entirely, it's helpful to know what TRM's communication culture asks of the team. "Communication here relies on three key tenets: speed, precision, and impact,” Isabella explains. “You're expected to respond quickly, but speed never comes at the cost of precision."

If you've sat through a meeting that should have been a doc — or written a doc that nobody read because no one else in the org valued documented thinking — the difference will be obvious within your first week here.

A few things to expect:

• Expect to write down your thinking before the meeting, not after.
• "I think X because Y. Am I missing something?" will become muscle memory.
• DMs are the exception. Public channels are the default.
• Decisions live in Notion, not Slack. If you try to make a decision in a DM, someone will (kindly) ask you to document it.
• Nobody will let you hide behind vague language. We treat directness as a form of respect.

Communication as a moat

Most companies talk about clear communication, but few build scalable and culturally embedded systems for it.

When the system holds, knowledge compounds. Decisions get better. The best thinkers, not the loudest talkers, set the direction. And the people who care about how work gets done, not just what gets built, tend to stay.

That's the bet we're making about what talent density actually looks like — across engineering, product, design, policy, intelligence, sales, and every team that has to make a decision legible to someone else.

‍

{{horizontal-line}}

‍

TRM is looking for engineers, designers, investigators, policy leaders, and operators who believe that how a team thinks is inseparable from how it communicates. If that's you, we're hiring.