How We Measure Developer Experience at Trybe

Elton Minetto - Jan 17 '21 - - Dev Community

You have probably heard the term UX (User Experience), which is defined as

"the discipline responsible for designing enchanting user experiences to retain and win customers".

Analogous to this term there is a more recent one, but it has been gaining popularity in recent years. This is the DX (Developer Experience). As this is the topic of the post, I will explain it using excerpts from this great post:

  • Developer Experience means ensuring that our developers can work productively;
  • DX is not just tools. It is also about using them effectively;
  • It allows our developers to move quickly to meet customer needs, while also having the confidence that their workflow is reinforcing best practices and helping them detect and eliminate problems in the code early;
  • With effective solutions around Build, Deployment, and Workflow, DX is a force multiplier on the creativity of our development community.

These were the definitions that led us to create a process where we can measure and improve the DX of our teams at Trybe.

The first step was to create a form to collect the pains and expectations of the teams. For this, we use the following topics and questions:

Documentation

  • Evaluate the available documentation, from the README.md of the projects, Playbook, diagrams, etc. (grade 1 to 5)
  • What are your pains regarding our project's documentation? Cite documentation that should exist or documents that exist but are not sufficient or efficient. (open question)

Automation

  • Evaluate the automated processes that exist in the company. (grade 1 to 5)
  • Name processes that are done manually and that could be automated, or automation that exist but that can be improved. (open question)

Tools

  • Evaluate the available tools, IDEs, linters, etc. (grade 1 to 5)
  • Name tools that could be added to the teams' toolbox, as well as existing ones that could be improved or replaced. (open question)

Process

  • Evaluate the current development process, from task creation to the moment the code is sent to production. (grade 1 to 5)
  • Name improvements in the development process, changes in methodologies, functions, and steps. (open question)

Metrics

  • Evaluate the metrics currently collected, as well as how teams use them. From development process metrics to product performance. (grade 1 to 5)
  • Suggest improvements to the metric collection and how we analyze them, as well as new information that can be used (open question)

E-mail

  • Enter your email (optional)

With these data, it is possible to make simple math, using the median, to have a score for each item. But more important than the score, the open questions are where we collect the pains and needs of each person on the team.

And how do we use this information? At Trybe we use the management methodology created by Google, the well-known OKR. One of the characteristics of this methodology is to divide the year into quarters, where we define the goals of the company and each team. Bearing this in mind, we redo this survey at the end of each quarter. That way, we can measure the results of the initiatives we have carried out and also to define the goals for the next one.

We are now in the third quarter using this DX measurement process and the results have been very positive. It has helped us to identify where the main problems are that hinder the productivity of the teams and with that, we can tackle the biggest pains first.

My suggestion is that you analyze whether this process makes sense for your team, review whether the topics and questions we are using are important to you as well, and test with your developer people. It is an easy process to be performed, it only needs Google Forms and a few calculations in a spreadsheet, but it can generate a lot of knowledge about your teams' daily lives.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .