Scaling developer experience across 1,000 engineers at Dropbox

Engineering Enablement by DX

0:00

-39:01

Scaling developer experience across 1,000 engineers at Dropbox

I talk with Uma Namasivayam of Dropbox about treating developer productivity as a business problem, running developer experience like a product, and building foundations that make AI useful at scale.

Abi Noda

Feb 06, 2026

Listen and watch now on YouTube, Apple, and Spotify.

Developer productivity is often treated as a tooling problem or a sentiment problem. In reality, it’s neither. It’s a socio-technical systems problem that spans engineering foundations, leadership alignment, organizational design, and culture.

In this episode, I’m joined by Uma Namasivayam, Senior Director, Engineering Productivity at Dropbox, to explore how Dropbox approaches developer experience at scale. We talk about why productivity needs to be framed as a business problem, how executive alignment creates the conditions for meaningful change, and what it takes to treat developer experience as a real product with developers as customers.

We also dig into Dropbox’s approach to AI adoption. Uma shares why strong foundations, such as build, test, and observability, are prerequisites for AI to actually accelerate work, how Dropbox encourages daily AI use without mandating a single tool, and where build-versus-buy decisions break down at scale.

We close with an honest look at what remains unsolved: how to connect gains in developer productivity and AI-driven capacity to real business outcomes, and where engineering leaders should focus next in 2026.

Some takeaways:

Developer productivity is a socio-technical problem

Productivity cannot be solved through tooling alone; it spans engineering systems, leadership behavior, organizational structure, and people practices.
Problems like build and test are engineering problems, while problems like focus time and interruptions are people problems, and both matter equally.
Treating productivity as a system forces tradeoffs to be explicit, rather than hidden inside isolated tooling initiatives.

Executive alignment matters more than any single metric

Top-down sponsorship creates permission to act, especially when productivity work cuts across org boundaries.
A shared framework creates alignment, not answers; its value is giving leaders and engineers a common language.
System metrics matter more than single metrics, because productivity improvements rarely move one dimension in isolation.
Distributed accountability makes productivity a company problem, not a developer experience team problem.

Developer experience works best when treated as a product discipline

Developers are customers, and their experience must be understood through both qualitative feedback and quantitative signals.
Good system metrics do not guarantee good developer experience, which is why sentiment and perception matter.
DX surveys surface where systems break differently for different teams, such as desktop, mobile, and web developers.
Continuous feedback loops are essential, combining surveys, direct conversations, and usage data.
Internal communication is part of the product, reinforcing to developers that their feedback leads to real change.

Prioritization requires structure, not intuition

Finite capacity makes prioritization unavoidable, even in large, well-resourced engineering orgs.
Segmenting developer populations clarifies tradeoffs, since different teams experience different bottlenecks.
DX survey data provides a defensible starting point, but prioritization still requires judgment.
Leadership-level stack ranking helps resolve conflicts, especially when multiple teams compete for attention.
Frameworks make hard decisions easier to explain, even when they do not make them easy.

AI and developer experience must advance in parallel

AI accelerates work, while developer experience reduces friction, and both are required for sustained gains.
Foundational systems act as plumbing, enabling trust in speed, quality, and safety.
Without strong CI, testing, and observability, faster code creation increases risk instead of value.
Trust in guardrails enables confidence in AI-assisted development, especially at scale.

AI adoption succeeds through choice, not mandates

Early organic adoption revealed real developer needs, rather than forcing a single tool.
Different teams require different AI tools, particularly for mobile, desktop, and large-repo workflows.
Supporting multiple tools increased adoption, rather than reducing it.
Daily use depends on fitting AI into existing workflows, not adding extra steps.
Habits matter more than access, which is why SDLC-level integration is critical.

Build vs. buy decisions change at scale

Many AI tools fail when tested at large-company scale, despite working well in smaller contexts.
Cost and performance become gating factors, not feature completeness.
Internal platforms can abstract complexity, enabling teams to build AI workflows safely and consistently.
Shared internal platforms unlock reuse, allowing teams to innovate without rebuilding infrastructure.
Speed of iteration remains the primary differentiator, even when building in-house.