Today, more and more companies are creating dedicated infrastructure for development optimization, Developer Experience (DevEx or DX). DevEx specialists identify bottlenecks in the development processes, address issues that consume engineers’ time, and increase team productivity. Artem Mukhin joined Microsoft as a Frontend Engineer and later succeeded in creating a new role tailored specifically for him, Developer Experience Engineer. Artem shared why he decided to focus on DX, the challenges he tackled, and how his work impacted company-wide processes.
Discovering Developer Experience Before It Had a Name
Artem, you joined Microsoft as a Frontend Engineer. How did your responsibilities evolve, and how did a new role, Developer Experience Engineer, come to be created for you?
Before Microsoft, I worked at Yandex for seven years. While the conditions were satisfactory, I wanted to continue developing in an international company and was preparing to change jobs. In 2021, Microsoft noticed my skills and offered me a Frontend Engineer position. Typically, interviews at large IT corporations take a long time, but in this case, I completed all the rounds within a few days and received an offer to join the Skype team.
It is worth noting that at all my previous workplaces, I primarily focused on speeding up and optimizing tasks; for example, I could complete a month’s workload in four days. At that time, I didn’t yet know the term Developer Experience, or DevEx, but when I encountered it at an IT forum, I realized this was exactly what I had always been doing.
Optimizing Legacy Products: Early DevEx Initiatives on Skype
When I joined Skype, I understood that such a complex and “legacy” product would have many unoptimized development processes and elements, from UX to onboarding new employees. So even before officially starting on the team, I compiled ideas for product improvements to implement quickly. Once on the Skype team, I began working on my ideas and successfully executed many initiatives.
Two or three times a year, Microsoft employees fill out a table indicating what they accomplished and what they would like to work on next. I wrote that I wanted to focus more on DevEx and proposed several optimization ideas. I also presented my proposals to managers and even met once with the head of Skype development to discuss DevEx. As a result, he offered me the opportunity to try this role.
Why Microsoft Formalized Developer Experience as a Dedicated Role
I went on to implement several major changes that significantly improved the efficiency of development processes. For example, I accelerated local mobile builds from 1–2 minutes to just a few seconds. This greatly enhanced the team’s feedback loop and workflow; my work was highly appreciated both within the Skype team and later when transitioning to the MS Teams division.
I also conducted an extensive analysis to remove one of Skype’s key libraries, categorizing usage types, assessing automation potential, and preparing a detailed migration plan with a Gantt chart, documentation, and scripts. The project was paused due to Skype’s closure, but the methodology was documented and will be used in future projects.
To consolidate various DevEx metrics for Skype, I created a dedicated portal. I also implemented an interface to analyze npm libraries installed in the project, including their update history, relevance, and potential security vulnerabilities. There are no fully comparable tools to this interface.
Since I have expertise in UI design, I also proposed UX improvements for the product, some of which were implemented.
Tackling Workflow Bottlenecks in a Large Legacy Codebase
What challenges in workflows prompted you and the company to formalize a DX focus?
When I got acquainted with Skype’s development processes, I noticed a lot of daily routines that consumed significant time. For example, local builds were a major problem, checking the code across all platforms where the application ran: browser, Android emulator, iOS, Mac, and Windows. Builds, especially mobile, were difficult to configure and frequently broke.
As often happens with legacy products, technical debt had accumulated within the application. I reviewed the libraries and test frameworks in use, documented the problem areas, and drafted an improvement plan to simplify and accelerate future development.
These two issues were key in motivating both myself and the company to develop a dedicated DX focus.
How Local Build Times Were Reduced from Minutes to Seconds
Can you explain in more detail how you accelerated local builds, and what were the key solutions?
This issue frustrated many developers but was long ignored. I approached the developers, explained that I understood their pain points, and suggested working on it together. This helped get started; colleagues saw me as an ally.
Due to technical debt, we didn’t realize that our tools already had a function that could speed up local builds. We needed to update the build library and enable fast refresh, allowing only the changed element to reload instead of the entire application. I spent about two weeks researching, found the right tool, and figured out how to use it to accelerate our work. As a result, we reduced mobile rebuilds to a few seconds. Previously, each build took 1–2 minutes, and considering that developers run it dozens or hundreds of times a day, this was a huge time saver.
This is a clear example of how DevEx can optimize work with minimal effort. The solution was simple, but since no one had looked for it, developers had spent years on inefficient development processes. With my involvement, development became much faster, and engineers no longer had to wait; they could check new code in seconds.
Measuring the Impact of Developer Experience Improvements
How do you measure the effectiveness of a DX engineer and similar initiatives? Which metrics truly matter?
Publications on the topic usually discuss development process efficiency and the overall state of DevEx, at what stage it exists, and which innovations have been implemented.
We approached evaluation by comparison, “before” and “after” a change. For example, with builds, previously a developer waited several minutes; after improvements, it was just a few seconds. This allowed us to record the specific impact of changes on tasks.
DevEx Metrics: What Really Shows Results
Sometimes broader frameworks are used to assess DevEx effectiveness: DORA metrics (release frequency, deployment time, mean time to recovery, and change failure rate) and the SPACE framework (developer satisfaction, productivity, activity, communication, and process efficiency). However, these primarily reflect the development environment and development processes, not the output of a specific DevEx engineer.
In general, DevEx effectiveness can be measured using quantitative metrics, build time, test execution, deployment time, bug count, etc. Qualitative metrics can also be applied, such as developer surveys, analysis of team chats, and feedback on implemented changes.
Why More Companies Are Investing in Developer Experience Teams
Why do you think more companies are now creating DX as a dedicated focus or even a separate team?
The first investments in DX were made by large companies, Google, Microsoft, etc. This is understandable; corporations have huge potential and resources, but if their core tools are inefficient, progress slows significantly. Large products often have accumulated technical debt over the years, whereas startups usually have a newer codebase, so issues are less critical.
The Business and Engineering Value of Developer Experience
As a result, in large companies, developers spend a lot of time not on core tasks but on problem-solving, mitigating incidents, downtime, etc. One option is to hire more developers, but technical debt grows, and required resources increase. Another is to optimize processes to avoid staff expansion and develop faster.
Introducing DX is a win-win strategy for both the company and employees. The business gains accelerated productivity and more results for the same investment, while developers avoid tedious problem-solving tasks and focus on implementing new features, which is much more engaging.
Lessons from Skype’s Closure and Moving DevEx Forward at Microsoft Teams
And, of course, I must ask, what did Skype’s closure mean to you as an engineer who actively worked on improving the product?
Skype was a significant milestone in my career. I had ambitious plans for optimizing development processes over the next couple of years. However, the business had its own strategy, and the product was set to be closed.
My work as a DevEx engineer, however, did not end. I transitioned to a related team working on Microsoft Teams, where I continue to promote DX ideas while holding a product developer role.
In my view, DX works best if you personally encounter negative experiences, analyze the causes, and think about solutions. Now, I am gradually integrating into a new product, learning it, and simultaneously proposing optimization initiatives.
Photo by Vitaly Gariev; Unsplash
Rashan is a seasoned technology journalist and visionary leader serving as the Editor-in-Chief of DevX.com, a leading online publication focused on software development, programming languages, and emerging technologies. With his deep expertise in the tech industry and her passion for empowering developers, Rashan has transformed DevX.com into a vibrant hub of knowledge and innovation. Reach out to Rashan at [email protected]
