Companies adopting Backstage follow a predictable pattern: they hire a “Backstage Developer” and expect results. The assumption is understandable — Backstage is software, so surely we need someone to develop it.
But it sets the effort up to underdeliver. The hard part of a Developer Portal isn’t writing the code. It’s knowing what to write. And that requires a fundamentally different skill set than software development.
When you hire a Backstage developer, you’re assuming someone already knows what features to build, which workflows to automate, and which pain points to address. But who actually has that knowledge?
The truth is: nobody knows what to build until you create feedback loops with the developers who will use it.
Backstage is not a product you install and ship. It’s a framework — a blank canvas for encoding your organization’s unique processes, workflows, and knowledge into a portal-as-code.
Every company is different. Your deployment pipelines, your onboarding flows, your service ownership models, your documentation culture — all of these are specific to you. That means the work of figuring out what goes into your portal is mostly discovery work, not development work.
And discovery work requires a Developer Experience Engineer.
A DevEx Engineer isn’t primarily a coder. They’re a hybrid role that combines:
The technical part is actually the easiest to fill. Any mid-level full-stack TypeScript developer can learn Backstage’s architecture and plugin system. The rare skills are on the research, communication, and design side.
Before you write a single line of Backstage plugin code, you need to:
This is months of research-driven work by people with UX backgrounds — not sprints of feature development by backend engineers.
Developer Experience works best when it isn’t a top-down initiative where a director decides what developers need. That approach tends to produce features nobody asked for and nobody uses.
Instead, the DevEx team is most effective as enablers and facilitators:
This is empowerment, not enforcement — a distinction I dig into in Empowerment Beats Imposition. Developers themselves should be building and extending the portal for their own benefit. The DevEx team provides the structure, the tools, and the coaching to make that happen.
Here’s a perspective most organizations miss: the Developer Portal isn’t just a tool catalog or a documentation hub. It’s a communication platform.
Think about what becomes possible when you have a centralized portal:
One of the biggest unaddressed bottlenecks in Developer Experience is that we rarely account for developers serving other developers.
Senior engineers who’ve been on a project from the start often struggle to do their own work because they’re constantly onboarding new team members. Companies don’t track this time. They don’t have structures for it. And they certainly don’t optimize it.
The solution isn’t more HR processes. It’s code-based, replicable knowledge structures. Backstage can become the tool for education, knowledge transfer, and developer-to-developer communication — supporting the onboarding that developers already do for each other, just without support today.
Here’s what I believe the next evolution looks like: the Developer Portal should serve both humans and AI agents equally.
We should create content for people and for AI at the same time. The same context that helps a new developer onboard should help an AI agent understand your codebase. The same documentation that explains your deployment process should be consumable by an AI assistant that can guide developers through it.
This is a topic I explore in Developer Portals and AI Agents — but it reinforces why you need people with strong communication and knowledge-architecture skills on your DevEx team, not just coders.
| If you need… | Hire… |
|---|---|
| A standard Backstage setup with common plugins | A mid/senior full-stack TypeScript developer |
| Actual improvement in Developer Experience | A Developer Experience Engineer with UX research, writing, and communication skills |
| Maximum impact | Both — the engineer to discover what to build, the developer to build it |
A Backstage developer working as an external contractor who never talks to your developers isn’t really doing Developer Experience — that’s a software project running without requirements.
The hard part of Developer Experience is not building the portal. It’s understanding what your developers actually need, facilitating the communication to discover it, and designing solutions that developers themselves want to adopt.
That’s not a coding problem. It’s a research, communication, and design problem — and it calls for a Developer Experience Engineer: someone with UX sensibility, linguistic precision, writing ability, and enough technical depth to turn insights into software.
Stop hiring only for Backstage. Start hiring for Developer Experience.
Related reading: Who to Hire for Your DevEx Team and Understanding the Purpose of Developer Experience. At DevStage, we help organizations build Developer Experience — from discovery to a portal developers actually want to use.
Join the DevStage Bulletin to get updates on new Backstage plugins, exclusive Developer Experience insights and best practices in building developer portals.
The most common hiring instinct for Developer Experience is to look for a Backstage developer. That misses the point. He...
Explore why Developer Experience matters in modern software development, how it impacts productivity and well-being, and...
Most DevEx scorecards measure the wrong things — activity instead of value, people instead of processes. Here is how to ...