[talkimhi]

Well even though you are talking about "corporate jargon" - From my experience this role becomes relevant much sooner. Many startups (especially in hyper growth) will suffer from decreasing velocity due to tech debt and lack of investment in dev experience and engineering enablement.

Enablement can be done in many ways - internal APIs, Skeletons, Communication protocols, Education and more. The fact that these are backend developers with different mentality and goals already makes a huge difference. For both the business and their fellow engineering that see the investment in their experience.

> This applies to literally every software company ever

Well not really. It might be right to the more mature ones. Also, There are many ways to implement Engineering Enablement, but once you cross the 30 engineers in your R&D, it feels like the right time to consider a dedicated team that are measured on these things instead of new features.

> Treating systems architecture with the same "ship it" mentality of product features is asking for a world of hurt.

Totally, That's why I'm sharing the importance of having such a role and saying this should be a dedicated role and not something you do "on the way". You must dedicate time for engineering enablement initiatives. If you can achieve it as "engineering bucket list" within your current organization - Good for you. You should give this baby a name - Engineering Enablement