The State of Developer Experience and Developer Productivity

This report on the state of developer experience and developer productivity is based on the JetBrains Developer Ecosystem Surveys from 2024 and 2025. We asked software developers, technical managers, and DevEx and developer productivity engineers about their companies’ practices in measuring developer productivity and experience. We also asked what they think is still missing, and received between 146 and 6,144 responses to each question.

In this report, we highlight the main takeaways that we at JetBrains consider valuable to the tech community and to enterprise customers in particular.

Whether you're responsible for developer productivity and DevEx at your company, advocating for better processes, or thinking about AI adoption, the insights in this report can help you reflect on your current practices and make more informed decisions.

Snapshots

1. What developers want from AI, and how companies are increasing productivity

The top five areas developers want to use AI in are:

62%

Writing boilerplate or repetitive code

58%

Understanding and fixing bugs

57%

Generating tests

57%

Improving or optimizing code quality (e.g. refactoring)

49%

Writing and editing regular code

85%

of developers use at least one AI tool for coding and other development-related activities.

9%

of developers haven't integrated any AI into their workflows

Companies are using these top three measures to increase developer productivity:

24%

Internal training

10%

Generative AI adoption

9%

Improving development methodologies

2. Satisfaction with tools

A good tech stack is as important for developer experience as non-technical factors like clear goals and compensation (89% and 87%, respectively).

33%

of developers revealed that their satisfaction with tools isn't even measured.

3. Most-used productivity metrics

35%

Deployment frequency (DORA)

35%

Lead time for changes (DORA)

35%

Performance (e.g. stability and quality) (SPACE)

34%

Developer satisfaction and wellbeing (SPACE)

4. Methods used to assess developer productivity and developer experience

Individual productivity is usually measured by:

35%

KPIs

33%

Interviews

31%

Self-assessment

Satisfaction with tools is usually measured by:

27%

Spontaneous, informal conversations

24%

Surveys

21%

Interviews

5. Team leads are expected to be responsible for DevEx and productivity measurements

56%

of respondents say team leads are responsible for productivity and experience measurements, rather than specialists like developer productivity engineers or HR pros.

6. More stats on productivity, developer sentiment, and their measurements

66%

of developers are not confident that the metrics used to measure their productivity are truly representative.

51%

of developers say their satisfaction with tools is measured in any way.

24%

of tech managers who are unhappy with the current state of DevEx in their company say that inefficient processes and policies hinder developer productivity.

41%

of small companies don't measure developer productivity and experience, compared to just 30% of large companies.

Developer experience (DevEx or DX) refers to the overall satisfaction and feeling of being productive that developers experience when interacting with software development tools, processes, environments, and platforms.

Developer experience has been gaining increased attention lately, as it’s closely connected with the effectiveness of software development. Companies are stepping up their efforts to assess DevEx and developer productivity and better understand the factors that influence them.

Measuring developer experience and productivity isn’t just a “nice-to-have” anymore – it’s an essential practice for tech companies wanting to stay competitive, attract top talent, and build thriving developer teams. However, how companies approach this process is just as crucial as the measuring itself.

The Top Developer Productivity and Experience Pain Points From the Perspective of Tech Managers

Tech managers who said they’re unhappy with the current state of DevEx in their company were asked to identify challenges or inefficiencies in their organization’s approach to productivity and DevEx.

What does your company lack or do ineffectively in its approach to developer productivity and developer experience?

question for tech managers (those who reported being unhappy about their company’s approach toward DevEx and productivity), N=146, year 2024

27%

Developer productivity and experience are not a priority for the company

24%

Inefficient and cumbersome processes and policies are hindering productivity

20%

Poor leadership, communication, and management practices

14%

Lack of proper metrics and measurement of developer productivity

14%

Negative impact of company culture and organization structure on productivity

14%

Lack of investment and budget for tools that enhance developer productivity

Key points

While improving developer productivity and DevEx is becoming a priority for many companies, challenges still exist. Organizations that don’t prioritize developer productivity and experience and fail to address inefficient processes and poor communication risk falling behind.

