Successful organizational change, especially in technology adoption, happens through empowerment rather than imposition. This principle is particularly evident in Developer Portal implementations.
Before we talk about how to introduce change, one correction that saves a lot of wasted energy: developers don’t resist “the portal.” That phrase is too blunt to be useful. What people push back on is always specific — a particular workflow change, a mandatory field, an integration that adds a step without removing one. Treating that as generalized “resistance to the portal” leads you to fight the wrong battle and to talk past people who usually have a good reason for their pushback.
Operate at higher resolution. Name the exact change being resisted, understand the concrete friction behind it, and you’ll almost always find the objection is reasonable. Most of the time it’s a signal that the change wasn’t designed with the people it affects — which is precisely the problem empowerment solves.
Many organizations approach change management with a top-down mindset:
This approach often leads to:
Empowerment-based change management focuses on:
The most useful mental model for a DevEx team is facilitator, not central planner. A central planner decides what everyone needs and builds it for them. A facilitator helps each team build what they need. The difference sounds subtle and changes everything: “You come to us with your problem, and we help you solve it” produces tools people actually use, because the people who own the problem also own the solution.
This is where ownership becomes real. The portal has to be their portal — their problems solved, their way, with your help — not the DevEx team’s portal that developers are asked to visit. When a team shapes the thing, they defend it, improve it, and bring the next team along. You’re not manufacturing adoption; you’re growing owners.
There’s a role hiding inside DevEx work that rarely appears in the job description: internal marketer. Not in the sense of selling a product nobody asked for — in the sense of educating. Most developers have no idea what a well-built portal can do for them: the templates, the automations, the visualizations, the golden paths. Your job is to show them what’s possible and then let them tell you what they want.
That reframes adoption entirely. Instead of enforcing usage, you spark demand. “Here’s what we could build for your team — is any of this useful?” invites a conversation; “you must now log all services here” ends one. Education-driven adoption is slower to start and far more durable, because it’s pulled by interest rather than pushed by mandate.
Result: Developers create workarounds, adoption is superficial, and the portal becomes a checkbox exercise.
Result: Developers become advocates, adoption is genuine, and the portal becomes an integral part of the workflow.
Track both quantitative and qualitative metrics:
Any change that involves measurement raises the same quiet question: is this here to help me, or to watch me? How you answer — in design, not in words — decides whether people trust the whole effort.
I learned this outside software, on an IoT project on a factory floor. The instinct was to track workers; the design decision was to track the carts and processes instead, and to put the resulting dashboards in front of the people doing the work immediately. Nobody felt surveilled, because the data visibly served them — they could see their own flow and improve it in real time.
The same rule applies to a developer portal: measure processes, not people, and show developers their own numbers first. When the people being measured are the first to benefit from the measurement, tracking stops being surveillance and becomes something they’d ask for. It’s also the clearest way a DevEx team signals whose side it’s on — the tools you build should visibly serve the developers using them before they serve anyone reporting upward.
Organizations that embrace empowerment-based change see:
Change management isn’t about forcing people to adopt new tools—it’s about creating conditions where teams want to embrace change because they see clear benefits and feel supported in the process.
Empowerment beats imposition every time. When we involve people in shaping their own future, they become partners in transformation rather than obstacles to overcome.
The most successful Developer Portal implementations aren’t those with the most features or the fastest rollouts—they’re the ones where developers feel heard, supported, and empowered to do their best work.
Join the DevStage Bulletin to get updates on new Backstage plugins, exclusive Developer Experience insights and best practices in building developer portals.
Explore why Developer Experience matters in modern software development, how it impacts productivity and well-being, and...
As software development accelerates and becomes more complex, traditional approaches to knowledge transfer and onboardin...
Kickstart your Backstage implementation with these practical steps to quickly prove value, build momentum, and secure su...