3 Steps to Improve Developer Experience

Before you bet the farm on a platform engineering function, take these three actions

TL;DR

Developers are the engine that runs digital business and the canary in the coal mine that signals what the future health of that business will be. Developers are rapidly becoming overwhelmed with the pace of technology innovation and expectations to do everything from solving the core business problems to securing the applications (e.g. “shift left”) to operating the applications (i.e. “DevOps”, “build it, run it”). This leads to talent churning out and burning out. Reducing churn, and improving developer happiness are quickly becoming top priorities for companies to retain precious talent and achieve their desired business outcomes.

Who is this for?

Anyone concerned with increasing developer satisfaction, acquiring and retaining developer talent. Example roles include: Platform Product Managers, Platform Engineering teams, SRE Leads, Software Engineering Managers and Leaders, Enterprise Architects, and CTOs.

Take these 3 Steps

1. Create a feedback loop to understand developer interests, challenges, blockers, pain, and friction points. 

2. Form developer communit(ies) that open up opportunities for developers to engage, share, and learn from others in an informal setting.

3. Define your developer personas. Avoid treating developers as a monolith and gather data to understand the cohorts of developers in the organization and how to tailor DX to meet their needs.

Problem Statement

This analysis aims to answers the question: 

What steps should I take to start an initiative to improve developer experience?

Technology innovations in cloud, containers, and AI are accelerating and causing organizations to iterate rapidly and do dev spikes to assess how these technologies impact their business. Organizations rely on developers to solve the problem of testing and integrating these technologies into their core digital business that increasingly runs on cloud infrastructure and services. Investing in developer experience (DX) enables companies to react quickly and assess what to do with these technologies through dev spikes and experiments while integrating them into existing and new business models. The pressure on developers to play double duty of maintaining applications on existing technology while delivering new applications on emerging technology can lead to burn-out. The following meme (I found this and cannot take credit) reminded me of this increasingly common problem.

For example, cloud providers increase complexity for developers because they are product-oriented, not solution-oriented. Services are silo’d and consumed a la carte (e.g. storage, database, compute, networking), while developers require a combination of these services to ship code for the business. The onus is on the developer to figure out how to piece these services together just to provide the infrastructure in addition to actually solving the business problem. Adding to this complexity are the myriad of SaaS tools developers use for other services like observability, security, and each individual developer will create their specific, albeit snowflake, formula to solve these infrastructure-centric problems. 

This quagmire is forcing organizations to take a closer look at DX and investing in platform engineering teams to ease the burden and cognitive overload put on developers. Developer productivity is directly related to developer satisfaction and burnout¹. But where do you start? There is hype around platform engineering functions, however there are a few steps organizations can take prior to creating this function that will help stop the bleeding and are also strategic in nature.

Organizations prioritize DX once they hit an inflection point. Common symptoms include failure to scale, slow time to value, long onboarding cycles, inability to attract talent, unhappy developers, and burn-out.

Improving developer experience (DX) is not just about implementing tools (e.g. IDP phenomenon) and creating a new function (e.g. “platform engineering”) in order to solve for the technical bits. The primary issues to solve for first are the people and process bits. This the actions in the next section focus on how to start making improvements to DX. Future posts will cover the strategy and technology aspects of improving DX.

Action Plan

Conventional wisdom posits you need a strategy before you move to tactics, however a successful strategy requires data and capturing that data requires implementing specific tactics that we dive into in the following sections: Feedback loops, communities, and developer personas. These initial steps are what you will use to capture data as inputs to formulate a strategy that we will discuss in a future post.

P.S. → Conventional wisdom also states you need to “form a team” first to do this. Sure, form a team, but that doesn’t mean you need to “hire a team”. The likelihood that there are people in the organization already passionate about solving these issues is high. Find them, incentivize them, and empower them to go solve the challenge of improving DX. These same people will be your early adopters and champions that will ultimately drive growth and adoption beyond one or two teams.

Implement a Developer Feedback Loop 

Organizations cannot know what to improve in DX if they do not know what issues their developers face and why. Organizations experience symptoms that are directly and indirectly related to a poor developer experience and unhappy developers, but struggle to make the connection. Direct symptoms include failure to retain talent, slow time to onboard, and burn-out. 

Additionally, one of the biggest challenges engineering leaders and c-level execs face is visibility into the impact developers are having on the business and what is important to them². They may have a handle on the basic activities, but aren’t aware of how this delivers value for the business. 

