Engineer Experience examines how people, processes and tools affect productivity amongst software engineering teams. Based on a Tech Talk delivered by Technical Director Richard Brown, this blog explores the ‘why’ and ‘how’ of measuring Engineer Experience.
What Is Engineer Experience?
According to GitHub, engineer experience, sometimes called developer experience or DevEx, refers to the systems, technologies, processes and cultures that influence the effectiveness of software development.
Engineers are typically the most expensive resource on any software project. When engineers constantly face bottlenecks, blockers, inefficient tooling, slow laptops or build queues that stretch for hours, the entire team slows down and struggles to deliver value to end users. Whereas the more efficiently a developer is able to work, the better value for money an organisation can offer.
Bringing engineer experience front and centre means recognising that investing some time, effort or money can unblock engineers to deliver much faster. The return on investment is often relatively high compared to the input.
Why Measure Engineer Experience?
Often, surveys can reveal what metrics can't. Metrics like DORA measurements, build times and deployment frequency provide useful data. However, without asking engineers directly, organisations can miss potential blockers and inefficiencies. The best way to measure engineer experience is through surveys that ask engineers themselves about their day-to-day work.
Measuring engineer experience delivers four key benefits:
Identify inefficiencies
Surveying engineers helps identify inefficiencies by allowing organisations to drill down into process details to find what causes them. For example, metrics might show that deployments reach production only once per month, but survey answers can reveal why.
Evaluate tools and technologies
Engineers working directly with software, frameworks and tech stacks are best positioned to say whether their tools are fit for purpose or their tech stack is up to date. Engineering leaders might struggle to keep pace with every new development, especially in AI tools where capabilities proliferate rapidly, but engineering teams usually maintain deep knowledge in their specific areas. Asking them about the tools and technologies they use surfaces insights about how effective those choices are for solving daily problems.
Recognise pain points
Job satisfaction matters enormously in any role, and in software development the best engineers are in very high demand, making it crucial to avoid having people dissatisfied in their roles. Whether it stems from being unable to use particular technologies, waiting three hours every time they queue a build, or working in silos with no visibility of other teams, a few stacked frustrations can prompt engineers to look elsewhere. Identifying pain points means they can be addressed before they become retention issues.
Build engagement
People genuinely appreciate being asked their opinion and having it valued. Engineering leaders who mandate decisions – frameworks, IDEs, product licences – without input quickly leave people feeling disempowered and lacking buy-in. Asking for opinions and taking them on board creates genuine engagement and commitment to organisational goals.
Best Practices for Engineer Experience Surveys
Several practices help organisations run effective engineer experience surveys and extract maximum value from the results.
Ask about things within your control
Only ask questions about factors that can actually be changed. For example, if an organisation only uses JavaScript and there are constraints that mean this cannot be changed, asking about satisfaction with the programming language only draws attention to dissatisfaction without offering a path to improvement. Instead, focus on areas where action is possible.
Focus on what's important to your organisation
Template surveys and example questions exist online and make excellent starting points, but every organisation differs. Use templates as foundations, then add, remove and modify questions to ensure the survey speaks to specific organisational needs and priorities.
Be consistent
Running a single survey provides a pulse check on engineer sentiment, but the real value emerges from running questionnaires at a regular cadence. Instead of changing questions between surveys, maintain a high proportion of consistent questions as a baseline. This allows organisations to track trends and determine whether changes implemented between surveys have influenced engineer sentiment. For example, average scores moving from 3.5 to 4 out of 5 between surveys suggests that any change implemented in-between was positive and worth continuing.
Include role-specific questions
Most organisations employ different types of engineers – software engineers, test engineers, cloud engineers, data engineers, data scientists etc. Include universal questions aimed at everyone as well as subsets of questions targeting individual roles. For example, ask testers about splits between automation and manual testing, developers about unit testing and cloud engineers about cloud provider choices or infrastructure-as-code toolchains.
Consider anonymity carefully
Anonymous surveys encourage honest, robust feedback, but they can be harder to action. Without follow-up questions or context, it becomes difficult to fully understand the motivation behind comments. For example, in an organisation of 100 engineers, if 97 rate documentation as fantastic but three suggest room for improvement, then the big picture suggests that documentation is a low priority pain point. However, if those three engineers all make up one team, then the feedback becomes very different and targeted improvement for that specific team becomes necessary.
One solution can be to maintain anonymity whilst also collecting role, team or project information. This preserves anonymity (teams are typically larger than three people) whilst enabling identification of systematic trends within specific roles or teams.
Balance quantitative and qualitative feedback
Quantitative questions, scoring from one to five, enable easy trend measurement and quick identification of pain points (typically the lowest-scoring questions). Qualitative free-text responses provide the crucial context that makes feedback actionable. Someone scoring something one out of five is useful, but someone scoring one out of five and explaining why is far more valuable.
Follow through with change
Actioning feedback is the most critical practice in this list. At Audacia we break results down by project and meet with lead developers to identify next steps. These decisions feed into sprint retrospectives or targeted improvement initiatives.
We never make surveys mandatory, but by demonstrating that feedback leads to real change engagement stays high. Without this follow-through engagement rates drop as people gradually disengage from the process. If feedback can’t be actioned because of constraints such as finite time and budget, then clearly communicate those. Opening this conversation makes people aware of leadership constraints, whilst maintaining trust.
Key Survey Areas
At Audacia, we structure our survey questions around these key areas chosen to reflect what matters most to our engineers and the organisation. These areas can change year-on-year depending on organisational activity. Every business is different, and the areas you prioritise should reflect that.
Documentation and knowledge sharing
These practices address how quickly engineers can onboard to new projects or code areas. For consultancies, this becomes especially critical because project teams work in entirely different business domains and build very different software, making knowledge silos easy to form.
- Can engineers search documentation to answer questions about how code works or why architectural decisions were made?
- Or must they ask specific individuals, creating bottlenecks?
Technical standards
Technical standards should help organisations ship better code faster. Surveys provide a pulse check on whether standards are helping or hindering. Too many standards, poorly discoverable standards or frequently changing standards slow teams down rather than speed them up. On the other hand, clear, concise, easily discoverable standards speed teams up and improve code quality.
Agile processes and project delivery
Determine whether agile processes help teams work effectively, or whether they fail in practice.
- Are stand-ups efficient or do they stretch to two hours because discussion is too detailed?
- Do retrospectives happen?
- Do teams action retrospective items?
- Are teams continuously improving?
Additionally asking about project delivery can surface inefficiencies. For example, builds taking two hours because of massive queues, or deployments only being possible at specific times because they rely on one person.
Observability
This matters particularly when supporting software in production.
- When bugs appear or production goes down, how do teams find out?
- Do customers call to report problems, or do alerts arrive proactively, enabling teams to inform customers about issues and mitigation plans?
- When bugs occur, can teams diagnose them quickly?
Strong observability, seeing exceptions logged and tracking paths through systems, enables rapid bug diagnosis, faster patches and reduced impact on end users.
Quality
This topic covers broad territory.
- Do code reviews add value or slow teams down?
- Are automated tests written?
- Are those tests run regularly?
- Do they deliver valuable feedback?
- Do tests catch regression bugs?
Practices like code reviews and automated testing policies are important, but they can easily become bottlenecks. Asking engineers about the value they receive identifies where policies fail to add value and simply slow people down.
Tools, technologies, and practices
These often have the biggest impact on engineer job satisfaction. Engineers spend most days writing code, living in their IDEs, working with programming languages and frameworks. An engineer could face frustration if they work with outdated frameworks approaching end-of-support whilst colleagues on other teams use the latest frameworks. Identifying these pockets of dissatisfaction – particularly when responses are sliced by team or project – enables targeted improvements.
AI tools and adoption
Engineer sentiment around AI is increasingly worth measuring on its own terms. Attitudes vary widely from enthusiastic adopters to sceptics, and understanding where your teams sit helps inform decisions around tooling and training.
Useful questions to ask include:
- Do engineers feel positively about the role of AI in engineering generally?
- Do they think the organisation is adopting AI at the right pace?
- Are engineers satisfied with the AI tools available to them?
- Do they have sufficient quota within those tools to use them in their day-to-day work?
Conclusion
Engineer experience surveys provide a valuable mechanism for gathering feedback that metrics alone cannot capture. By customising surveys to organisational priorities and running them consistently, organisations can measure progress, identify systematic issues and make targeted improvements. This ongoing practice of measuring and improving engineer experience leads to better delivery outcomes, higher engineer satisfaction and stronger retention.
