Why is 'Developer Experience'  critical to your people strategy?

Jody Cox
Jody Cox
Solutions Director

What is Developer Experience?

Developer Experience (DX) is about how developers experience a positive sense of flow and enablement from technical products and processes. It is akin to User Experience but from the perspective of developers and engineers on the job.  

However, whilst DX is primarily focused on workflow, it doesn't exclude non-tooling factors around their working experience. It encompasses how  all company interaction with engineers and demands align to their workflow.

The more integrated these factors are with the delivery tooling they use day-to-day the better...  

Why is Developer Experience important?

Today, deploying quality code quickly that is compliant, tested and secure, without support from tooling 'guardrails' can be an anxiety-inducing exercise. Especially with increasingly higher performance expectations.  

These guardrails can (and should) be provided by test, security and deployment automation tooling, that is integrated into their workflow processes. Without good DX, provided by automation, pressure can mount within a team.

Pushing for higher performance expectations without good DX is firmly at odds with a viable people strategy for retaining and attracting quality talent, in a highly competitive talent market.

Simply put, if business pressures becomes too great, and investment in the quality of experience for a developer isn't proportionate, there has never been more demand elsewhere for their skills.

Given this, there are very few incentives for talented individuals to put up with a sub-par experience. This is why many organisations are now dedicating entire DX teams to innovate and ensure developers have an ever more positive experience on the job.

As it's becoming a key focus for organisations... what does 'bad' or 'good' DX look like?

and, if you need to improve... where do you start?

What is a bad Developer Experience?  

When developers are required to constantly switch between tools or processes, the workflow isn’t providing them with a positive experience.

This is because context switching can create headaches arising from decision fatigue.  

A poor developer experience is detrimental on an individual level, by making you less efficient while coding.

The same is true for collaboration, as everyone has different tolerances and specialisms with unique working demands.

Those that are disproportionately effected by poor developer experience, or have unique demands to juggle are likely to be most impacted. This may be more senior engineers with other management duties, or indeed junior engineers who are working through a learning curve.

Ultimately, developers work best when they are ‘in the zone’, blocking out all distractions and finding a ‘flow’ in there working focus.  

By creating 'good DX' this is what we are trying to enable and protect

What is a good Developer Experience?

Good DX leverages tools in the right way to minimise complexity, context switching and decision fatigue.

Working with minimal interruptions and reduced mental load is possible. This can be achieved by optimising tooling to provide guidance and quality checks on their work before allowing deployment.

The Integrated nature of the tooling to typical delivery tooling (such as Azure DevOps or Octopus Deploy, etc) is key to aligning support to the process of development.

In bringing support to where the delivery workflow happens, automation tooling enables developers to build a rhythm of activity and reduce switching.

Reliable automation also promotes creativity. By de-risking and introducing objective quality parameters, this helps to enable a culture of psychological safety for engineers and increase focus on problem solving where it adds value, instead of where it prevents error.

In many cases, this can also help to reduce the knowledge threshold required for engineers to contribute to a given task as testing and security automation can help prevent bad deployments and provide instant feedback to engineers.

Essentially, if you want to provide a great developer experience, it starts with reducing context switching and decision fatigue. To do so, you need highly usable software and platforms to help them get ideas off the ground quickly.

In return, this benefits organisations by enabling higher quality development at a higher speed.

Ultimately good providing DX helps keep teams focused on the long-term goals whilst keeping them happy! It's a win, win, win!

So... how do you get there?

Really, this should be treated like any other improvement or transformation project that takes place in parallel to key deliverables and, as such, requires brilliant basics and an iterative approach.


Brilliant Basics!

  • Establish a small team
    Recently, a client worked with just a Scrum Master / BA and a UX Designer from our team to drive engagement, analysis and lead improvement work.

    We identified and prioritised improvement pathways through applying UX/DX principles like those they would use to develop a product. It all starts with user engagement and requirements capture.  
  • Start with user needs (in this case, developers)
    Develop surveys, initiate 1-to-1 feedback sessions and team workshops to understand current frustrations and pain points.
  • Understand all external interactions
    Developers often have other external factors that demand change in their priorities or expectations of work. Mapping these factors and how these demands interact with your developers is particularly useful.

    We recommend auditing demands, the mediums they source, the medium they are notified by, the frequency, urgency, time and processes of the demand.

    For example, this can often arise from security and compliance teams, who introduce process requirements but don't always understand how to meet engineers in their working context.
    Security or 'DevSecOps' tooling can be used to achieve organisational priorities without frustrating workflows. This tooling may sound expensive, but many open-source tools can be used to accomplish this.
    OWASP has put together a handy list of these.

    If there are frictions between security and development teams, it is also well worth analysing how these conflicts arise and how to approach this situation. CISO Mario Platt covered this in a
    talk about evolving security in context.  
  • Plot the 'developer journey' and map pain points
    By exploring the nuances of the challenges and niggles they face on the job, you will become more empathetic when interacting with developers.   This is essentially the same as mapping a customer journey!
  • Build an improvement task backlog
    Then, allocate a dedicated developer / DevOps engineer to the initiative iteratively if possible. Repeatedly, we see innovation being stifled by product development goals, leaving no time for the improvements that enhance overall delivery long term.  

    Ensure the initial focus is small but impactful and that there are regular feedback loops for introducing changes. To ensure the changes are positive, continuously engage the development community and take on board actionable suggestions.

    The goal is to make everyone feel involved and understand how these changes will improve their day-to-day work.
     
  • Never stand still
    innovation should be at the forefront of the developer experience, and a backlog should be maintained and actioned. There is an ever-changing landscape of integration and tooling opportunities, and many organisations are dedicating entire DX teams to innovate continuously.  

So... where to start?

Start by learning more about your developers. Interview and observe some of them, then map out their journey to understand what they need from you as a company.  

From there, take steps towards shortening feedback cycles by providing excellent service. Simultaneously, build trust among potential adopters, so when something does go wrong within developed software ecosystems, everyone has less trouble adapting.

Adapting to change only happens quickly when all parties involved feel invested in making things work this time around, rather than letting previous mistakes repeat themselves over again.  


Are you struggling with bad DX?  

Our team have seen the good, bad and ugly in Developer Experience, and we're always happy to have a chat and offer free advice where we can.

If you're having difficulty, reach out!  

Register Here!