Content & Knowledge Lead

Some of the work, before we talk.

Documentation sets I run at Atlassian, and one of your own Help Center articles rebuilt to serve a clinician and Fin at the same time.

Alex Schwarz Sydney linkedin.com/in/schwarzy schwarzy46@gmail.com 0424 625 279
01  /  Published work

Documentation I maintain at Atlassian.

All three are live and public. Worth opening rather than taking on trust.

02  /  Applied to Heidi

Your "User Roles" article, rebuilt for two readers.

One reader is a clinician skimming for an answer. The other is Fin, retrieving one on their behalf. The same article can serve both.

As it reads now

User Roles

Heidi uses role-based access control to manage what each team member can see and do. Roles are divided into Administrator, Clinician, Assistant, and Template Manager, each tailored to specific team functions.

The Administrator role is for users who need full access to manage the workspace. The Clinician role is designed for providers who need clinical tools and documentation. The Assistant role is for support staff who help without owning core sessions…

Continuous prose, with permissions embedded mid-sentence. No single role can be retrieved without the others.

Restructured

User Roles

Heidi has four roles. Each controls what a team member can see and do.

# one self-contained chunk per role # Fin retrieves exactly one, cleanly ## Clinician For: providers delivering care. Can: create and own sessions, use clinical tools, generate and edit documentation. Can't: manage team settings or billing. ## Assistant For: support staff. Can: create sessions, add patient details, manage session logistics. Can't: own core sessions, change settings.

Each role becomes one retrievable unit, with permissions stated explicitly rather than implied.

What this changes for Fin

A support AI retrieves passages, not pages. When four roles sit inside continuous paragraphs, a question like "can an assistant change team settings?" returns a passage mentioning all four, and the model has to infer which sentence applies. Most wrong answers begin here, in the structure of the source rather than the model reading it.

Separating each role into its own unit, with permissions stated as can and cannot, gives the retrieval step a single clean passage to work from. The facts are unchanged from your current article; only the structure differs. I measured this at Atlassian against a six-point quality check: 93 percent for the retrieval-ready version, 63 for the one written for a human alone.

content chunking retrieval-first structure dual-audience plain language
03  /  The system

How content stays current without being chased.

Your posting describes this as much as building the system as writing inside it. This is the system I would put in place.

Single source
One canonical article per concept, structured in retrievable sections. The Help Center renders it for readers and supplies Fin the same source, which avoids parallel internal and public versions drifting apart.
Release hook
Content becomes a checklist item on the release itself. When Product ships a feature, price change, or integration, the linked articles are flagged before it goes out rather than after.
Staleness signal
Every article carries a last-verified date and a named owner. A change to the product surface it documents flags it for review, so ageing content declares itself rather than waiting to be discovered.
Ticket-driver loop
Support ticket themes feed a ranked list of gaps. The highest drivers with no article behind them become the next sprint, so the Help Center is shaped by what customers actually ask.
One voice
A concise, enforced standard so Support, the Help Center, and Marketing's multilingual content give the same answer to the same question. I have written and documented standards of this kind before, with worked examples.
04  /  First 90 days

How I would approach the first three months.

Days 1–30Map and first fixes
Audit the Help Center for stale articles, pull the support ticket data, and rank the drivers. Cross the two lists to find which drivers have no article behind them and which articles have quietly gone out of date. Fix the highest-traffic stale ones first, while I am still learning the product.
Days 31–60Close the gap, build the hook
Run a content sprint against the top ticket drivers, structured for retrieval so Fin improves alongside the articles. In parallel, work with Product and Engineering to establish the release hook, so Support is brought in before a release ships rather than after it.
Days 61–90Current by default
Review signals in place, ownership assigned, and the release hook running against real releases. Documented thoroughly enough to hold as the team grows, since a system that depends on its author is unfinished.
05  /  Track record

Relevant background.

93%
quality score for content structured for AI retrieval, against 63% for the same facts written conventionally. A six-point evaluation I designed, the first of its kind at Atlassian.
4
knowledge maps built from a blank page, with the method documented so others could repeat it.
164pg
GA documentation set delivered on schedule with no launch blockers, from a single canonical source model.

Twelve years in content altogether. I started as a copywriter in advertising, working on global brands for five years before moving into tech, then became Airtasker's first writer, which meant establishing a content function rather than joining one. I also spent a period as a patient some years ago, long enough to notice the difference between a clinician who is present and one buried in administration. It is a large part of why this particular role interests me.