Before answering the question, we have to keep in mind the trade-offs that are involved here.

When you centralize this type of things, you will indeed reduce the maintenance burden on all the other teams, but you also introduce an organizational dependency between the teams.

What I mean is that teams won't have to worry about fixing problems in the shared code, however they also won't be able to have new features they need until your team is free and ready to implement them. This type of things cause conflicts between the priorities of your team, and that of other teams (or event between other teams, if they both need different features at the same time).

Now to answer the question more directly, there is an immediate value only if you are trying to roll out an organization-wide change that will affect all automation pipelines.

Otherwise, I'm afraid there is no immediate value in this case. Duplicating code never really causes significant issues right away, it's always a problem that develops over time. Usually the issues that crop up are caused by the fact that duplicate code contains duplicate bugs, or caused when a change that impacts all automation has to be implemented (there will always be some people lagging behind).

Maybe a better solution would be to write your automation code such that teams are able to extend it. Keep a common core that takes care of the typical usecase, but provide hooks that individual teams can use to customize the behavior.

Before answering the question, we have to keep in mind the trade-offs that are involved here.

When you centralize this type of things, you will indeed reduce the maintenance burden on all the other teams, but you also introduce an organizational dependency between the teams.

What I mean is that teams won't have to worry about fixing problems in the shared code, however they also won't be able to have new features they need until your team is free and ready to implement them. This type of things cause conflicts between the priorities of your team, and that of other teams (or even between other teams, if they both need different features at the same time).

Now to answer the question more directly, there is an immediate value only if you are trying to roll out an organization-wide change that will affect all automation pipelines.

Otherwise, I'm afraid there is no immediate value in this case. Duplicating code never really causes significant issues right away, it's always a problem that develops over time. Usually the issues that crop up are caused by the fact that duplicate code contains duplicate bugs, or caused when a change that impacts all automation has to be implemented (there will always be some people lagging behind).

Maybe a better solution would be to write your automation code such that teams are able to extend it. Keep a common core that takes care of the typical usecase, but provide hooks that individual teams can use to customize the behavior.