Make developer productivity and DevEx a priority at the leadership level

Without a strong commitment from the leadership, efforts to enhance developer experience and productivity will remain scattered and underfunded.

Fix broken processes and invest in tools

Inefficiencies, unsuitable tools, and over-complicated workflows all drain productivity. Streamlining processes and prioritizing investments in modern, developer-friendly tools can boost developer productivity and experience.

The New Role of AI in Developer Productivity

We can’t talk about the future of developer experience and productivity and the software development industry in general without mentioning AI.

2.1 The adoption rate of AI tools is a promising productivity booster

Our data collected in April–June 2025 shows that 85% of developers now use at least one AI tool for coding and development activities. This presence of AI is redefining what both technical leaders and developers expect.

Which of these AI tools
do you regularly use for coding and
other development-related activities?

question for everyone, multiple choice, N=23,350, year 2025

85%

At least one AI tool

62%

At least one AI coding assistant/agent or code editor

2%

Custom AI tool

9%

None

Note: The original question listed specific tools (omitted here), whose shares have been aggregated for this report's purposes.

The adoption of generative AI tools is already seen as an important move. Tech managers ranked it among the top three organizational measures for improving developer experience and productivity, alongside internal training and improvement of development processes.

What is your company's main organizational measure to enhance developer productivity and developer experience?

question for tech managers, N=2,336, year 2025

24%

Internal training and skill development organized by the company

10%

GenAI tool adoption

9%

Improving development processes and methodologies

8%

Support of grassroots initiatives and exchange of best practices

7%

Fixing internal collaboration and communication issues

2.2. Developers expect AI to improve – not control – their workflows

Developers have a clear sense of how they want AI to reshape their jobs. When asked how they expect their workflows to change over the next 1–3 years, developers pointed to a shift – not a full automation of their work, but a rebalancing of where their time goes.

Many expect AI to speed up learning (47%), take over repetitive or boilerplate tasks (44%), and generate initial drafts of code (42%). Developers also see AI as a way to spend more time on meaningful work like problem-solving and high-level design (39%).

How do you expect your coding and development workflows to change in the next 1–3 years due to AI tools for coding and development?

question for developers, multiple choice, N=1,625, year 2025

47%

AI will reduce the time I spend learning new frameworks, tools, or APIs

44%

I’ll rely more on AI for repetitive tasks but keep the core work manual

42%

I expect to use AI to generate initial drafts of code, but I will still review and refine it

39%

AI will help me focus more on problem-solving and high-level design, while handling low-level implementation

37%

I expect AI to significantly improve debugging and code optimization processes

34%

AI will help me transition into new roles or technologies more easily

Developers already know where they want to leverage AI.

In which of the following areas would you like to get assistance from AI tools for coding and development?

question for developers, multiple choice, N=1,682, year 2025

62%

Generating boilerplate or repetitive code

58%

Understanding bugs and finding fixes for them

57%

Generating tests

57%

Improving or optimizing code quality (e.g. refactoring)

49%

Writing and editing code

These are signals worth paying attention to if we want to enhance DevEx and productivity in the AI era.

Key points

AI adoption is evolving. It may not have transformed developer workflows overnight, but its influence is growing. Developers have a vision of how AI tools may help them in the future, and these ideas might be a useful starting point for those willing to enhance developer productivity by leveraging AI.

The Impact of the Tech Stack and Non-Technical Factors on Developer Productivity and Experience

Developers report that both technical and non-technical factors strongly influence their developer experience, with 89% citing technical factors and 87% citing non-technical factors as having a moderate or significant impact. These results suggest both types of factors are nearly equally important in shaping developer experience.

To what extent do you believe your developer experience is influenced by …?

question for developers, N=2,785, year 2024

Technical factors

such as performance of development tools, code editor responsiveness, etc.?

55%

Significantly influenced

34%

Influenced

10%

Somewhat influenced

1%

Not at all influenced

Non-technical factors

such as team processes, clear communication, clear goals, fair compensation, your overall well-being, work-life balance, etc.?

