Thanks @Russ Nealis again for the great read. It helps me understand where I'm at and my biases in terms of Internal Platforms' metrics. The first thing I do agree with is the article. I used to run a SaaS company and in B2B is extremely common to consider both the customer and the user needs separately. It also makes sense that for an external platform (what the article refers to), there is a third set of needs to consider.
Where my thought starts to potentially clash with what you wrote is that internal platforms are very different from external ones. And my advice is only battled tested for Internal platforms. For example, across all the companies I worked with, the voice of the developers was hardly heard, while instead, mostly what was driving platform development was the senior leadership's perceived need applied in a controlling way:
• we need more resilience; we will enforce it at the platform level
• we need more security, ...
• we need to improve some of the DORA metrics; the platform should be responsible
While I believe that part of a platform's job is ALSO to create an environment where the right behaviours are incentivised and the wrong behaviours are avoided, my drive to push for Product/Developer focused metrics stems from those three considerations:
• The focus on DX is strongly connected with the lack of it when building internal tools. I would love to hear if your experience differs, but this is what I observed in places that are not BigTech.
• Ultimately all the non-functional requirements above need product teams and platform team focus. If I have them as Product teams metrics, they will trickle down to the platform (again, this is not strictly true for every product the platform maintains, so I certainly have non-functional metrics for platform teams when needed)
• And ancillary to the above most of the behavioural changes described above are non-functional requirements (security, reliability, DORA) that can't be plugged in and require co-ownership. An excellent way to make it happen is to turn it into a need for the customer (internal teams)
Your message helped me realise that my bias is that I can operate and think at the system level because I'm responsible for the broader engineering function, so I can optimise the whole system. Product/Customer metrics are valid (IMHO) even if your other teams don't operate with a co-ownership mindset like described above. However, I would love other people's points of view on this because it's an important aspect and is quite foundational to my "thesis". What do you all think?