Deepgram

Staff Developer Experience (DX) Engineer

Remote Developer Relations role with clear candidate location fit.

PostedJul 17, 2026

Eligible countries1 accepted country

Seniority signalLead

Work settingRemote

Accepted candidate locations

USA

AWS Java JavaScript Python REST TypeScript

Role overview

Staff Developer Experience (DX) Engineer

Requirements and responsibilities

Readable role content extracted into sections for faster review.

What you'll work with

Real-time, streaming SDKs. Our SDKs wrap low-latency WebSocket APIs for speech-to-text, text-to-speech, and Voice Agents. The hard, interesting parts are streaming, partial and interim results, reconnection and backpressure, and concurrency.
Multiple languages and tech stacks. Python, JavaScript/TypeScript, Go, Rust, .NET, and Java today, with a persistent eye on what developers are building with.
Open source, in the open. The SDKs are public on GitHub. You own the repos, work in the open, and engage directly with external contributors, issues, and PRs.
Spec-driven, generated SDKs. The libraries are generated from a shared API specification, so much of the craft lives in the generation pipeline and templates rather than hand-writing each library, which is exactly the architecture this role owns.
The wider surface. A CLI, the documentation and reference experience, and starter repos and reference integrations for the partner stacks developers build voice agents on, like Pipecat, LiveKit, AWS, and Twilio.

What you'll do

Own the direction of developer experience. Set the DX roadmap (what we build, in what order, and why) and act as the technical lead for the area without direct reports. You're the person Product, Engineering, and Partnerships come to for the DX point of view, and the one who represents it in planning.
Own the SDK code-generation architecture. Design and own the system that produces our SDKs, so every supported library ships predictably and adding a new language is a known, low-cost effort rather than a one-off project.
Set the standard for how developers experience the platform. Define the quality bar, cross-language parity, versioning and release discipline, and observability across all of our SDKs. These are the standards the rest of the team builds against.
Raise the level of everyone who touches the SDK surface. Through code review, patterns, documentation, and pairing, you make the engineers around you better at developer experience, leading through influence rather than management.
Attack friction at the root. Find the systemic causes that slow developers down across whole segments and fix them once, structurally, before developers ever hit them.
Build the tooling the whole team relies on. The code-generation pipeline, CI and supporting infrastructure, starter repositories, and context that both human developers and AI coding agents can build on (including emerging standards like llms.txt).
Design for resilience and longevity. Build documentation, automation, and architecture that the whole team can operate and extend, so the work lasts and scales beyond any one person.
Be the technical voice into Product, Engineering, Marketing, and Partnerships. Give cross-functional stakeholders the context and technical input they need to make good decisions about the developer-facing surface across our partner ecosystem.

What we're looking for

A track record of owning developer-facing tooling across multiple languages. Starts with libraries, and expands to the SDK generators, templates, and release automation that produce them, with direction others built against.
AI as part of how you build. You use AI as real infrastructure in your workflow. Think agentic pipelines, custom tooling, and generators you've authored and rely on daily, with strong verification discipline. (Be ready to talk about the most complex AI system you've built recently.)
An instinct to build reusable systems. Your standout work is something that outlived you. It could be a generator, automation, pipeline, or architecture that others adopted.
First-principles reasoning about systems. You think about SDKs, code generation, and partner ecosystems as systems. They have inputs, outputs, feedback loops, and boundaries.
Production ownership instincts. You treat production SDKs as production: observability, incident response, backward-compatibility discipline, and a bias toward removing recurring toil.
Range beyond your core. You go deep on developer experience and tooling, and you can pick up developer content, demos, or community work when the moment calls for it.
You think in developer outcomes, not just shipped code: you connect SDK and docs work to product activation and retention.

What success looks like

You set the standards for our SDKs and developer tooling, and the rest of the team adopts them.
The team has a clear direction for developer experience, and follows it, because you set it; and the engineers around you get better at DX because of how you work.
You're a recognized authority on developer experience; engineers and partners reference your work at the integration layer.
More signups reach a successful first call, and fewer drop at integration, because the SDKs and docs make activation effortless.
Support load drops, because the tooling and documentation answer the question first.
The hardest, least-defined problems in our developer experience get named and solved, often before anyone else has spotted them.

Similar roles