53%

Significantly influenced

34%

Influenced

13%

Somewhat influenced

1%

Not at all influenced

In 2025, we asked both developers and technical managers a similar question, this time about how much technical and non-technical factors influence developer productivity. Both groups rated non-technical factors as slightly more influential for developer productivity (managers: 89% vs. 85%; developers: 89% vs. 84%).

To what extent do you believe developer productivity is influenced by …?

question for tech managers, N=2,360, year 2025

Technical factors

such as performance of development tools, code editor responsiveness, etc.?

52%

Significantly influenced

33%

Moderately influenced

13%

Somewhat influenced

2%

Not at all influenced

Non-technical factors

such as team processes, clear communication, clear goals, fair compensation, your overall well-being, work-life balance, etc.?

64%

Significantly influenced

25%

Moderately influenced

9%

Somewhat influenced

2%

Not at all influenced

To what extent do you believe your productivity as a developer is influenced by …?

question for developers, N=6,144, year 2025

Technical factors

such as performance of development tools, code editor responsiveness, etc.?

51%

Significantly influenced

33%

Moderately influenced

14%

Somewhat influenced

2%

Not at all influenced

Non-technical factors

such as team processes, clear communication, clear goals, fair compensation, your overall well-being, work-life balance, etc.?

62%

Significantly influenced

27%

Moderately influenced

10%

Somewhat influenced

1%

Not at all influenced

Key points

Companies should focus on both technical and non-technical improvements to boost developer experience and productivity. Investing in high-performing tools is important, but so is improving team processes, communication, and overall well-being. This way, developers get the support they need – not just to be more productive, but also to enjoy their work.

The Top Metrics for Measuring Developer Productivity and Experience

We distinguish between the metrics and methods used to assess DevEx and productivity in companies as follows:

  • Metrics are the ways of defining the behavior of software developers in measurable terms and quantifying that behavior.
  • Methods are the approaches used to organize these assessments.

In other words, metrics are what is being measured, whereas methods are how things are being measured.

Metrics

4.1 Commonly used metrics from the DORA and SPACE frameworks

When it comes to measuring developer productivity and experience, two of the most recognized frameworks are DORA and SPACE. These frameworks provide a structured approach toward developer productivity and experience.

In 2024, we asked tech managers who are involved in efforts to improve DevEx and developer productivity within their companies which specific elements of these frameworks (i.e. metrics), if any, they use to evaluate developer productivity and experience.

Many organizations seem to be actually combining DORA’s operational metrics with SPACE’s more human-centric dimensions to create a more balanced approach.

The most widely adopted metrics from both frameworks are:

Deployment frequency (used by 35%)

A DORA metric that measures how often developers deploy code.

Lead time for changes (used by 35%)

Another DORA metric that tracks how long it takes for code changes to reach production.

Performance metrics (used by 35%)

Part of the SPACE framework, these metrics focus on process outcomes, such as stability and quality.

Satisfaction metrics (used by 34%)

Another core SPACE dimension, which measures how happy and fulfilled developers feel with their work, team, and their tools.

Which types of measurements does your company use to assess developer productivity or developer experience?

question for technical managers, N=1,063, year 2024

35%

Deployment frequency (DORA) – how often a developer deploys code

35%

Lead time for changes (DORA) – the amount of time it takes a code change to reach production

35%

Performance metrics (SPACE) – the outcomes of a system or process (e.g. stability, quality, etc.)

34%

Satisfaction metrics (SPACE) – how fulfilled developers feel with their work, team, and their tools; how healthy and happy they are

28%

Change failure rate (DORA) – the percentage of deployments causing a failure in production

26%

Time to restore service (DORA) – the average time it takes to recover from a failure in production

4.2 Operational metrics are the most commonly used to measure developer productivity

A while ago, DX asked the top 18 tech companies about the metrics they use to track developer productivity. We decided to investigate which of these metrics are most commonly adopted by a broader range of companies. Here are the answers from 2,000+ respondents:

Traditional activity-based metrics are used less frequently

