Remote developer experience engineers make software development faster, less frustrating, and more productive — building the tooling, automating the toil, improving the documentation systems, and removing the friction points that slow engineers down every day. The role applies engineering skill to the problem of engineering productivity itself, treating developers as the users whose experience must be designed and optimised.
What they do
Developer experience (DX) engineers build and maintain the tools that the engineering organisation uses to develop, test, and deploy software — CI/CD pipeline tooling, local development environments, test harness infrastructure, build system optimisation, IDE plugins and extensions, and the scaffolding and code generation tools that bootstrap new services. They instrument developer workflows to identify bottlenecks (slow CI pipelines, flaky tests, painful onboarding steps, missing documentation) and fix them systematically. They own the onboarding experience for new engineers — the scripts, documentation, and self-service tooling that allows a new hire to go from laptop setup to first pull request with minimal friction. They work with platform engineering on the developer-facing layer of the internal platform and with developer relations on the external developer experience for API and SDK products.
Required skills
Strong software engineering skills — production-quality code in at least one major language (Go, Python, TypeScript, or Java) — are required for building the tooling and automation that is the DX engineer's primary output. Deep familiarity with CI/CD systems (GitHub Actions, GitLab CI, CircleCI, Jenkins, Buildkite) for building and optimising the pipeline infrastructure that development teams use daily is required. Understanding of developer tooling ecosystems — shell scripting, Makefile patterns, build systems (Bazel, Gradle, Webpack), and the composition of local development environments — is foundational. Strong technical communication skills for documenting tooling, writing engineering guides, and presenting developer productivity improvements to engineering leadership round out the baseline.
Nice-to-have skills
Experience with developer experience measurement — tracking CI pipeline duration, flaky test rates, onboarding time-to-first-PR, and developer satisfaction surveys — for quantifying the impact of DX improvements and prioritising the highest-leverage investments. Background with internal developer portals (Backstage) for building the developer self-service experience layer that organises tools, documentation, and services in one place. Experience with external developer platforms (APIs, SDKs, developer consoles) for companies building developer products, where the DX engineer's improvements affect the experience of thousands of external developers rather than only internal engineers.
Remote work considerations
Developer experience engineering is naturally suited to remote work — tooling development, automation, CI/CD optimisation, and documentation work are all async activities. DX engineers often develop among the strongest empathy for remote engineering challenges because they are themselves distributed engineers building for distributed engineers. The feedback loop for DX work — understanding what friction points matter most to engineers across different teams and time zones — requires deliberate investment in async feedback channels (surveys, Slack channels, documentation issue trackers, structured onboarding feedback sessions). Remote DX engineers typically build their communities of practice across async channels and are heavy users of the internal communication and documentation infrastructure they are improving.
Salary
Remote developer experience engineers earn $130,000–$195,000 USD at mid-to-senior level in the US market, with staff and principal DX engineers at major developer tool companies reaching $220,000–$290,000+. European remote salaries range €80,000–€140,000. Developer tool companies (where internal DX quality directly influences external product quality), large engineering organisations with significant developer productivity leverage, and companies that compete on engineering velocity pay at the upper end.
Career progression
Software engineers who develop a strong interest in tooling, productivity, and the engineering experience move into developer experience engineering. From DX engineer, the path runs to senior DX engineer, staff engineer, and principal engineer. Some DX engineers move into platform engineering leadership, developer relations (where external developer experience is the focus), or engineering management with a productivity team scope. The DX engineering discipline is relatively young — practitioners who define the practice carry significant influence over how the field evolves.
Industries
Developer tool companies (GitHub, JetBrains, Atlassian, Vercel — where developer experience is the product), large technology companies with hundreds of internal engineers (where DX investment pays off at scale), and API and SDK companies where external developer experience is a competitive differentiator are the primary employers. Any engineering organisation beyond a few dozen engineers benefits from dedicated DX investment; it typically becomes a dedicated role around 50–100 engineers when CI pipelines slow, onboarding takes weeks, and local development environment setup is a recurring pain point.
How to stand out
Demonstrating specific developer productivity improvements with measured outcomes — CI pipeline duration reduced from X minutes to Y minutes (and the resulting reduction in engineering time blocked), onboarding time reduced, flaky test rate brought from X% to near zero — positions DX engineering as a measurable business investment. Being specific about the tooling you built (the CI optimisation, the local dev environment setup script, the scaffolding tool) and the adoption metrics (how many engineers use it, how often) shows operational impact. Remote candidates who demonstrate experience building DX for distributed teams — async feedback loops, documentation-first tooling, timezone-aware CI scheduling — address the specific challenge of improving developer experience without physical co-location.
FAQ
What is developer experience and why does it matter? Developer experience (DX) is the sum of how easy, fast, and pleasant it is for software engineers to do their work — from setting up a development environment to getting code to production. It matters because engineering time is expensive and friction is multiplicative: a CI pipeline that takes 30 minutes instead of 5 means engineers wait, interrupt their flow, or work on something else and lose context. Flaky tests mean engineers don't trust the test suite and ignore failures. Painful onboarding means new hires take months to be productive. DX improvements compound: making each engineer 10% faster with better tooling creates more leverage than hiring 10% more engineers at the same pace.
How is developer experience engineering different from platform engineering? Platform engineering focuses on the infrastructure and operational layer — the Kubernetes clusters, the service mesh, the deployment pipelines, the observability stack. Developer experience engineering focuses on the developer-facing layer — the tooling, documentation, local development environments, onboarding, and productivity workflows that software engineers interact with daily. The two overlap significantly: a platform engineer and a DX engineer both care about CI/CD, but the platform engineer focuses on the reliability and scalability of the pipeline, while the DX engineer focuses on the developer ergonomics — how fast it runs, how clear the feedback is, how easy it is to debug failures. At smaller companies one team does both; at larger ones they differentiate.
What is the highest-leverage DX investment for most engineering organisations? Typically CI/CD pipeline speed and reliability. Slow or flaky CI blocks engineers at every stage of development — every pull request, every merge, every deploy. A CI pipeline that takes 30 minutes and fails randomly 20% of the time is not just annoying; it actively degrades code quality (engineers skip running tests locally because CI is slow) and slows the entire delivery cycle. Investing in CI caching, parallelisation, test sharding, and flaky test elimination typically produces the largest and most broadly distributed productivity improvement of any DX investment. After CI, local development environment setup (eliminating the "it works on my machine" class of problems) and developer onboarding (reducing time-to-first-PR for new hires) are the next highest-leverage investments.