I work in an automation-focused role that has gradually become much more technical than operational. Much of my job involves fixing manual or unreliable processes and building automations around business rules, integrations, permissions, data sources, testing, and edge cases. I still consider myself relatively junior on the technical side.
The 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 incrementally, permissions can change, and some required capabilities depend on other teams.
From the business perspective, stakeholders may only see that an automation is not finished. In reality, the schedule can be affected by security reviews, infrastructure work, access requests, or decisions owned by other teams. I've started documenting blockers and explaining development stages more clearly, but I'd like to understand how this is typically handled in US and European companies.
How much responsibility generally remains with the developer when delivery is blocked by access or another team? What are effective ways to set expectations when a request sounds simple to the business but involves significant technical dependencies?
4 Answers
Make approvals and dependencies visible in the same tracker as the automation work. Put the blocker, the responsible team or person, the date it was raised, and the number of days it has been waiting. “Not ready” sounds like a development problem, while “waiting 11 days for platform access” clearly shows where the delay is. Regular reports can also reveal recurring bottlenecks and encourage the approval process to improve.
For project-based work, a project manager or delivery owner usually helps coordinate this. As the developer, you should raise the request, explain its impact, document follow-ups, and keep working on anything that is not blocked. Stakeholders and owners are then responsible for providing decisions, approvals, or resources. If they do not respond, record that fact and move on to other useful work rather than silently absorbing the delay.
Try to involve stakeholders in the approval workflow so they can see what is required and where the queue is slowing things down. A status such as “blocked—waiting for security approval” is much more useful than simply saying the automation is delayed. The developer remains responsible for communicating early and accurately, but should not be held solely accountable for work that cannot proceed without another team’s action.
Start with the person or team responsible for security or access and ask for an expected completion date. If they provide one, communicate that date and the dependency to your stakeholder. If there is no response or the date threatens the delivery timeline, ask the stakeholder to help escalate it. This keeps escalation factual and tied to project impact instead of making it sound like a personal complaint.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures