Building a documentation practice
I have done this twice, at Tavisca and at Miro: deciding the structure, the templates, the owners, the review cadence, and the versioning from nothing, and documenting the process so that it survives a handover.
Information architecture and standards
I decide the categories, standardize the formats, and organize content so it can be found, reused, and scaled across teams, in XML and DITA where reuse matters. I set and enforce the standards, templates, terminology, and review workflows around it.
Docs-as-code and release velocity
Markdown and MDX in Git, GitHub workflows, versioned documentation, and linting in the pipeline, so documentation ships with the release rather than trailing it.
Automated publishing and quality checks
REST API reference publishes through CI/CD: when an OpenAPI Specification changes, the pipeline lints the spec, rebuilds the reference, and deploys it. Help Center articles pass through the same kind of gate, with linters, style guide checks, and broken link checks running before anything goes live.
Explaining AI and agent-based concepts
I use Claude and Claude Code daily, build multi-step LLM pipelines with structured outputs and evals, and work with agentic AI and RAG systems. I structure content so retrieval works for AI assistants as well as people, and write about it for non-expert audiences.
Technical and customer-facing documentation
Product documentation, API reference, Help Center and knowledge base content, release notes, SOPs, onboarding guides, and training material. I work in instructional design myself, so collaborating with designers and trainers is familiar from both sides.