You Don't Need a Backstage Developer — You Need a Developer Experience Engineer

DevEx
March 19, 2026
6 min read

The Hiring Instinct That Quietly Backfires

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.

The Knowledge Gap No One Talks About

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?

  • Your Backstage developer? They just arrived. They don’t yet know your organization’s processes.
  • Your engineering manager? They see the team from above, not from inside the daily friction.
  • Your product owner? They’re focused on business features, not developer workflows.

The truth is: nobody knows what to build until you create feedback loops with the developers who will use it.

Backstage Is a Framework, Not a Product

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.

What a Developer Experience Engineer Actually Does

A DevEx Engineer isn’t primarily a coder. They’re a hybrid role that combines:

UX research skills

  • Mapping current developer workflows and touchpoints
  • Identifying bottlenecks, friction points, and repeated pain
  • Running surveys with well-crafted questions (this is harder than it sounds — bad questions produce bad data)
  • Conducting interviews and feedback sessions with development teams

Communication and writing skills

  • High linguistic intelligence — the ability to structure knowledge clearly
  • Experience writing documentation, technical content, or even marketing copy
  • Understanding how to formulate questions that produce constructive answers
  • Facilitating asynchronous communication processes with developers

Internal marketing skills

  • Evangelizing the portal and its possibilities to teams
  • Building buy-in through empowerment, not imposition
  • Making the value proposition tangible: “We’ll help you reduce your onboarding time, document your services, and eliminate those bottlenecks you keep hitting”

Technical foundation

  • Full-stack TypeScript (React + Node) — enough to build Backstage plugins
  • Understanding of software architecture and platform engineering
  • Ability to translate process insights into working software

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.

The Real Work: Developer Experience Before Developer Portal

Before you write a single line of Backstage plugin code, you need to:

  1. Map the current Developer Experience — Where do developers interact with internal systems? What’s painful? What’s unclear?
  2. Create feedback loops — Establish channels for developers to surface their challenges and propose solutions
  3. Identify quick wins — Find the 20% of effort that will deliver 80% of the value (the Pareto principle)
  4. Co-design solutions — Work with developers, not for them. They should be involved in deciding how Backstage serves their needs
  5. Build incrementally — Start with what you’ve learned, ship it, gather feedback, iterate

This is months of research-driven work by people with UX backgrounds — not sprints of feature development by backend engineers.

The Flat Structure Principle

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:

  • “We have these capabilities. What do you need?”
  • “You’d like help writing better documentation? We’ll coach you through it.”
  • “You spend three hours onboarding every new team member? Let’s automate that together.”

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.

The Portal as a Communication Platform

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:

  • Single source of truth — Everyone knows where to look. No more “I’m not sure if this is the latest version.”
  • Self-service booking — Imagine a plugin where you can book a 15–20 minute session with an expert in translations, cloud infrastructure, or content management. Not just codified knowledge, but access to people.
  • Transparent metrics — Build metrics about processes (not people) and show them in real time. Developers can see exactly what’s being tracked and why. No surveillance anxiety — just process visibility.
  • Developer-to-developer knowledge transfer — Senior developers spend enormous amounts of untracked time onboarding others. The portal can structure this, turning tribal knowledge into scalable onboarding.

Developers Working for Developers

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.

The Coming Shift: Portals for Humans and AI Agents

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.

So What Should You Actually Hire?

If you need…Hire…
A standard Backstage setup with common pluginsA mid/senior full-stack TypeScript developer
Actual improvement in Developer ExperienceA Developer Experience Engineer with UX research, writing, and communication skills
Maximum impactBoth — 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 Bottom Line

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.

📮 Stay Updated with DevEx Insights

Join the DevStage Bulletin to get updates on new Backstage plugins, exclusive Developer Experience insights and best practices in building developer portals.

You can unsubscribe at any time.Privacy Policy