Technical Writer / Documentation Lead

About the Role

We have strong technical ideas—co-timing, validity gates, contracts, diagnostics—but they only become a product when people can operate them correctly. This role turns research-grade narrative into field-ready documentation: product docs that explain what the system is doing, test protocols that make results reproducible, and calibration procedures that survive real installs.

You’ll own the writing that prevents institutional memory from becoming a single person’s brain.

What You’ll Do

• Whitepaper → product documentation: translate core concepts into operator-usable docs: what the system assumes, what it checks, what outputs mean, and what to do when it abstains or flags a window.
• Test protocols: write step-by-step validation procedures (benches, acceptance tests, regression checks) with pass/fail criteria and expected signatures.
• Calibration procedures: create factory + field calibration guides (equipment, diagrams, tolerances, receipts to log, intervals).
• Commissioning & install guides: placement guidance, wiring/cabling, environmental constraints, and common mistakes sections.
• Troubleshooting playbooks: symptom → likely causes → confirming checks → fixes, aligned with UI diagnostics (“if notch does not dip…”).
• Information architecture: structure docs so answers are fast to find (glossary, naming conventions, doc sets by persona).
• Docs-as-code workflow: versioning, review, publishing processes aligned with releases.
• Cross-functional editing: interview engineers/field staff/customers; extract tacit knowledge; make it precise without losing clarity.

Concrete Deliverables

• A product documentation set split by persona: operator, installer, admin/IT, advanced diagnostics.
• A protocol library: acceptance tests, bench validation steps, regression test descriptions mapped to CI checks.
• A calibration handbook: equipment list, procedures, thresholds, receipts/log fields, frequency guidance.
• A glossary + concept map that keeps terminology consistent (co-timing, windows, validity, receipts).
• A documentation style guide: tone, diagram conventions, naming, severity language, how to write assumptions/checks/actions.

Required Qualifications

• Proven experience writing technical documentation for hardware/software or scientific/industrial systems.
• Ability to interview engineers and convert complex concepts into clear, testable procedures.
• Strong editing skills: clarity, consistency, structure, ruthless removal of ambiguity.
• Comfort with diagrams and structured artifacts (tables, checklists, decision trees), not just prose.

Preferred Qualifications

• Experience in instrumentation, metrology, HVAC/facilities, IoT deployments, or other field-reality domains.
• Familiarity with DSP/measurement concepts (noise, drift, coherence) enough to write accurate troubleshooting content.
• Experience with docs-as-code tooling (Markdown, static site generators, Git workflows) and release-aligned publishing.
• Experience producing customer enablement materials: quickstarts, training guides, in-product help, runbooks.

How You’ll Be Measured (First 60–90 Days)

• The first set of customer-facing docs ships with the product and reduces support load.
• Calibration and acceptance procedures become repeatable and produce consistent receipts across installs.
• Engineers and field staff adopt a docs workflow where updates happen alongside code changes.
• Common failure modes become easy to diagnose because troubleshooting content is aligned with the UI.

Working Style

• You hate vague instructions like “ensure proper calibration.” You replace them with equipment, steps, tolerances, and pass/fail.
• You write for people under pressure: on a ladder, in a hot aisle, during a change window.
• You keep terminology consistent so the product doesn’t feel like three teams talking.

Title & Level

Technical Writer / Documentation Lead (mid-to-senior; can scale to Docs/Enablement Lead as the org grows), partnering with engineering, solutions/field, and product teams.