Among the least commonly used metrics is the number of diff/pull requests per developer (10%). This might indicate a shift in the industry from simplistic volume-based measures to more holistic, outcome- and human-oriented assessments of developer productivity. We see this as a very positive sign.

Developer satisfaction (32%), developer engagement (32%), and developer sentiment (20%) top the list

These three metrics focus on the human-centric aspects of developer experience and productivity. Their high usage reflects a growing recognition that morale, motivation, and overall well-being are crucial for developer experience and productivity.

Operational/process-oriented metrics are widely adopted

According to our data, metrics like deployment frequency (21%), lead time for changes (19%), and ease of delivery (18%) are among the most commonly used. These metrics are partially taken from the DORA framework, highlighting the importance organizations place on smooth workflows and minimizing bottlenecks.

Which of the following specific measurements does your company use to assess developer productivity and/or developer experience?

question for tech managers, multiple choice, N=2,315, year 2025

32%

Developer engagement

32%

Developer satisfaction

21%

Deployment frequency

20%

Developer sentiment

19%

Lead time for changes

18%

Perceived/Self-reported productivity

18%

Ease of delivery

Methods

4.3 KPIs, interviews, and self-assessments are the most widely used productivity measuring methods

When it comes to measuring productivity, developers report a variety of methods being used in their companies.

At the top of the list in 2025 are:

35%

KPIs

33%

One-on-one interviews

31%

Self-assessment

Activity logs (such as tracking code commits and pull requests) follow closely, with 23% of developers saying this method is used in their companies.

Which of the following methods or metrics does your company or organization use to measure your productivity?

question for developers, N=6,036, year 2025

35%

Key performance indicators (KPIs)

33%

One-on-one interviews

31%

Self-assessment (in any form other than surveys and feedback forms)

23%

Activity logs (e.g. code commits, pull requests)

21%

Observational assessments

When it comes to measuring satisfaction with development tools, the picture is far from perfect. Almost half (49%) of developers told us there are issues here: 33% say their satisfaction isn’t measured at all, and another 16% don’t know whether it’s being measured.

The top three methods for measuring DevEx – when it is measured at all – are:

27%

Spontaneous, informal conversations

24%

Surveys and
feedback forms

21%

One-on-one
interviews

How is your satisfaction with development tools measured in your company?

question for developers, N=6,009, year 2025

27%

Informally, during spontaneous conversations

24%

Through surveys and feedback forms

21%

In one-on-one interviews

13%

Via observational assessments

33%

My satisfaction with development tools is not measured

16%

I don’t know

1%

Other

Key points

It is important to balance objective data with subjective data; relying solely on metrics like activity logs or KPIs can oversimplify the picture of productivity. Companies need to combine them with subjective methods like interviews and surveys to gain a much more meaningful and reliable understanding of developer productivity.

How Developers Feel About Standard Productivity Metrics and Their Reliability

5.1 Most developers are comfortable with having their productivity measured

Most developers are generally OK with these assessments. When we asked developers in 2024 how they felt about having their productivity measured, 42% said they were comfortable with it, and 40% had a neutral attitude. However, 18% admitted some discomfort with the idea.

Developers feel even more comfortable about the fact that their satisfaction with development tools is assessed. Over half of respondents (57%) said they felt comfortable about their satisfaction being measured, and 39% felt neutral about it.

Overall, developers are more at ease when evaluations focus on the tools they work with rather than their personal productivity. And that makes sense – assessing tools feels far less personal than evaluating individual performance, which naturally reduces anxiety around the process and its outcomes.

How do you feel about the fact that your productivity is being measured?

question for developers, N=3,840, year 2024

17%

Very comfortable

25%

Somewhat comfortable

40%

Neutral

14%

Somewhat uncomfortable

4%

Very uncomfortable

How do you feel about the fact that your satisfaction with dev tools is being measured?

question for developers, N=2,319, year 2024

29%

Very comfortable

28%

Somewhat comfortable

39%

Neutral

3%

Somewhat uncomfortable

1%

Very uncomfortable

