I work in an automation-focused role that has gradually become much more technical than operational. I improve broken or manual processes and build automations involving business rules, integrations, permissions, data sources, testing, and edge cases, although I still consider myself relatively junior technically.
My company is becoming more restrictive about external or unapproved automation tools, so I'm moving projects into approved internal tools and infrastructure. The difficulty is that access is granted gradually, permissions can change, and some required features depend on other teams.
From a stakeholder's perspective, it may look like an automation simply isn't ready, even when the delay is actually caused by security reviews, infrastructure work, access requests, or dependencies outside my control. I've started documenting blockers and explaining development stages more clearly, but I'd like to understand how this is typically handled in larger US or European companies.
How much responsibility normally falls on the developer when delivery is blocked by access or another team? What are effective ways to manage expectations when a request sounds simple from the business side but is technically complex?
4 Answers
Set expectations early by breaking the work into stages: discovery, design, access and security approval, development, testing, and rollout. Give separate estimates for the parts you control and clearly label external dependencies. That helps business partners understand that “simple” automation still involves permissions, data quality, failure handling, and testing.
For project-based work, a project manager or delivery owner often coordinates this. For smaller teams, the developer usually has to document the dependency and notify the owner, but shouldn’t be treated as accountable for another team’s delay. Send the request to the responsible person first, record the expected date, and then ask the stakeholder to help follow up if that date passes.
Make security and access dependencies visible to the stakeholders. Track them in the same system as the automation work, including the responsible team, the date the request was submitted, and how long it has been waiting. A status like “blocked — awaiting platform approval” tells a very different story from simply saying “not ready.” Regular reports can also reveal where the real bottleneck is and give stakeholders something concrete to escalate.
Keep moving on anything that isn’t blocked. Build a proof of concept with sample data, document the required permissions, prepare test cases, and identify edge cases while approvals are pending. That shows progress without pretending the production delivery can happen before the necessary controls are in place.
It also helps to agree on an escalation path before there’s a crisis. If an approval misses its target date, the next step should be clear instead of relying on repeated informal reminders.