In most small and mid-size companies that build software, the development team is fully committed to the product. That is where the revenue is and where the roadmap is. Operational automation, the work that would take hours of manual effort out of an operational process, joins the backlog behind customer-facing features and stays there. A year later it has not shipped, and the process is still done by hand.
This is not a failing of the development team. It is a correct allocation of a scarce resource. The mistake is treating operational automation as a software project that must pass through them.
What the work needs
Most operational automation does not need a product engineer. It needs someone who understands the process, access to the systems involved, and tools that are now cheap and well understood. The work can be designed, built and run alongside the development team rather than inside it, on accounts the company owns, documented so that the company's own people can maintain it.
What the technical staff are asked for is access, not labour: a service account with the least privilege that will do, a view of where the data lives, and a review of what was built. They are told what exists and where it runs. They are not handed a backlog item.
One caution
Working outside the development team must never mean working outside the company's controls. Access is granted and logged. Changes to records are approved by the staff who own them until they are satisfied the automation is right. Everything is written down so that IT can take it over whenever it chooses. Done that way, the development team keeps shipping product, and the rest of the business stops waiting.