The data makes one thing clear: Developers are mostly comfortable with having their productivity and experience assessed.

This kind of evaluation seems to be becoming a standard practice in the tech industry. Fear of making developers uncomfortable or eliciting negative emotions should not stop companies from measuring developer productivity and experience.

5.2 Developers don't feel metrics accurately reflect their productivity

Almost two thirds of developers either do not believe that the metrics used to measure their productivity reflect their productivity and contribution accurately (36%) or are unsure about it (30%).

Do you feel that the methods or metrics used to measure your productivity accurately reflect your productivity and contribution?

question for developers, N=4,240, year 2025

34%

Yes

36%

No

30%

I’m not sure

This lack of confidence extends to how this data is used in decision-making processes. In 2024, we asked developers how aware they were of the decisions being made based on their productivity assessments.

Only 22% of developers said they’re fully aware of how their productivity data is being used and are regularly and clearly informed about it.

A further 32% are mostly aware, meaning they have a general idea but are missing the full picture. For the rest, awareness drops off, with 46% having a limited understanding or being completely unaware of how their data is being used.

This split in awareness underscores a significant challenge: If developers don’t fully understand how their productivity measurements are being used, these assessments can easily feel arbitrary and unfair, which can lead to absenteeism and low response rates in the future.

How aware are you of the decisions made based on the assessment of your productivity?

question for developers, N=3,763, year 2024

22%

Fully aware – I am regularly informed about, and I fully understand how my productivity data is used in making decisions

32%

Mostly aware – I have a general understanding of how my productivity data is used in making decisions

23%

Somewhat aware – I have a limited understanding of how my productivity data is used in making decisions

13%

Slightly aware – I am rarely informed and have very little understanding of how my productivity data is used in making decisions

10%

Completely unaware – I am not at all aware of how my productivity data is used in making decisions

5.3 Developers want transparency and constructive feedback

When we asked developers what could make them feel more comfortable with how their productivity is measured, this is what they told us they want:

21%

Greater transparency and clarity of the process

Developers want to know how their work is being evaluated, and why. Without this clarity, these efforts risk feeling arbitrary or unfair.

19%

Constructive feedback
based on the results

Developers want actionable insights based on the results so they can grow, improve, and better align with their goals.

15%

Change of methods

12%

Change of metrics

Those who asked for changes in methods and metrics named KPIs, one-on-one interviews, and work journals or diaries as the methods currently in use in their companies.

Other concerns included the fairness of the process, how results are used in decision-making, and who is responsible for measurement. Developers want this process to be thoughtful, purposeful, and empowering.

What would need to change to make you more comfortable with the productivity measurement process?

question for developers, N=2,361, year 2024

21%

The transparency and clarity of the process

19%

I would like to receive constructive feedback based on the results to improve my development

15%

The method used (e.g. activity logs, issue tracking statistics, interviews, surveys, etc.)

12%

The specific metrics that are measured

10%

The fairness of the process

9%

How the results are used in decision-making

6%

Who performs the measurement

4%

The frequency of measurement

2%

The ability to suggest modifications to the process

1%

Other

Key points

Developers are mostly comfortable with having their productivity and experience measured.

However, a significant number remain skeptical about the process. More than half (58%) are unsure whether the metrics and methods their organization uses to measure developer productivity accurately reflect their contribution, while 46% have limited or no understanding of how their productivity data is used for further decision-making.

Companies need to earn developers’ trust and provide feedback.

Transparency and clear communication are non-negotiable. Developers want to know what’s being measured, why it matters, and how the results impact decision-making. More transparent communication about this is crucial to building trust and bridging the gap between organizational priorities and developer perceptions.

How Developer Satisfaction With Tools Is – or Isn’t – Measured

Building on our discussions of the metrics and the methods used to measure developer experience, we return to the question of whether organizations actually measure their developers’ satisfaction with their tools. While this metric is a vital component of DevEx, almost half of all developers report it’s missing or unknown in their companies. Specifically, 33% say tool satisfaction isn’t measured at all, and another 16% aren’t sure. Without this visibility, teams have little chance to spot pain points or take systematic action.

