Hi everyone!, I'm doing a little research on the d...
# platform-culture
d
Hi everyone!, I'm doing a little research on the different flavours of
Engineering Productivity
in the industry, I found a lot of different ways to call groups with similar goals ( of course with a lot of nuances as it depends on company size, maturity, etc )
Copy code
Developer Tools ( Auth0, Facebook )
Engineering Productivity ( Google, Pinterest, Gitlab )
Developer productivity ( Airbnb, Zalando )
Productivity Engineering ( Spotify, Netflix )
Engineering Effectiveness ( Twitter )
Developer Efficiency ( Datadog )
The issue with the examples above ☝️ is that those represent only a very small percentage of the industry, I'm interested on the other maybe 99% ( loving this post from Jean Yang https://future.a16z.com/software-development-building-for-99-developers/ ) How do you call
the team
doing this kind of work in your company? Do you see
Platform Engineering
as one of the branches of
Engineering Productivity
?, or do you see it as independent discipline? 🧵
👀 2
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
m
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?
2
b
At the beginning of the year, we created the Developer Experience area. As our peers, we have our SRE and Security areas.
d
@Michael W Agreed, I have also heard of such individuals.
h
In Zalando, "Developer Productivity" is part of the "Builder Infrastructure" organization which also contains SRE, Observability, etc.
b
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”
h
Asking the other way around, regardless of naming, one could ask which department is focusing on tracking and improving Software Delivery Performance (Accelerate)?
👍 1
d
@Henning Jacobs Interesting, I like that approach, thinking about our specific case, there are different teams tackling different contributing factors for Software Delivery Performance
s
@Bruno Dias "There are only two hard things in Computer Science: cache invalidation, naming things and off by one errors." 😉
😂 1
b
Here at VTEX, we articulate these (and other metrics) as Development Lifecycle Metrics. It is our focus (in DX) to track and improve them.
d
@Bruno Dias, what are your Development Lifecycle Metrics? How do you measure Platform adoption and "user happiness"?
b
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
👍 1
We are still in the begging of the adoption. But how I thinking to measure user happiness it will probably be with CSAT
CSAT will be specific for each service, tool that we deliver in the platform. How is the satisfaction of the engineer regarding the build workflow, how they feel regarding the configuration management system… and so on.
d
Got it, thanks!
n
@Bruno Dias : How big is your team and which tool do you use for tracking the metrics
b
We have >200 engineers. We are testing (for some metrics) the codacy pulse. (DX team has ~13)
n
@Bruno Dias: Got it! How do you balance context switching between the DX(13engineers) and manage the flow of requests from engineers?
b
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.
n
Same! Thanks for the response @Bruno Dias