Who to Hire for Your DevEx Team (It's Not a Backstage Developer)

When organizations decide to invest in Developer Experience, the first move is almost always the same: they write a job posting for a “Backstage Developer.” It’s an understandable instinct — Backstage is the visible artifact, so hiring someone to build it feels like the obvious start. But it quietly sets the whole effort up to underdeliver, because it optimizes for the easiest part of the job and skips the hard one.

Backstage Is a Framework — Someone Has to Design the Product

Backstage isn’t a finished product you install and configure. It’s a framework — a canvas for encoding your organization’s processes as code. That means the technical setup is only the surface. The real work is intellectual and conceptual: figuring out what to build, for whom, and why. Somebody has to design the internal application that sits on top of the framework, and that application is different for every company.

Hire only for the framework skills and you’ll get a portal that runs beautifully and serves no one — a catalog full of entities that nobody opens. The scarce skill was never wiring up plugins. It was deciding what the portal should be.

The Real Profile: A “Soft Developer”

The person you actually want is what I call a soft developer — someone who codes and brings a set of skills that traditional engineering hiring ignores. Three capabilities matter most:

• User Experience — not just UI, but designing how developers interact with systems, processes, and each other: onboarding flows, feedback loops, cross-team collaboration.
• Writing / linguistic intelligence — the ability to structure knowledge clearly, write documentation people actually read, formulate precise questions, and produce context that both humans and AI agents can reason over.
• TypeScript development — full-stack (React + Node), enough to build Backstage plugins and integrations.

Here’s the key: the technical bar is the easiest one to clear. Any competent TypeScript full-stack developer can learn Backstage architecture. The UX and writing skills are the rare, high-value ones — and they’re exactly what standard engineering interviews never test for. Look for someone strong in at least two of these three pillars.

The Full Skill Map

Beyond the three pillars, the strongest DevEx people tend to be generalists who span several of these clusters:

1. UX & research — information architecture, user research, product analytics.
2. Linguistic intelligence — technical writing, documentation instinct, teaching and workshops. This one is even testable: standardized linguistic-intelligence tests exist, and they’re worth using.
3. Analytical thinking — data and product analytics, plus systems thinking that connects the dev world to the ops world.
4. Product & design thinking — knowing what to build, treating the portal as an internal product to grow, and awareness of change management.
5. Marketing & communication — the internal-evangelist muscle: selling ideas to developers and to management, building community.
6. Technical foundation — enough DevOps and architecture awareness to know what can be integrated and how.

Notice how little of this is “write more code.” DevEx is where engineering meets product, writing, and facilitation.

Staff the Team, Not the Superhero

No single person has all of this — and you shouldn’t wait to find one who does. A useful rule of thumb: an individual should cover at least ~60% of these skills, and the team collectively should cover all of them. Build a multidisciplinary group where someone owns information architecture, someone owns linguistic intelligence, and someone owns product thinking.

There’s one constraint I’d treat as non-negotiable: every member should be a soft developer — actively coding and carrying soft skills. A team of pure developers with no UX or writing instinct wanders without direction and builds things nobody needs. A team of pure communicators who can’t build ships nothing. The combination is the whole point.

How to Screen for It

The trap in interviews is asking attitudinal questions. “Do you like documenting?” tells you nothing — everyone says yes. Ask behavioral questions instead, about what people actually did:

• “Were you the person who documented things in your team — without being asked?” An organic documentation instinct is linguistic intelligence in action.
• Do they write a technical blog? Give talks, run workshops, train people? Those are communication maturity you can’t fake.
• Marketing or UX in their background? That usually comes with analytics and user-research reflexes.

And if you want a hard signal, use a linguistic-intelligence test. It’s one of the few core traits here you can measure directly rather than infer.

What Product Thinking Looks Like in Practice

The single clearest divider between a great DevEx hire and a merely technical one is product thinking. Here’s the contrast in behavior.

With product thinking, a DevEx engineer asks developers what they need first, researches it through interviews and observation, then comes back with something concrete: “Here’s a tool I built for you — what do you think?” They show possibilities — plugins, templates, visualizations — and leave room for developers to decide. They bring inspiration, not mandates.

Without it, the same role defaults to filling the catalog with entities, building tools nobody asked for, and running out of ideas about what to do next. It serves the portal instead of the people. Same job title, completely different outcome — and the difference is a way of thinking, not a certification.

Why This Profile Is Rare

Corporations rarely look for this combination, which is precisely why it’s a competitive advantage when you find it. Most of the market is hiring “Backstage Developers” — narrow technical roles — and wondering later why their portal doesn’t serve anyone. The answer is usually that nobody on the team was ever asked to design it for humans.

If you’re building a DevEx function, hire for the design and the writing first; the framework skills are the part you can teach. At DevStage, this profile — the soft developer who can build, write, and think in products — is exactly the shape of person we look for, because it’s the shape the work actually demands.

Related reading: Understanding the Purpose of Developer Experience and Empowerment Beats Imposition.