How is your satisfaction with development tools measured in your company?

question for developers, N=6,009, year 2025

27%

Informally, during spontaneous conversations

24%

Through surveys and feedback forms

21%

In one-on-one interviews

13%

Via observational assessments

33%

My satisfaction with development tools is not measured

16%

I don’t know

1%

Other

As mentioned earlier, quantifying developer satisfaction is generally well-received and rarely seems to spark discomfort.

How do you feel about the fact that your satisfaction with development tools is being measured?

question for developers, N=2,319, year 2024

29%

Very comfortable

28%

Somewhat comfortable

39%

Neutral

3%

Somewhat uncomfortable

1%

Very uncomfortable

Key points

This data signals that if you're not tracking developer satisfaction with tools, you’re missing opportunities. In the tech industry, top talent values not just compensation and perks but also seamless workflows and empowering tools. Developers thrive in environments where their concerns are heard and their tools work for them, not against them.

How Often Are Companies Measuring Developer Experience?

7.1. Larger companies are more likely to measure DevEx and productivity

Company size seems to play a role in the adoption of measurement practices, with larger organizations more likely to measure DevEx and developer productivity than medium and small-sized companies.

In larger organizations with over 1,000 employees, only 30% of the surveyed tech managers stated that their companies do not measure DevEx or developer productivity. For medium-sized companies (50 to 1,000 employees), this number increases to 34%, and again to 41% in smaller companies with fewer than 50 employees.

Does your company measure developer experience and developer productivity (either for individuals or teams)?

question for tech managers, year 2025

30%

31%

38%

Yes, we measure both developer productivity and developer experience

12%

20%

15%

Yes, we measure developer productivity

7%

5%

4%

Yes, we measure developer experience

41%

34%

30%

No

9%

10%

13%

I’m not sure

1%

1%

0%

Other

Small companies just me OR 2–10 OR 11–50 employees N=678

Medium-sized companies 51–500 OR 501–1,000 employees N=731

Large companies or enterprises 1001–5,000 OR 5,000+ employees N=656

7.2. There is no consistent standard for how frequently DevEx should be measured

In 2024, the frequency of productivity assessments conducted among developers shows a wide spread from company to company. Quarterly (25%), monthly (18%), and weekly (17%) productivity assessments are the top practices.

It’s a bit of a different story for satisfaction with tools, which is the core component of DevEx, where things are shifting. In 2024, more than half of developers (53%) said their satisfaction with development tools was measured at irregular intervals. But in 2025, that number dropped significantly to 29%, with more teams adopting structured measurement practices – monthly, quarterly, and annually. Quarterly (28%), monthly (18%), and weekly (9%) assessments became more common.

This might be a sign that companies are starting to treat DevEx less as an afterthought and more as something that deserves regular, consistent attention.

How frequently is your productivity
measured?

question for developers, N=3,869, year 2024

8%

Daily

17%

Weekly

18%

Monthly

25%

Quarterly

15%

Annually

15%

At irregular intervals

2%

Other

How frequently is your satisfaction
with development tools measured?

question for developers

5%

9%

Weekly

9%

18%

Monthly

10%

28%

Quarterly

8%

15%

Annually

53%

29%

At irregular intervals

15%

1%

Other

Key points

The good news is that companies are getting more serious about tracking developer experience, not just productivity. The drop in irregular DevEx assessments – from 53% in 2024 to 29% in 2025 – shows a positive shift toward more structured and thoughtful measurement.

Consistency and balance are crucial. While frequent measurement can create friction, measuring too infrequently may lead to overlooking critical issues. Develop a rhythm that works for your teams and their objectives.

Who Is Responsible for Measuring Developer Productivity and Experience?

Who is actually responsible for tracking DevEx and developer productivity? Our data paints a clear picture: In most companies, regardless of size, team leads take (or are expected to take) ownership of these efforts (see other job roles in the chart).

According to our 2025 data, 56% of the surveyed individual contributors (ICs) and a half of technical managers of various positions (including productivity engineers, DevEx experts, team leads, etc.) agree that team leads are the primary drivers of DevEx and developer productivity measurement. Interestingly, this is true for companies of all sizes. The choice looks logical – team leads work closely with developers and know their teams’ workflows, challenges, and pain points.

Who is primarily responsible for measuring your productivity and/or DevEx?

question for developers, multiple answers possible, N=3,462, year 2025

56%

My team lead

30%

Myself

14%

Platform Engineering team

Who is responsible for developer productivity engineering and DevEx in your company?

question for tech managers, multiple answers possible, N=2,338, year 2025

50%

Team leads

41%

Developers themselves

16%

Dedicated specialists or dedicated teams

Some crucial questions remain: Are team leads actually ready to take on this responsibility? How well-equipped are they for this task? Do they have real authority to influence company-wide decisions regarding tools, developer productivity, and DevEx? Or has this responsibility been pushed onto them without sufficient support?

Among developers and technical managers in large companies, 22% and 23%, respectively, identified platform engineering teams as responsible for DevEx efforts. 25% and 22%, respectively, pointed to dedicated specialist roles.

Who is primarily responsible for measuring your productivity and/or DevEx?

question for developers, multiple answers possible, year 2025

57%

60%

52%

Team leads

38%

27%

26%

Myself

7%

13%

25%

Dedicated specialists

6%

13%

22%

Platform Engineering team

14%

13%

11%

HR

10%

10%

6%

No one

2%

3%

5%

I don’t know

Who is responsible for developer productivity engineering and DevEx in your company?

question for tech managers, multiple answers possible, year 2025

49%

57%

44%

Team leads

45%

37%

39%

Developers themselve

12%

17%

22%

Dedicated specialists

6%

16%

23%

Platform Engineering team

8%

9%

8%

HR

15%

12%

9%

No one

General without breakdown by company size N=2,338

Small companies just me or 2–10 or 11–50 employees N=669

Medium-sized companies 51–500 or 501–1,000 employees N=726

Large companies or enterprises 1,001-5,000 or 5,000+ employees N=651

Among developers, 30% feel that measuring their own productivity and experience falls solely on their shoulders. This figure rises to 38% in small companies, suggesting that smaller organizations are especially prone to leaving developers to fend for themselves.

Key points

Organizations that invest in dedicated specialists and platform engineering teams are better equipped to create consistent, scalable practices that go beyond siloed efforts. These roles can complement and enrich the efforts of team leads, tying them into larger strategic goals.

Final thoughts

Myriad factors influence developer productivity and experience, but to get both right, leaders need to measure, get feedback, and invest in the technologies and policies that make the biggest impact. That means looking for AI solutions and developer tools that can automate routine tasks, being transparent about goals and how productivity is measured, and keeping open lines of communication between developers and leadership.

Methodology

This report is based on responses from the Developer Ecosystem Survey 2024 and Developer Ecosystem Survey 2025, conducted by JetBrains.

For each question, we indicate:

  • Who was asked the question
  • The number of responses
  • The year it was asked

If the year is listed as 2024, this means the question was dropped from the 2025 edition, and 2024 provides the most recent available data for that topic.

“Developers” refers to all individual contributors in roles such as Developer / Programmer / Software Engineer, Architect, DevOps Engineer / Infrastructure Developer, DBA, Systems Analyst, and related positions.

“Technical managers”, “Tech managers”, or “Tech leaders” refer to respondents in managerial roles (such as Team Lead, CIO / CTO / CEO, Developer Productivity Engineer, Developer Experience Engineer, Product Manager, or Product Marketing Manager) who also indicated they are aware of their company’s policies and practices related to developer productivity, experience, and associated processes.

You can download the 2024 raw data here. The raw data for 2025 will be published soon on jetbrains.com.

Analysis and writing
Olga Lvova
Yanina Ledovaya
Editing
Ciara Byrne
Colette Des Georges
Copyediting
Christian Yates
Mikhail Kropotov
Design
Anastasiya Bystrushkina
Daniil Komov
Project Manager
Nadia Lokot