Moving Adobe to a Unified Developer Platform

Background

I’d spent years building the interface of Adobe’s internal developer platform, starting as the only UX designer for ~50 backend engineers, creating a lean in-house design system, founding the first UX & Product Engineering team, and consolidating into a single platform for our org.

Then, in 2021, our org expanded again. Multiple teams and tooling sets merged, and suddenly, we were supporting more than 15 tools and over 150 engineers.

Two things never changed throughout my time working on Adobe’s developer platform:

• UX was fragmented across teams; developers kept spinning up their own tools rather than building on the shared platform
• We maintained more UIs than we had UX resources to properly support

At that time, the team working on the UI (rebranded UX & Product Engineering) was only five people, nowhere near enough to design and build every frontend the expanded org was producing.

Changes in the Landscape

Throughout this period, the developer tooling space was also exploding industrywide. Teams everywhere were rethinking how developers deploy, monitor, and manage services, and building tools to match. We had to continuously adapt to keep our platform relevant and Adobe’s developers moving fast and with confidence.

Meanwhile, another Adobe team had built Spectrum, a customer-facing design system with a dedicated team. It was far more comprehensive than the design system we had built internally.

Challenge

Across the industry, teams were tackling the same internal developer tooling problems, trying to unify into portals. And some of them were open-sourcing their solutions and building momentum.

Our goal hadn’t changed: a unified platform UI that made development easier and more consistent. But the situation had:

1. A better design system was now available and maintained in-house
2. Open-source portals were already solving the same problems we’d been building toward

In 2022, this led to our most ambitious project yet: a unified developer portal across all of Adobe.

Strategy

With a fixed frontend team size and a shifting landscape, it was time to step back and reassess. Our developer platform wasn’t a flagship Adobe product that required deep customization, which made it a strong candidate for utilizing existing software. Before bolting more tools onto our platform (which already needed rewriting in order to incorporate Spectrum), we had an opportunity to pivot.

The strategy:

1. Assess our options: Evaluate existing platforms, including open source portals and vendor-operated ones.
2. Switch design systems: Commit to Spectrum for all internal tooling UIs, whatever platform we chose.
3. Redefine UX & Product Engineering: Shift from UI design and implementation within a single team to a center of excellence: consulting on UX and managing contributions to the portal.

Throughout the evaluation, we kept four focuses front of mind, the 4 Cs:

Assess our options

I led teams through a structured assessment of four platform options. Each assessment got a small, short-lived cross-functional team that rapidly prototyped the core functionality we needed. I facilitated stakeholder discussions across teams and orgs to weigh trade-offs and work toward a decision. For months, my mantra was: “let’s not reinvent the wheel”. If someone else is already doing this better, let’s use it. We narrowed down the options to two, deep-dived on the products, and time-boxed our final decision.

After careful consideration and consensus-building, we chose Spotify’s Backstage as our foundation. As an open source project, it came with OS advantages: community support & collaboration and significant cost savings over the vendor options we’d reviewed. It accelerated our unification plan and gave our developers the chance to engage with a broader community, contribute upstream, and build skills in industry-standard tooling.

Switch design systems in parallel

Alongside the Backstage decision, we committed to Spectrum for all internal tooling. I believe in working as one company: if Adobe has a design system, every team should use it and contribute to it. There’s a dedicated team building a beautiful, holistic system for Adobe’s end users, using it internally was the obvious call.

The upside went beyond aesthetics. Using Spectrum gave our developers the chance to work closely with a system built by their coworkers, and to contribute back, improving it for everyone at Adobe and for the open source community using Spectrum beyond Adobe.

Redefine UX & Product Engineering team

Finally, we redefined what the UX & Product Engineering team was actually doing. We audited the previous years’ work and drew a clear line between what we should own and what should move back to the tool-specific sprint teams. The plugin architecture made this a natural change because teams could now own and maintain their own plugins. We documented the contribution process, set up office hours for UX consultation, and rolled it out across orgs. The goal was to make it easy for teams to do good work without us as a bottleneck.

Outcomes

Developer Home launched as a unified portal combining the UIs of ~7 teams and 15+ tools. And people actually used it.

By six months after launch, 82% of Adobe development teams were onboarded onto the platform, and the adoption growth rate had increased 60%. Deployments through Developer Home were also up 14% in that time. Monthly active users hit 3k, and an NPS of 32 confirmed that the consolidated experience was working for developers.

The contribution model also took off. Teams contributed 6 plugins at launch with 7 more built as fast-followups. That was early proof that the shift from centralized execution to a center of excellence could scale the way we needed it to.

Developer Home showed each service with a rich detail view, bringing together DORA metrics, a service maturity score, cross-linked tooling (GitHub, Jira, Argo CD, Kibana), and deployment status in one place. The context developers used to chase across more than six different tools was now a single tab away. And that was just the start.

Lessons Learned

Be a gardener over a gatekeeper

This is the title of a talk I gave at Oredev in Sweden during this initiative. Letting go of control and helping people do what they want to do will make your work better and more fun.

In platform work, adoption follows ownership. The easiest way to get engineers to use your tools is to make them feel like the tools were created with their collaboration, not to mandate compliance. Remember that everyone wants to build things other people enjoy using.

Let go of your darlings

Over a long career, you will say goodbye to products you built. Nothing stays relevant forever. Sometimes you make the wrong tooling call; sometimes you build a design system that gets eclipsed by a better, company-wide one. The natural instinct is to hold on; the thing you made feels special. Resist it. Build a culture that rewards pivoting when the time is right. Otherwise, you become irrelevant.

Sometimes you have to say no

Not everyone embraced the shift to team-owned plugins. It meant new responsibilities and a learning curve. But the alternative was asking a small team to own an overwhelming amount of work that wasn’t fully in their control, with blurred ownership. The right call required assessing who was best suited for what work, now and in the long-term. Each plugin required deep domain knowledge and ongoing maintenance, things that only the owning team could sustainably provide.

This project was, in many ways, the culmination of everything I’d been working toward since joining the team as its only designer. The real work was never just the technology. It was proving that the best thing a small design team can do in a large engineering org is make itself less necessary, not by stepping back from quality, but by making quality the path of least resistance. Developer Home launched, teams adopted it, and engineers were shipping plugins without us. That’s the outcome I was most proud of.