Why developer feedback loops important:

• Captures early warning sign that things are wrong

• Feedback loops give platform engineering, product teams, and leadership visibility into the challenges developers face

• Gives developers’ a soapbox to vent and express their concerns

• Creates developer outreach opportunities to engage and understand how to improve DX

How to implement your developer feedback loop:

• Use existing, in-house tools to create your feedback mechanism like slack, surveys, or a no-code tool

• Brand your feedback loop (e.g. “Voice of the Developer”, credit goes to a colleague for this phrase) 

• Communicate the feedback loop’s availability, how to use, why, how it will be used, and expected benefits and impact far and wide

• Dedicate a role to intake, collecting feedback, and summarizing it for leadership to take action

Start a branded program (e.g. “Voice of the Developer”) that targets developers to express common issues they run into. Instead of these issues living in silos, it is expressed publicly for all developers to see and gives others the ability to upvote/downvote the issues. These issues can funnel into the platform engineering or platform PM teams, triaged, stack ranked, and executed on as part of a roadmap.

Start Developer Communit(ies)

The best way to determine what developer’s want is by understanding their daily struggles, what works, and what doesn’t. A community gives developers the opportunity to express themselves outside of formal feedback (albeit corporate/managerial channels). A community solves the problem of developer’s getting questions answered, sharing best practices as well as giving platform engineering teams the data required to build a platform that works for developers. 

A community provides developers with education and outreach, providing resources, tutorials, and documentation to help developers get started with their services. This focus on supporting developers and fostering a strong developer community has been crucial in driving adoption and building trust among developers.

The common denominator for developers is code. Everything comes back to code. The tooling and scaffolding surrounding that code varies, but the goals remain the same: code it, build it, test it, ship it, operate it. Developers are happiest when they have autonomy over the tools they use within their “inner-loop” for coding, debugging, and testing while agnostic to the tools used in the “outer-loop” for team development. The trend is tool selection for developers as part of the “operational loop” for incident response, troubleshooting, and debugging.

Developers struggle to find the right resources, training, and terminology used to address their technical issues. Organizations need to minimize the learning curve for tools and APIs, as developers are primarily focused on delivering results rather than spending excessive time on training. This can be solved with a diverse set of resources like interactive materials and seeking help from local communities when working with unfamiliar technologies. 

Define Developer Personas

Knowing your user, the developer, inside and out is critical to ultimately building a platform and tooling that solves their problems and leads to successful outcomes for the business. When you consider that developers in your organization are your users, focused on accomplishing X outcome, encounter specific pain (and friction) Y that they solve through Z, you can start to understand how they work and what matters to them. This breakdown creates greater segmentation amongst the population of developers that helps prioritize and target features, programs, messaging, and training to specific developer cohorts.

There are plenty of techniques and methods for doing persona analysis (lmgtfy :)), the important part is picking one that works for the team and running with it. Empathy maps are another good technique for this (what do they say, do, feel, see, hear, gols, pains, etc.). These planning and data collection exercises aim to identify developer cohorts, their pain points, and identify common patterns with high impact. These patterns influence your strategy and roadmap to determine what to prioritize and what tactics to employ. Some key components of this exercise should include: 

• Jobs to Be done. Developer Activities and why they matter

• UX studies. Provide valuable insights into improving command line interfaces, API design, and developer experience.

• Developer feelings and sentiment going through these activities. Empathy maps work well here.

• Technology stacks. What tech stacks are in use? What is the momentum and mass of these stacks?

• Geographies and work styles. Where do these developers reside? What are their work habits? Office, remote, hybrid.

• Key blockers and pain points. What are the key blockers inhibiting developers to be successful, and having a positive impact on the organization, and business? 

Conclusion

Improving developer experience and making developers happy requires starting from a baseline of what you know and forming a hypothesis, all of which requires data. First, help developers make their voices heard through feedback loops. Follow this with forming strong, autonomous communities that empower developers to learn, discover ways to remove toil, share best practices and lessons learned, and get up to speed on technology and systems quickly. Finally, use persona analysis to learn who your developers are, what their goals are, what their pain is, what they need to be productive, and increase job satisfaction.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the four actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

3. Share your feedback on this article.

4. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

1. https://devops.com/how-developer-productivity-engineering-dpe-enhances-software-delivery/

2. https://devops.com/the-metrics-disconnect-between-developers-and-it-leaders/