DevX is a Quality Process

For all the good that a Developer eXperience team can do, by creating documentation, improving APIs, building tools and libraries, and fostering community, this will only ever constitute part of the total developer experience. The foundation stones of a good developer experience are actually in the hands of the core product teams.

Delivering a quality product, which does what it should, and does it reliably, is the bedrock on which any developer's eXperience is based. Proper analysis, implementation and testing all play a role in this process of delivering quality, in a technical sense. Thankfully most engineering teams are already very focused on these aspects and DevX shouldn't need to be involved.

However, DevX teams are, naturally enough, significantly smaller than the development teams they augment, and they have to get up to speed quickly with the torrent of changes and enhancements coming from the main development team. To think that the DevX team could do this purely by reading the code alone is, demonstrably, ridiculous.

Thus, a major component of a DevX teams work is to ensure that what is delivered by the main software engineering teams meets the standard required for them. Typically this doesn't involve checking the quality of functionality delivered in the traditional sense of Quality Assurance, but rather ensuring that those teams are following documentation practises that ensure that all the information necessary to understand how to use the software is already in place before it leaves the main engineering teams.

Documentation doesn't just refer to API or library documentation strings/comments, but also to documenting processes around the product. Making sure that everything that needs to be done is still possible when the person who created or designed it is off sick, or the whole team has an offsite day. These are aspects that may well seem obvious in internal devx teams, but we should be aware that they also have knock-on effects for external customers.

Ideally, we should also push Dev teams to focus on automating internal processes as well as obvious, external ones.

In that sense, DevX is a quality process. Setting a standard for what is delivered, and educating software engineers as to why this is important is one of the most important things a DevX team has to do.

Sadly, this is often overlooked by organisations creating DevX teams - the naive view is that it is simply possible to "retrofit" a good developer experience at the end of the production line. If your finding that your DevX team simply can't keep up with the output of the product team, the answer may not be to add more DevX engineers, but rather to think carefully about what their role is.

Let's boil this down to some rules:

• Developer eXperience is an aspect of product quality.
• "Quality is a process".
• Assuring high-quality DevX means being the customer of the teams you augment, and requiring that follow the right process.

It may seem a bit rich for DevX teams to start making demands like this of other engineering teams. After all, shouldn't creating a new team for this purpose make the whole thing easier? I think the answer to that question hangs on whom exactly is having their burden lifted by the DevX team.

It's been my experience, in start-ups, that external-facing DevX teams occur when the founding CTO no longer has time to directly oversee all development operations to ensure things are being done to the right quality.

Internal facing DevX teams come to be when the company scales to the a point where there is no longer a small, tight-knit group of developers communicating openly about shared concerns, but rather multiple teams pulling in different directions.

In big enterprise companies, internal DevX is something that comes about from the push to develop internal platforms for development, which in itself is a reaction to the problems associated with the same lack of responsibility for the shared parts of disparate engineering needs.

In all these cases the driving force to do this is not the things a DevX team can produce, but the embodiment of the responsibility to safeguard a positive effect on small companies and small teams, as we scale-out. It is about oversight, and responsibility being embodied in a business function instead of in some small number of overworked individuals.