DevEx in Trimble

[jhonkan]

I read this study DevEx in Action, and it reminded me of Build: Elements of an Effective
Software Organization which I had read last year and had used as inspiration for a program charter I wrote last year.. the timing was not right, and week later we had the re-organization announced, so not much came out of it. However, I thought to write something to open up the discussion on the topic. Here are some questions I'd be interested to know about:

• What is the state of Developer experience & productivity in your group?
  • Also, what is your perception Trimble overall state?
• How is Developer experience & productivity tracked?
• What are the things that have the biggest positive/negative impacts on Developer experience & productivity?
  • People, tools, processes, anything goes

TL;DR

• Build: Elements of an Effective
  Software Organization is much easier to read, promotes the same message.
• DevEx in Action findings support what you will find Build, but covers extensively about the research methods and validating those.
• I recommend to read both, but skip the latter if you're not in to research language.

However, I found a some interesting paragraphs in DevEx in Action.. first they summarize well why it requires attention:

There is a difference between simply writing code and writing code in an environment that is optimized for writing code. Environments are optimized for writing code are efficient, effective, and conducive to well-being, and rely on the right mix of tools, practices, processes, and social structures. These environments help developers:

• Get into the flow and minimize interruptions so they can
  focus and solve complex tasks.
• Foster connections and collaborations so they and their
  teams can be creative when it matters most.
• Receive high-quality feedback so they can make
  progress.

Secondly, they summarize why it does not get the attention it needs (management), and goes on about how the study can be used as compelling evidence:

Knowing intuitively the importance of DevEx, however, is not always enough to make a compelling case to upper management. When management rightfully asks if DevEx has an impact on business, this study can provide an answer, showing that DevEx affects the performance of individual developers, teams, and organizations. Further, our analysis clearly indicates which factors should be given priority for teams to achieve positive outcomes. This evidence can justify a DevEx initiative, as well as provide actionable insights to guide a DevEx intervention.

The first actionable the give you, was especially interesting:

Get data on the current developer experience:

Understand what DevEx is like at your organization. For organizations that are just beginning their DevEx journey, this means collecting new data to reveal their biggest pain points, as well as knowing their current abilities to make changes. (You can use or adapt the survey used in this study, included in table 1, or a dedicated solution such as DX.) If this is your first time collecting data about DevEx, this becomes your baseline. If you have already been doing some DevEx work, you can integrate this data and update your metrics.

We already have some initiatives I'm aware of, that relate to developer experience & productivity:

• AI adoption, for example GitHub Copilot
• Internal Developer Platform(s), for example Transportation Cloud
• Internal Developer Portal, like backstage.io

One thing I have not stumbled upon on, how do we get data on the current developer experience? How would you validate if you, your team or the organization is benefitting from AI tools like GitHub Copilot? For example, [Netflix uses DORA & SPACE](Developer productivity engineering at netflix), and even McKinsey suggests the same, but apart from DORA, which I know some are using already, I can't recall hearing about SPACE being used extensively.