Dishaya / Careers / Developer Relations & Technical Writer

Developer Relations & Technical Writer

Explain a trust product clearly, without overselling it: documentation, guides, and worked examples that respect the reader's time, tell the truth about limits, and let people succeed on their own.

Growth · Remote-First · Founding Equity

About Dishaya

Dishaya makes research people can actually send. One question in; a client-ready report, deck, and source ledger out, with every claim checked against the exact passage it cites and labeled verified, partial, unverified, or contradicted. What fails the check is disclosed, never hidden. We are early, independent, honest about both, and building toward one ten-year outcome: "Verified by Dishaya" becoming a mark a reader trusts before they read. More in About and Principles.

Why This Role Matters

Dishaya asks people to trust what it writes. The first thing most of them read is not a report; it is our docs, our guides, our changelog. If those words oversell, the trust is spent before the first work package finishes. This role makes the writing around the product as honest as the product itself, so that a careful reader arrives already believing us for the right reasons.

What You'll Work On

• Public documentation that takes a new user from their first messy question to a finished report, deck, and source ledger without guessing.
• Integration guides that work when followed exactly, because you ran every step yourself before publishing.
• The changelog voice: plain, specific, honest about what changed, what improved, and what did not.
• Worked examples built on real outputs, including the honest failures: what partial, unverified, and contradicted look like in practice, and why showing them is the point.

We describe work by the outcomes you will own rather than by our internal systems; you will see everything on the inside from day one.

Responsibilities

• Own the public docs end to end: structure, accuracy, and upkeep as the product changes underneath them.
• Test everything you document by running it yourself; nothing ships on faith.
• Write the changelog and defend its voice: calm, specific, no adjectives doing the work of facts.
• Turn real user confusion into fixes: when the same question reaches support twice, decide whether the answer belongs in the docs and put it there.
• Hold the line on what we publish: outcomes and policies people can rely on, never internal mechanics.

Required Qualifications

• A strong technical writing portfolio: docs, guides, or explanations you can point to and defend line by line.
• You can code enough to test everything you document, and you refuse to document anything you have not run.
• A calm voice: plain sentences, no hype, and real comfort stating what a product cannot do.
• An editor's discipline: you cut words until only the useful ones remain.

Preferred Qualifications

• You have documented an API or developer product that paying customers built on.
• You have owned a changelog or release notes and kept them honest under launch pressure.
• Experience writing for products where accuracy is the promise: security, data, finance, research.

Nice To Have

• Published writing, a personal site, or open documentation work that shows how you explain hard things simply.
• Time spent answering support questions and turning the recurring ones into documentation.

What Success Looks Like

• 30 days: you have run the product end to end yourself, rewritten the pages that confused you as a new user, and shipped changelog entries in a voice we keep.
• 90 days: a new user can go from first question to a finished work package in their Library using only the docs, and the most common support questions now have documented answers you wrote.
• 365 days: users routinely succeed without writing to support, nothing in the docs promises what the product cannot do, and when the product falls short somewhere, the docs are the first place that says so.

Team Principles

• Honesty over fluency, in the product and in code review.
• Delete before you add; every abstraction earns its keep.
• Evidence over enthusiasm; direction comes from users.
• Small, senior, trusted; you own outcomes, not tickets.

Benefits

• Founding-level equity; early means it matters.
• Remote-first, judgment over time zones.
• The hardware and tools you need, without a procurement dance.
• Direct access to how the company runs: numbers, decisions, reasons.

Interview Process

1. Intro conversation (30 minutes): the honest state of the company, and what you want to build.
2. Craft deep-dive: real decisions inside work you shipped.
3. Paid working session: scoped, close to the real job, never spec work we ship.
4. References and a clear written offer, fast.

Equal Opportunity

Dishaya is an equal opportunity employer. We evaluate candidates on craft, judgment, and alignment with how we work, never on race, color, religion, gender, gender identity or expression, sexual orientation, national origin, disability, age, or veteran status.