[oroul]

> Would dedicated engineering time for a short time improve the situation and benefit the whole organization?

This applies to literally every software company ever. There's also too much vague corporate jargon to make it clear what specifically the role involves that makes it meaningfully different from DevOps.

> A different but equally important part of the team’s job is to architect, build, and refactor major software components

> handle multiple, sometimes conflicting priorities ... willingness to pitch in whenever necessary to get things done

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

[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

[throwawaysea]

For that matter even terms like DevOps seem very fuzzy and differently interpreted by everyone. It seems to some these are teams that fight fires. To others they are teams that perform any and all engineering relating to residence. To others it’s some mix. I’m not familiar with the space and approaches but I wonder if all these labels and constraints are useful or if it is better to just stick to a generic “software engineer” role.

[buitreVirtual]

One big difference with DevOps, according to the article, is that the enablement team can refactor the software and promote specific architectures and processes.

[nopenopenopeno]

Isn’t that engineering?

[talkimhi]

Let's say you are working in a micro-services architecture. Multiple services owned by multiple teams, some services are newer than others (years).

Now try to apply a new centralized logging system or migration to K8s or even introduce a new feature toggle system. How much time will this effort take? How many stakeholders will be involved, what are the tradeoffs of this effort? With an engineering enablement team or even a "task force" - this effort becomes much more feasible