A good developer experience not only benefits the developer but is essential to increase developer effectiveness and thus, your organisational performance. Developer experience (DX) encompasses all aspects of a developer’s interaction with an organisation, its tools and systems. If you’re wondering what concrete steps to take to improve the DX in your organisation, we’ve got you covered. We gathered five approaches that we tried out and might inspire you to take the first steps.
1. Adopt product thinking for technical products and platforms
If you want to detect opportunities for new products or improve your current product offering, what would you do? Most probably you would start by researching what your customer’s needs and problems are and use these findings to come up with a product offering.
Based on your insights, you then target to build a product that brings together the customer and your business: solving the identified problem and generating revenue (or serving another business goal).
You can use the same techniques building products for developers. Developers are your customers. In fact, highly evolved organizations are adopting product thinking for technical products and platforms to accelerate development, reduce operational complexity and improve time to market.
On our projects, we were able to increase developer effectiveness by adding product managers and UX designers that bring product and design capabilities to a platform team.
2. Understand your developers’ journeys to identify what limits them in doing their job
Start by getting into the field and learn first-hand what truly affects your developers’ – likely your colleagues’ – work.
Find out step-by-step what jobs they need to do, from setting up their developer machine to actually delivering code to production (and beyond). Often these are tedious jobs for them. Like any user, developers strive for compelling onboarding, self-service and automation.
You will build empathy with them and will discover different developer personas with various needs and challenges. We recommend using techniques such as customer journeys and service blueprints to synthesize your learnings into insights and opportunities.
Customer journey maps focus on the user's path, goals, emotions, pains and touchpoints. We found the following layers helpful to add:
What is the level of cognitive load when completing an action? How many context switches does it take?
What interfaces and tools are used? Think of APIs and CLIs, not only graphical interfaces.
What does the feedback loop of the action look like? How long does it take?
- With whom does the developer interact? What is the interaction mode?
3. Shorten feedback loops for developers to improve frequent workflows
Working in small batches allowing short feedback loops is the core of agile and lean product development. Fast customer feedback allows us to learn if we are doing the right thing. The same way developers require feedback from various systems in order to learn if they are doing the thing right.
In his research on developer effectiveness, Tim Cochran recommends identifying developers’ feedback loops and optimizing them by making them fast and simple. He found that “feedback loops for developers in highly-effective environments are significantly shorter than those in environments with a low effectiveness.“
| Feedback Loop | Low Effectiveness | High Effectiveness |
| Validate a local code change works | 2 mins | 5-15 seconds (depending on tech choice) |
| Find root cause for defect | 4-7 days | 1 day |
| Validate component integrates with other components | 3 days - 2 weeks | 2 hours |
| Validate a change meets non-functional requirements | 3 months | 1 day - 1 week (depending on scope of change) |
| Become productive on new team | 2 months | 4 weeks |
| Get answers to an internal technical query | 1-2 weeks | 30 mins |
| Launch a new service in production | 2-4 months | 3 days |
| Validate a change was useful to the customer | 6 months or never | 1 - 4 weeks (depending on scope of change) |
Figure 2. Examples of developer feedback loops. Source: Tim Cochran, Maximizing Developer Effectiveness
This is a long list and measuring all of this might be overwhelming at first – and not all of it will be equally relevant to you. Start by looking at the feedback loops in your developer journey. What is performed several times a day and causes most pain and/or inefficiency? Start there to make improvements and continuously measure progress.
4. Enable collaboration to eliminate inefficient silos and foster mutual understanding
A decade of State of DevOps reports has shown that the ability of different disciplines to achieve win-win outcomes is amongst the top predictors of IT performance. While this initially mainly referred to development and operations, the 2020 report is expanding this concept by defining DevOps as “enabling people to collaborate with each other towards a common business goal.”
Achieving this might be easier than you think. Start by hosting joint lunch breaks where you provide food or other get-togethers so people can meet in an informal way. Or start creating opportunities and space for actively sharing information by hosting lightning talks, internal conferences or hackathons where employees from different teams and departments can come together and learn from each other. Opening daily standups for colleagues from other teams is another option to foster mutual understanding and create empathy for each other, especially for teams that have strong dependencies.
Need more inspiration? In their book “Team Topologies” Matthew Skelton and Manuel Pais suggest that team interactions can be nourished further by fostering co-location and introducing shared tools.
5. Foster a culture where team members feel safe to experiment and encouraged to innovate
While enabling collaboration can be achieved in a relatively short time frame, the following needs a bit more effort and patience: creating a healthy and safe environment for your teams in which they can thrive, innovate and create business value.
If you have doubts about your organization's environment aka organizational culture, check out the characteristics analyzed by sociologist Dr. Ron Westrum on that topic. How are you treating people that bring bad news? Does failure lead to scapegoating or investigation and learning? Is novelty in your organization considered as a threat or rather an exciting opportunity?
| Pathological (Power oriented) | Bureaucratic (Rule oriented) | Generative (Performance oriented) |
| Low cooperation | Modest cooperation | High cooperation |
| Messengers "shot" | Messengers neglected | Messengers trained |
| Responsibilities shirked | Narrow responsibilities | Risks are shared |
| Bridging discouraged | Bridging tolerated | Bridging encouraged |
| Failure leads to scapegoating | Failure leads to justice | Failure leads to inquiry |
| Novelty crushed | Novelty leads to problems | Novelty implemented |
Figure 3. Westrum's typology of organizational culture. Source: Ron Westrum, "A typology of organisation culture"
Google, which has done extensive research with its workforce on what makes teams successful, found that they share one common characteristic: psychological safety or in other words “the belief that one will not be punished when making a mistake”.
So why should you care and what does that have to do with developer effectiveness? Google’s researchers found that individuals on teams with higher psychological safety are less “likely to leave, are more likely to harness the power of diverse ideas from their teammates, bring in more revenue and are rated effective by executives twice as often.”
Netflix, who are considered a role model for DevOps, attribute a major part of their success as a technology company to a healthy culture and thinking. What are they doing differently? They hire managers to help engineers do their jobs. The job of a manager is to ensure that the people they work with have a constant flow of context of other departments' decisions (“the business”), thus enabling delivery teams to make well-informed decisions themselves instead of being dependent on their managers (“context over control”).
Considering your developers as customers can be a competitive advantage
If you are now wondering “Wow these are great points! But where do I begin?”, start by learning more about your customers. Interview and observe some of them, then map out their journey. From there you can identify opportunities to shorten feedback cycles and build a case to get more product capabilities in your technical product or platform team.
By doing so, you have the opportunity to uncover and realise mutual benefits for the developers and the business. A good developer experience can accelerate your software delivery and thus, reduce your time to market. It can enable innovation through flexibility and experimentation. And keeping in mind the competition for talent, a good developer experience might be your differentiator to attract and retain tech talent.
Want to learn why companies should invest in a good developer experience today? Read more in part 1.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
