Building Resilience with Developer Experience

A few weeks ago, I was struck by the wide variation in frustration levels across software development organizations. I started thinking about my experience as an engineer and what creates good and bad experiences. By extension, I tried to collect some thoughts about what creates productive and non-productive organizations. As I raised my finger to wag it thoughtfully at various practices in the software world, I realized that would be pretty dull to read ( and write ). But I couldn’t put my finger away completely. There is something peculiar and interesting about how “developer experience” or DevEx varies between organizations.

Looking through an organizational and systemic behavior lens, that peculiarity is because DevEx is often informally evolved. Over the years, various teams across an organization have developed different processes for change management, equipment procurement, maintaining code quality. These informal processes become entangled with regulation and compliance. As such the process become hard to detangle and change. In short, DevEx is often a cultural artifact more than an intentional process. With a more intentional approach, DevEx can be an organizational asset.

DevEx can be an enabler of innovation in an organization. ‘Developer Experience’ or DevEx is a practice which helps organizations build capital that enables them to be resilient and adaptive. DevEx builds capital in the form of productized knowledge. It centralizes process knowledge to enable resilience in the face of change. That approach enables quick adaptation to new challenges.

I’ve worked in a variety of places over the years. The ‘Developer Experience’ has ranged significantly. On the high end there are places in which the bulk of engineering is to push code to a repository. Most of the additional work of publishing services, deploying to various environments, running tests, submitting compliance documentation is taken care of by various systems. On the other end of the spectrum, there are places where you end up waiting for weeks to get a laptop, then waiting to get access to code repositories, or you are digging through multiple document systems to find some long gone engineer’s ratty notes about the services you are supposed to work with.

Backing up, what is DevEx? As with many Software terms, it’s inconveniently fuzzy. I have found two major definitions of DevEx. One definition is focused on software customers. For instance, a company selling API’s or Software as a Service may define DevEx in terms of their customer’s experience. The other definition, which I’m working with, is about the experience of internal developers. I think the lay definition of ‘experience’ implies some level of satisfaction. And indeed, there are some places that define DevEx in terms of developer satisfaction. For instance, the DevEx team at Synk has this team charter:

Make Snyk a pleasure to develop within

Github specifically mentions ‘developer happiness’ in their definition:

GitHub’s DevEx formula takes into account:

Productivity: how quickly or simply a change can be made to a codebase

Impact: how frictionless it is to move from idea to production

Satisfaction: how the environment, workflows, and tools affect *developer happiness*

But most commonly, I think, developer experience tends to focus on productivity and developer efficiency. As demonstrated by Microsoft’s definition

Developer experience refers to how easy or difficult it is for a developer to perform essential tasks needed to implement a change. A positive developer experience would mean these tasks are relatively easy for the team

In any case, I think the happiness, pleasurability, and productivity are intended to go hand in hand towards ultimately making more money. So let’s say that DevEx is work to improve the efficiency of other developers. How do teams do that? From my experience, those teams are building products and tools for other engineers. These products and tools are automating the tasks and workflows that engineers do today. DevOps also focuses on automation. DevOps also falls under the perview of getting code tested and deployed faster. “DevEx” contrasts with “DevOps” ever so slightly. The difference, from what I have seen, is that DevEx focuses on tools and they treat the users like a customer. In other words, they take a product approach. The focus on product is where DevEx becomes more than a series of automation.

As a product, DevEx tools become capital within an organization. Not the cash kind of capital, but capital in the sense of wealth. The automation becomes productized process knowledge and productized best practices, it is an asset that the organization can leverage. And as a centralized source of information and process, there is more ability to adapt the process to new challenges. Completely distributed, non-automated processes rely on habit to function. Five people in a distributed process cannot change the output of their work because they do not know what downstream systems they will impact. But once a process is carbonized into a product, there is a functioning record of that process and change becomes easier to facilitate.

DevEx provides a near text book implementation of managing complex systems. Which according to “Complex Systems and Evolutionary Perspectives on Organizations : The Application of Complexity Theory to Organizations” by Eve Mitleton-Kelly involves

Managing Organisations as Complex Evolving Systems: If organisations were managed as complex evolving systems, co-evolving within a social ecosystem, emergence would be facilitated rather than inhibited, and self organisation would be encouraged, as would exploration of the space of possibilities available to an organisation. Managers would understand that an organisation is an entity capable of creating new order, capable of re-creating itself. Management would focus on the creation of conditions that facilitate constant co-evolution within a changing environment, and would encourage the co-creation of new organisational form with those directly affected.

Centralizing process rules into manageable products achieves this ‘facilitation of constant co-evolution’. As organizational capital, DevEx creates a form of capital that an organization can leverage to scale up or down effectively — thus improving their resilience. And as a centralized repository of organizational processes, DevEx also provides adaptability. By intentionally building DevEx as a product, organizations will improve their adaptability and resilience and position themselves to be better innovators.