I think you'll really struggle. Despite my title I still spend a lot of spare time coding, attending and speaking at tech events and was a coder for 30 years. I have also worked in product ownership roles too. The reality is that not only will you struggle to convince coders, you'll turn them against you because you use what the industry often regards as "Doodleware". It's the same attitude that buffets tools such as TIBCO AE, WSO2, NeuronESB etc.

You have to understand some of the key aspects of the mindset. Despite the very intellectual nature of the role, many software developers are extremely irrational, short sighted and a lot dimmer than the role and the reward's they're paid would have us believe. Many see their roles as crafts and as someone who tried to push the industry into true engineering lines some 20 years ago, trying something genuinely new, but too far outside one's natural paradigms, as a cohort, doesn't go down well at all, even from within it's own ranks. It's taken that long for some of the concepts I was talking about back then to start to permeate software development today. They're human after all and have very much the same concerns every other human has, but also with a unhealthy dose of prejudice to go with it.

Taking ESB's like the above as a part of an example. Many ESB's have build in routing and workflow configuration tools and have a sweet spot where their delivered value overtakes direct connections, including those of [badly engineered?] microservice architectures. This is due to the combinatorial complexity (or rather the explosion) of such connections, make change more cumbersome the bigger it gets, since they have to change up to O(n-1) connections to other services. By comparison, ESB solutions with workflow designers can make such changes in O(1) - There is no growth to that complexity. Configure a single new transformation and go. Similarly, workflow design is just reroute, and publish. That said, even here, aspects of Test Driven Development/Behaviour Driven Development are still necessary.

From a product owner's perspective, this carries unbelievable value, since it lowers the skill bar required to participate in the change (so QA's, designers, BA's and even product owners themselves can do to) making ongoing change substantially faster, easier, less risky and 'multi-skills' everyone as good as overnight. Otherwise to reduce the "Bus factor" risk alone, they'd have to find and recruit people with that skillset, taking time and money and for niche tools, this carries a high probability of failure and high cost in wages or contract rates. Having a workflow or configuration tool to do the job ups productivity massively. If you have developers who truly mean they deliver valuable software, they'll understand that's value. However, with all due respect to my colleagues in the industry, many say it, but don't mean it or understand it.

This sort of tool is a direct attack on revenue streams and someone's livelihood, though that will never be admitted. So you have to be mindful of that. I go through challenging conversations all the time, with both sides of the divide, mainly because I am almost "allergic" to waste. I have no issue having such conversations when needed and the same process happens.

1. Tool is touted as a solution by managerial teams
2. One developer is chosen to try it out (note, foisted upon them)
3. Developer begrudgingly uses it, doesn't get the wider benefits, presents an argument either to dismiss it or accept it "passive-aggressively"
4. Product owner, Manager, EA or whomever mandates use of the tool, effectively taking credit for the devs work
5. Devs use it, hate it, don't use (or attempt to use) it effectively, and it gets a groupthink of frustration
6. Tool is rejected

The answer is usually to allow developers to come to the conclusions themselves. There is almost no way of doing it otherwise. It almost certainly means your skillset won't be valued and in some case, it'll be laughed at.

As an example, ESB's are shunned (even the free ones like WSO2) in favour of MassTransit, which is more lightweight but if you visit the sites, you'll see requires code to change it. That means lower ubiquity (the world is bigger than software development) and it has to be built into the Continuous Integration/Deployment process and tests have to be written for everything from the routes to Automatonymous (the state machine). So it's not quick and for others, it's not easy.

Make no mistake, MassTransit is cool, I really like it with my coding hat on, but in reality all the problems it solves have been solved before. Many people say WSO2 etc. are not testable, which couldn't be further from the truth. They just don't have the skills to test it and "cargo cult" their objection, as this hits ego massively. There is of course, the automatic objection to vendors, especially high priced ones, thereby potentially iring them with your Sharepoint skills too. So be mindful of all of all of that.

Happy to discuss it on a call if you need more information.