# Dropbox DevEx Strategy: AI and Productivity

**Podcast:** Engineering Enablement by DX
**Published:** 2026-02-06

## Transcript

Working with our chief people officer and the people team, we had to actually literally think about how do we restructure meeting times?
How do we actually think about giving blocks to the employees?
That is a very different problem.
It's not an engineering problem.
So that's why having a common language and also bringing the people together and the leadership team was very, very important because we had to attack productivity from multiple different angles.
Welcome to this week's episode of the Engineering Enablement Podcast.
I'm your host, Laura Taco, and this week I'm joined by Uma Nabasimiam.
a senior director of developer experience at Dropbox, where we're going to talk about developer experience, AI, how they intersect, and what really great executive and organizational support for developer experience initiatives looks like.
Welcome to the show.
Welcome, Uma.
Thanks for joining me.
Let's set the stage a little bit and talk about Dropbox as a company.
Dropbox is a really engineering-first kind of company.
You've got engineering deep in your DNA.
Can you tell me a little bit more about the size and scope of your engineering org your role you know what you're setting out to do thanks for having me laura so um dropbox um we as you said is the engineering dna we have uh close to a thousand engineers in the company and we ship products and the files in can share that was the bread and butter for dropbox now we are in the world of dash which is focused on ai enterprise search and assistant So in terms of productivity specifically, what my team does is we are looking at engineering productivity across the company.
That includes the core organization that ships the core products, the Dash organization that ships their AI products also.
So my team looks into the CI CD systems, the telemetry systems, and also overarching the AI rollout within the company for all the engineers.
So the way you should think about it is my engineering team and my product management team looks into the overall experience of the developers and how we can actually improve their productivity through the use of AI and also the overall day-to-day experience of how we are shipping code to the customers.
For a company with so much engineering focus, it's not surprising that there's a lot of engineering muscle behind productivity and platform initiatives.
But you're thinking about this not just as a technology problem, right?
You're thinking about it as a...
as a business problem.
Can you talk a little bit more about where that mindset came from?
Yeah, it's a great question.
And I think that is one of the, I would say, of the differentiator in terms of how we are approaching productivity within our company here.
So I think of a productivity problem and Dropbox as more like anywhere actually as a social technological problem.
Yes, there has to be a very strong investments in the technology itself to improve the foundations, to improve the reliability.
to improve the speed of the system and whatnot.
But then there is also the element of collaboration, the element of working with the leadership team, working with developers themselves, and also working with the people team.
It's all about bringing the people together so we can solve towards how we can improve productivity.
There is also an aspect of the overall improving the culture of the organization as well, like why actually productivity matters for the company.
How do we think about business impact?
So for me, when I think about productivity as such, as a concept, it started in 1950s with respect to the production system, right?
This is not something unique to the world.
But when it comes to the applying the world of software, when we connect towards the arc of what does it actually help with our customers, bringing that mindset into the picture.
Clarifies a lot of things for our developers, clarifies a lot of things for our cross-functional partners also.
So ultimately, when I think about productivity is how do we actually bring value to our customers as fast as possible in the highest quality and the best possible way to our customers.
So that framing sort of helped not only our engineering team, but also the leadership to rally behind this whole construct of productivity within Dropbox.
And executive leadership is something that's so important when you're operating at the scale.
You have, you know, a thousand developers.
tying productivity back to business outcomes is crucial for getting the story straight from start to finish about how this benefits the business.
It's not about ping pong and beer.
That's often what we talk about, the kind of marketing problem of DevEx.
Can you talk a little bit about how strong executive sponsorship just accelerated and enabled a lot of success when it comes to DevEx and productivity?
So I think one of the things that actually helps us, and I think I'd be very candid here, is Drew is also an engineer.
I see a lot of interviews and I think we all know that actually helped us a lot in terms of setting the context also.
So even when it's thinking about AI rollout, he's a very big fan of using AI coding tools and whatnot.
So his thought process was, hey, if it's helping me do my job much better with AI, why does it not help my developers do the job better?
So that framing really, really helped.
But that...
The leadership alignment was even more important for us was when we actually approached this problem from the perspective of, okay, it's not a single metric that we're trying to move, but it's actually a system metric that we're trying to move.
A good example is DX code for the metrics that DX offers.
It was very useful for us because we had benchmarks.
We had not focused on a single metric, but multiple dimensions.
So when we bring this to the leadership team, it resonated with them very, very well in terms of, hey, we are not just focused on one single metric, but a framework of metrics.
And that also helped drive the alignment from top down to making sure that we are actually focused on the business problem itself.
So that helped us also to go towards the world of...
how we can improve productivity as a system, looking at multiple aspects of things, not only system metrics, but how does the developer experience improve?
What is the impact that brings to the table?
It was a very cohesive way of bringing things, but that top-down mandate helped us a lot in terms of varying the deep care.
Another point of improvement that also helped us was since we had the leadership alignment across the board, it was not a single team problem.
Yes, I own developer productivity in Dropbox, But ultimately, it's a shared problem.
Every developer, every manager, every leader within the company has to be thinking about productivity and making sure this becomes like a central accountability for the company, I would say was the biggest win that we had with respect to leadership alignment.
One thing you shared in preparing for this conversation was that adopting that common language.
So in this case, the core four framework and having alignment on how.
everyone from your leadership to your engineers are thinking about productivity didn't give you answers.
It gave you alignment so that we're all kind of directing effort in the same direction and see it as a business problem and a shared responsibility and not just something that's about developer sentiment only, but really that it's a crucial, it's a crucial operational and kind of crucial business performance aspect for Dropbox.
Yeah, totally.
100% agree with you.
um i think one of the examples that i always think about when i think about productivity and why this is actually a common thread that connects all the teams is um let's say for example developer experience there are multiple dimensions to it i'll take an example of build and test the things that we do for my technical standpoint how we're building software That is actually a very strong technical problem that we can solve.
And that requires talking to developers, what pain points they're facing, how we standardize some of the tools that we have.
So that is a very engineering-driven problem that we can solve.
But then there is another dimension when we talk about productivity is, as a developer, am I actually focusing on the right things for the company?
Do I have focus time?
Can I actually code on the right, unfiltered, there's no interruptions?
That is a very different people problem.
So working with our chief people officer and the people team, we had to actually literally think about how do we restructure meeting times?
How do we actually think about giving blocks to the employees?
That is a very different problem.
It's not an engineering problem.
So that's why having a common language and also bringing the people together and the leadership team was very, very important because we had to attach productively from multiple different angles.
And that's why I keep on hammering the point that this is a social technical problem, just not really a technical problem.
Collaboration is really key.
I think one other thing that stands out to me is that you're really treating developer experience in platform engineering as like a product problem where your developers are your customers.
Can you talk a little bit about that and how that mindset changes the way that you approach developer experience in general?
I think that I would say that was actually one of the biggest leg of improvement that we had in actually making sure productivity was actually like I was able to turn around in the company.
So just to give you some context, right?
a Dropbox has been built with bespoke tools in the past.
We wanted to always move fast.
We had different set of tools in the past and there was not a lot of standardization at play.
So that was an effort that was ongoing quite some time in terms of how do we standardize the tools?
How do you make sure that it's reliable and it's actually moving at a full speed?
That foundation was actually happening, which was great.
But then when the problem was looked at, let's say, in late 2024, it was okay, we feel like the systems are actually doing well from a system metric standpoint, but then developers felt like it's very, very hard to ship forward in Dropbox.
It could be a perception, it could be a problem that they're facing, but you're not able to connect to actually the system metrics that you're thinking about.
For example, ATL, TTL, time to land, attempts to land were actually really, really good, but developers are still feeling the pain.
So in that lens, when you think about why is this problem happening?
the biggest shift that we had was like, how do you think about this problem from a product mindset?
Okay, my product is great.
Why is it actually causing a problem with my developers who are our customers?
So connecting that arc required a mindset shift in terms of how do you think about the problem from a product perspective?
So we literally started thinking about getting the DX survey, which was very useful to kind of analyze what developers are actually saying about different parts of the system.
What are the pain points they are facing?
So it gave us a good way of thinking about the problem, like where to actually focus on, and nothing beats talking to our developers, right?
Like the PMs in my team, they talk to the developers, the TLs in my team, they talk to the developers.
They understand what their pain points are, where in the system it's actually breaking.
Having that feedback loop and understanding different parts of the system have different problems.
A good example is our desktop developers had a very specific problem in build and test.
The web developers had a problem in production debugging.
So it's a very different problem that we need to solve for and having that kind of mind share and also making sure that leaders in the team are also investing towards some problems.
was helping us connect the whole box here and that's why I think we were able to tackle the problem and change the perception around the productivity.
The second piece of the puzzle which people may also not consider and which I think is very important is the internal communication piece.
You have a product, you talk to the developers, then what does it actually mean in terms of selling the product to the developers to say these are absolutely wonderful.
But that's also where the VMs came into a big support here.
sharing of the story, not only to leadership, but also to the developer saying that, here are the updates that you're doing to our product stack.
Here are the things that are changing in our developer stack based on the feedback that you heard.
So that reinforces the learning between the developers and the system, which actually gave us the edge in terms of moving a lot of metrics that we thought were useful about productivity.
And I imagine just as you are prioritizing features and prioritizing new things for your customer end users, you're looking at all of this data and prioritizing the parts of your own internal product, your developer experience that you're going to work on for your internal customers, your developers.
Can you give us a glimpse into how you make those hard choices?
Because even a company with as many resources as Dropbox still needs to make a tough call about doing something first and doing something second.
You know, in that example about the desktop folks struggling with build and test, but web folks struggling with production debugging.
How do you decide what happens first and which sequence these problems get fixed?
That's a great question.
I think we are actually learning how to go.
I mean, there is not a great answer when it comes to prioritization, as you know, Laura.
But at least a couple of things helped us move in the right direction.
One, I was mentioning earlier, the leadership alignment piece was very, very useful.
And as part of that, what we also did was we made this as a distributed accountability for all the engineering VPs, the core VP, the dash VP, the CTO organization.
they would all have to invest x percentage of the resources and productivity.
So that's like the top level construct that we were able to align.
Now, once that capacity is there, now the question of prioritization is what you're asking.
So we definitely relied a lot on the DX survey metrics in terms of how we prioritize.
what are the top five pain points that we have within the company, and then going into another level of segmentation, like when I talked about desktop mobile versus web different developers.
Once you have a clear matrix like that, and then you know what capacity you're going after, then it comes down to roadmap planning, and it comes down to saying that, hey, all the teams provide your bottoms-up work in terms of how we can fix these problems that we have with respect to the X survey.
And then it comes down to stack ranking with the DPs in the room saying that these are the problems that we're going after.
These are the things what the developers are saying.
Here is how much capacity that we have in the different teams.
Here is how much segmentation that we have with the developers.
Now let's put the vote to the pin and then save pin to the vote and say how we can actually fix the download productivity.
So that's how our prioritization scheme went.
And always, like you said, it's not a rocket science, but at the same time, having some...
framework that's thinking and rationalize about that made these conversations much easier.
And there is always going to be a large backlog that you can go after.
But this framework actually helps you to prioritize really well.
I think that's reassuring for some of our listeners to hear because it's very easy to look at the great work that you and your teams have done and think, oh, that's inaccessible to us.
We can't do that.
They don't have the same problems that we do.
But truth.
be told you also still have prioritization problems.
There's still finite resources.
You still have to make tough calls about what to do first and what not to do at all.
As you said, there's a lot of things that we're learning as we go.
You mentioned something earlier about, you know, strong executive sponsorship and how that makes it.
You know, you've got visibility on these DevEx pieces from the top down, from the bottom up, and you're able to align your DevEx goals to the company goals at scale.
Can you talk a little bit about how that alignment works?
Like, how are you connecting these DevEx projects back to business value?
Like, where are you on that journey?
Have you cracked the code of doing that really well?
I think this is something that keeps me up.
all right, and my teams also in terms of how do we connect back to the business impact.
So when I think about the R grade, so the way I think about it is in 2024, it was about like, how do we actually fix engineering?
Maybe had the foundational issues.
That was a different set of metrics.
In 2025, it was about like what framework we're using towards GetDX, right?
The DX code for framework we used.
And you were able to move metrics along multiple lines.
Whereas the speed line also moved very well.
Quality was, card was there.
Impact was there.
We are almost very close to getting the benchmarks on our DXI metrics also, which is the developer experience side.
But then connecting back to the business impact, that is a code that is, in my opinion, very hard to crack at this point.
The reason I say that is it requires a lot of input from not only the developer experience metrics, but also what products that we're trying to ship.
So we are in the journey of connecting these developer improvements plus how much it helps you to reduce the time leadership features back to the business impact.
And that is a code that has not been cracked yet, in my opinion.
We are trying to connect all the data.
We're working towards how we can show that impact much better.
Having said that, for 2025, what was useful for us in terms of channeling the crew and the leadership towards a business impact was moving DXI, we felt also will help you save the amount of hours that engineers are actually spending on actually writing code.
towards shipping products much faster.
So we were able to see evidence of that in multiple areas, not only in experience, but also through the use of your adoption.
So that was the metric that we were using back in 2025 to kind of connect back to the business impact in terms of how we can ship products faster to our customers.
Great segue, because I do want to talk about AI.
Dropbox has been, Dropbox is a developer DNA kind of company, and you've been working on and emphasizing the importance of developer experience.
for a lot longer than AI coding assistants have been kind of on the market.
But when they arrived, they arrived in a big way, very high level.
Can you just give us a little bit of introduction to like, how do developer experience and AI coexist in your world?
And I think this is definitely a hot topic for anybody, any engineering leader out there.
So I would say, so back.
I think early 2025, late 2024, we started on the DXI journey.
Definitely, that was a developer experience journey that happened.
I think of AI coming in at the time when coding assistants were actually taking off big time.
I think at that time, roughly one third of engineers were using AI in a very, very organic way.
People were actually going after the coding assistant they like.
But then when I think about when the takeoff happened with respect to AI, it almost became two different work streams in my opinion.
There is this whole, how do you reduce the friction in the existing system, which is the DX side of the journey, which is one.
The other is the AI, how do we accelerate the journey in terms of getting it together.
It almost feels like you are rebuilding your car as you're accelerating.
That's how I do that.
It's almost like two different journeys that was in parallel.
It cannot be sequential as we all know, but it had a lot of overlap in the middle also.
So I would also characterize DX and AI in a different way.
DX is all about, like we discussed earlier, it's about defining what the problem is, aligning with leadership, and then slowly making those incremental changes as you standardize the system towards friction.
AI is all about speed.
Like, how do I actually get the best tools possible to our developers?
How do we experiment faster?
How do I train faster?
So we're always on the cutting edge of the technology.
So these two are actually in a parallel work stream, but they actually came in together in a lot of different touch points.
That's how I see those two work streams come along in Dropbox.
I wonder what...
From your point of view, what were some of those core developer experience building blocks that needed to be in place as a prerequisite for AI to take root and to accelerate?
Because they are, as you said, they're not totally separate.
There's a lot of crossing of streams.
But in a lot of ways, the DX practices help AI accelerate.
Can you think of a couple examples of like, what are you, from your point of view, what are those prerequisites?
Yeah, so I like to share one of Drew's quotes.
Drew, I would say that if your plumbing is not good, there's no point in beautifying your house, right?
I think the developer experience, I think of that as like your plumbing.
So everything stops if it doesn't work, right?
So that's pretty much the analogy that I would use here.
So getting back to your question, right?
I think the fundamental piece of...
you know build and test you know your telemetry system your production debugging system these all have to be in place to be in a really really good spot before i in my opinion where yeah i can actually actually have a lot of feedback the reason i say that is the speed at which like the air coding assistants are going the speed at which the developers are using ai to like push code they need to also have trust in the system that if i push code it actually has tested properly the quality cardinals are actually met the compliance angles are met, the security scans are met, and then when it actually goes to production, leadership plus engineers have the confidence that the ship, the code that I'm actually shipping will land and also have no issues in production.
So building that level of trust, the foundational systems have been very, very strong.
So I would anchor on like those foundational systems being super strong in terms of reliability, in terms of quality before we actually go really, really hard on AI.
So that would be my take on that.
And you have a pretty experimental mindset.
Like it's not about perfection, right?
It's about experimenting faster.
Most of your developers are using AI daily, weekly, and you're really, you know, focusing in on encouraging daily use.
Like what are some of the things that you're doing to encourage daily use, sustain daily use so that it becomes a new way of working and not just a temporary kind of state of being that's going to, you know, fall out of fashion?
So let me take back to in terms of how the journey of AI happened that can actually kind of explain like in terms of why, how can we make it more sustainable and sticky in a way, right?
So I think early 2025, like I said earlier, one third of our developers were using in an organic way.
And then there was huge uptick in the coding assistance, as we all know.
And I think we had strong leadership as our executive team alignment saying that, hey, we need to be also taking AI as a very serious company priority.
So that kind of felt in kind of like initial stages of like increasing your AI adoption.
So I would say like three fourths of people were starting to use on a weekly basis within like three months or so because of the top down help that came down from the exec team.
But beyond that, then it goes back to the product mindset also, right?
Like you have to look at like what developers are actually looking for different coding as it comes.
Today, we use like three or four different coding assistants that is available to our developers.
We are not like one single coding assistant shop going after the, hey, this is the only thing you have.
Different teams have different needs.
So going after like, for example, mobile team, they cannot use the existing AEC coding tools that are out there.
So we had to find that as something very specific for their use cases.
So that kind of helps add you to the option metric that you have, right?
So looking at these kind of pockets of areas where developers had what's working for them, what's not working for them, and providing those kind of tools definitely helped us to fix the long tail and we're able to get close to almost everybody's using AI tools right now on a regular basis, right?
But now how do we actually take it to the next level?
Now, again, we have to go into the habits of our developers, right?
Like what are the areas of core SDLC that is actually helping them or blocking them to not use AI?
Are the tests not being written properly with AI?
What are some of the things that we can do as a central team to kind of enable them?
So looking after every finer details of HDLC also will help you to make it more and more sticky.
And the second aspect of it is also like the PM team works very, very closely with the vendors.
And they are also making sure any updates that are needed.
that's required from the developers.
We are also communicating to our vendors to make sure that is also incorporated in them.
So that type of feedback loop also helps you to make the product more sticky and helps us to get the maximum bang for the buck with respect to coding tools.
Do you have any examples you can share of how your teams are using AI outside of just code completion?
So once the whole, once we started achieving like We started with coding tools as the first one because that seems to be the easiest one like everybody's doing.
Once we achieved whatever we could achieve there in terms of adoption, then naturally we need to start looking into the entire parts of SDLC.
The next aspect of it is we started looking into the review cycle, we started looking at the testing aspect of it, debugging aspect of it.
So looking at every single SDLC is actually going to be critical and we started doing that.
One thing that started resonating with us as we go into the POCs was there was a great way of tools that we started testing out.
There were a bunch of tools in different lengths that we started testing out, but a bunch of them did not start working for Dropbox at scale.
It was very easy for us to get carried away by, hey, this tool will work.
But as we started doing POC, we realized some of them will not work.
A good example that comes to my mind is in the review side of the world, we were using one of those marquee names and it just did not work for our scale.
So we then decided to actually think about how we start building those kind of tools in-house.
So we now have an in-house effort to start building those AI tools for specific use cases within SDLC.
So in terms of AI, build versus buy decisions are also very, very critical.
I don't know what specific for your own company is, but for Dropbox scale was a big issue.
And then as a result, cost was also a big issue.
So we need to think about what actually will help you move the needle faster and how can we actually unblock ourselves in terms of scale.
So that was the framework that we're using.
And again, like you said earlier, a lot of speed is going to be the biggest differentiator when it comes down to AI.
So having that lens, when you think about build versus spike, and this will really pass on the different phases of SDNC also.
How do you keep up with, you know, a thousand developers and this ecosystem that is just maturing at a really rapid pace and all these tools are coming out?
How do you keep up with...
the demand for tools?
Like I imagine that there's lots of developers coming and saying, hey, we want to use this tool.
We want to use this tool.
How do you manage that at scale while still, you know, still encouraging experimentation, but like doing it in a safe way?
Great question.
So it actually is, I wouldn't say it's happening naturally, but that is actually a method of the madness here.
Like I said earlier, the PMs on the team, they...
have a very tight pulse in what's happening in the market in terms of what tools are out there.
So we also do a lot of research in terms of what tools are getting matured, what tools are actually doing really well.
We talk to also our peers in terms of what they're using for AI tools.
So we have that intelligence happening on the external side of the puzzle.
The second one also, we leverage a lot of...
developer feedback, we have Slack channels, we have like DX surveys, you name it, any inputs that we get from the developers on what they are seeing on the ground.
We have a very strong triage process on like what softwares that they are also looking after and they want to actually use for their own purposes.
So the industry side, the developer side, and obviously leadership also, they have their own inputs of the link that we bring it all together.
Separately, we also worked with our own procurement and the legal and the security teams to reduce the time that it takes for us to experiment also specifically for AI tools.
And that also helped a lot.
I would say the biggest innovation in this one was reducing the whole review process from three days to three days.
I would say that was the biggest one in terms of moving really fast.
So once you have all these inputs into play, then we also have a framework on SDLC, like looking at which portion of the SDLC has the biggest impact in terms of when Java was saved, in terms of the number of PRs that are getting pushed through.
We can look into what impact scores that we have and accordingly we can prioritize them.
And the last one is my role and it's also to kind of manage expectation to be leadership.
You cannot have all the tools at the same time.
You need to prioritize that.
But again, having this framework and talking through this framework and the inputs that we have makes the conversation much easier with leadership and also with developers.
I feel like engineering leaders are caught kind of in a cross stream of really high expectations from leadership because they hear the hype cycle around these tools and what company X is doing.
And then developers are also hearing...
or like, you know, wanting to experiment with the things and you're sort of caught in the crossfire of needing to manage expectations both up and down and like make sure that everyone's needs are met, which is a really, really challenging place to be in, especially without data that you can back up and say like, OK, well, this is the actual result for our company.
And that's why we can't get this result that is shared in this LinkedIn article that's not plausible given our current environment.
Absolutely.
Talking maybe just a little bit into outcomes and some of the results of this great work, let's maybe start with the AI space.
So we already talked about like tremendous adoption, really sticky adoption.
Now we can get into daily work, we can get into other parts of the SDLC.
So it's not just about coding.
Do you have any other, do you have an example to share with us of something that was really innovative or just really, really impressive that came out of your engineering org or that you saw someone build with?
AI that you thought was just super cool and want to share with the audience?
There are a bunch of examples that come to my mind.
One of them is I'm very proud of one of the teams that are actually building, it's actually my team, they're actually building a very specific coding platform, I would say, where it takes into account all the third party assistants that we have, but then also works very specifically for Dropbox use cases when I talk about scale.
One of the things that I didn't mention was Dropbox is also a monorepo store where your repo size is very large.
We all know that some of the coding assets that we have may not actually work at the monorepo scale.
So we are actually one of the developers that we have.
He took it on himself to figure out what kind of platform that we can build using Cloud Code.
In terms of building that platform that can actually work within Dropbox.
and others can actually build on top of the platform to make sure, let's say, if I have a use case of building a review product using AI, if I start using this platform, it takes care of all the back-end problems that you have, right?
Like your deployment is taken care of, the scale of MonoRepo is taken care of, your testing is taken care of, and that platform I'm very, very proud of in terms of its adoption within our own company, and that's something that we're all looking forward to kind of.
having organic adoption on top of that.
So that's what I'm looking forward to in 2026.
I think that's such a nice example to kind of bring us back to the original point that we started on, which was developer experience, because it ties together how AI and building tools with AI does accelerate developer experience.
But thinking about the DXI, so the measurement of developer experience in the core four framework, you all have made tremendous progress of that in the last year.
Can you talk a little bit about that as well?
I think 2025 was a very strong year for DXi.
And we also, we haven't reached our benchmarks yet, but at the same time, we've made a very tremendous progress.
So some context on also DXi, right?
I think for folks that don't know, DXi is kind of a sentiment metric, but actually is very useful in terms of looking at.
multiple dimensions of a developer experience and that is very, very powerful.
So getting back to the initial discussion around like leadership alignment, right?
Once we know DX is very important and we made that company priority.
There was a lot of skepticism even within like engineering as well as like leadership.
Like, hey, we are going after a sentiment metric.
How can we move this metric?
It's not done in the past.
Like we've had DX surveys in the past.
It's not very easy to move.
And anecdotally also, like I was mentioning in 2024, the system metrics on the foundational pieces were improving, but the sentiment was not moving.
In fact, it was actually dropping in a lot of use cases, right?
So there was a lot of skepticism around that within engineering and we had to solve for it.
So that's what I feel like, you know, I, I also learned, are we here a lot where we actually went back and said, hey, have you had any companies that were able to move these metrics and give us very helpful in terms of showing industry benchmarks what is possible, what's not possible?
And then we took a bet on ourselves.
If somebody else is able to do it, we should have set an ambitious target and we have to go after that.
So even like convincing our leadership team to say that, hey, here is where the benchmark is.
Today we are here.
Everybody wants to make it happen in the same single year.
So convincing them to show that it requires a very different approach for different problems.
For example, telling the Red Bull and test is a technical problem.
Deep work is a people problem.
Documentation is an engineering-wide problem.
So it's a very different problem space.
So making them appreciate the fact that it is not just one metric, it has a lot of things that go under them.
And actually making sure it's a multi-year journey helps us a lot.
And then, yeah, I'm proud to say that we exceeded our targets that we set for 2025.
And that's truly because of very, very focused efforts on individual pain points, working with the developers and having a very strong priority scheme.
And we're able to move the metric.
I'm actually very proud to say that we have exceeded the metric for 2025 and we are on the journey towards meeting the benchmarks in 2026.
So it's been a very remarkable journey and definitely all the skeptics that were there in 2025, they are like, okay, this is possible.
And we are all marching toward what can we be doing in 2026.
So it's a very, very great story for us.
I like how you went from...
internal skepticism and looking out for an example in the industry to being the example in the industry.
And I'm sure there are lots of folks listening to this podcast right now that have listened to your story and listened to the great work your teams have done and thought, wow, that's really aspirational.
I would like to do that as well.
What are some little nuggets of advice that you would have to those people listening who want to get to the same kind of results and maturity that Dropbox has?
You know, what are the things that they should definitely keep top of mind?
Looking back into the journey, I think, actually, I'm going to again, is treat this problem as a socio-technical problem.
You need to have a very strong product mindset in terms of How do we actually move developer productivity within the company?
That means that you work with your developers very closely, you understand their pain points, you set your strategies accordingly, you prioritize your roadmap based on all that.
So having that goal and then making sure all your plans are aligning towards the goal is extremely critical.
And that's one piece of advice that I would give.
The second one is also we should not underestimate the importance of leadership alignment and culture.
In my opinion, If that is there and then you have a framework, things will automatically happen.
So I would highly, highly encourage folks to think about what is the best way you can get your leadership aligned on a basic framework, whatever it is, and then let's go after that.
And also think about culture very, very...
early stages also don't wait for you know hey let me get my stats to a certain level and think about culture it needs to go hand in hand and talking to your developers and talking to your communication partners and talking to your like what's out there in the industry it all has to come together that would be my piece of my advice and then things will automatically happen And I think listening to, you know, we're talking about this for a half hour, it is kind of a highlight reel.
We don't want to brush over the fact that these are a lot of this is multi-year investment.
There's a lot of hard strategic choices.
You also had to make some really important like capacity choices as well in order to facilitate the this amount of work.
Maybe you just speak about that, like the reality on the ground of what allowed you to achieve all of this.
Yeah.
So the.
The point we made earlier about capacity here is all of these projects, when you think about it, I know that the productivity is critical, but then we also have to ship products for revenue.
So that actually call is going to be hard.
So if developer productivity is important, it is a multi-year journey.
There is no question about it.
Not only from the fact that we need to actually make the system stronger and also invest in those systems to make sure those are all standardized.
It takes time.
It's a pure...
challenge of prioritization as well.
Even today, we always have a very healthy debate between the product and managers and the team and our team in terms of why is productivity important, what is the ROI we can get.
Having those challenging conversations over and over again is important.
It's a healthy debate, but ultimately it's up to the engineering leader or the product leader who is driving it to keep the mandate moving.
So it is important for the company and it's a multi-year journey.
So that's where I think the frameworks, the prioritization and the capacity management comes into play.
And ultimately, it's a struggle, but it is possible.
That's all I can say from my own experience in Dropbox.
One last question for you before we wrap up our conversation.
I would love to know what you're most excited about when it comes to developer experience and AI looking ahead to 2026.
Great question.
So 2025 is behind us.
It was a strong year.
But then, as you know, in 2026, the question that everybody's asking across the industry right now is, okay, AI is there.
Most of the companies are adopting them in different forms and fashion.
Coding systems are awesome.
I get all this capacity.
Where is it going?
Like that question comes up across from our CFO, from our engineering leaders, across the world, right?
So how do you answer this question?
Like it's not an easy question to answer, to be honest, because from anecdotally what we have seen, we have done some initial analysis and I can happy to share here is, yes, we have seen a capacity uplift because of AI.
And naturally, it's actually going towards like the migrations, the tech debt reduction.
And these are automatically happening.
Like this is what is very cool about engineering.
You have the capacity to automatically close into the right things for the problem.
And we are seeing that.
Now, how do we systematically think about it?
If I'm an engineering leader, I have the traditional capacity.
There is a world where I can focus on tech debt, but then there is also a world where I can shift it towards product development.
So how do we actually make those tradeoffs?
It's not very clear.
Those instrumentation and telemetry is not there yet.
One approach that we are taking is we are trying to connect all these productivity improvements that we're trying to do the roadmap and to the product roadmap also.
And it's not a very one-to-one relationship.
So for the listeners out there, if there is a better way for us to actually solve for it, if we have actually cracked the code, we would love to talk to you also.
It's not an easy one to actually fix.
But that's what I'm looking forward to in 2026, like how do we crack the code on the improvements that we're getting from developer productivity, how do we tie it back to the business outcomes, to the real business outcomes in terms of time to shipping the features and also where the additional capacity is going, how do we answer that question?
That's what I'm actually focused on in 2026.
Yep.
Me too.
I think a lot of engineering leaders are in the same boat.
Uma, thank you so much for sharing your story, the approach that you've taken at Dropbox, your successes.
I am looking forward to seeing what you all accomplish in 2026.
I think it will be a beacon for the rest of the industry if you're listening to this and think...
wow, this is really great work.
It definitely is.
And it's a lot of hard work.
And I think Uma shared so many really great strategies for the audience to take away.
So thank you so much.
Thank you, Laura.
Thank you for having me on the podcast.
I know I think productivity is going to be extremely critical in the coming years.
And I'm happy to share the nuggets that we learned from Dropbox.
And I'd also say that DX has been a great partner.
We've been able to get a lot of leverage from the GetDX Core 4 framework.
So that has been helpful for us to align with the leadership.
So thank you so much for all the...
participant collaboration.
Thank you.