This message was deleted.

In our case, the team is called

Tools

at the moment, and emerged organically from the SRE organization, including some developers from outside the SRE org

In my opinion, I’m not sure it’s necessarily about the name of the team as such as understanding the dynamics of the org. I’ve seen teams called e.g. ‘DevOps Architecture’ who have a KPI for adoption % of the platform, because leadership already understands that this is the most efficient way to get things done and everything else is discouraged. I’ve also heard of companies where it is not a team but a single individual who is given the mandate to address productivity, and needs to rely on the other teams to make change. Perhaps more about what is the charter of the team/person and how are they measured?

At the beginning of the year, we created the Developer Experience area. As our peers, we have our SRE and Security areas.

@Michael W Agreed, I have also heard of such individuals.

In Zalando, "Developer Productivity" is part of the "Builder Infrastructure" organization which also contains SRE, Observability, etc.

We call here Tech Infrastructure. Different names for similar problems. 😂 “There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton”

Asking the other way around, regardless of naming, one could ask which department is focusing on tracking and improving Software Delivery Performance (Accelerate)?

@Henning Jacobs Interesting, I like that approach, thinking about our specific case, there are different teams tackling different contributing factors for Software Delivery Performance

@Bruno Dias "There are only two hard things in Computer Science: cache invalidation, naming things and off by one errors." 😉

Here at VTEX, we articulate these (and other metrics) as Development Lifecycle Metrics. It is our focus (in DX) to track and improve them.

@Bruno Dias, what are your Development Lifecycle Metrics? How do you measure Platform adoption and "user happiness"?

Hi @Daniel Serodio , we are derived from DORA metrics Lead time for changes • here we can split in other two: time to request a review, time to review • in the future we want to expand to add cycle time on top of LTC, this will consider also the time to design Change frequency Change failure rate Time to restore services Time between failures Service Level Objectives

Got it, thanks!

@Bruno Dias : How big is your team and which tool do you use for tracking the metrics

We have >200 engineers. We are testing (for some metrics) the codacy pulse. (DX team has ~13)

@Bruno Dias: Got it! How do you balance context switching between the DX(13engineers) and manage the flow of requests from engineers?

Align with the rest of the organization the priorities in that timeframe. When we have a good align we can say “no, why” in a simple manner. Now we have some things align and others not. So I need to manage expectations of the org needs.

Same! Thanks for the response @Bruno Dias