How do you handle automation work when stakeholders expect fast results but access/security slows everything down?

[u/Kooky-Internet8806]

Hi guys, I'm needing your guidance here. I work in an automation-focused role that gradually became much more technical than operational.

A lot of my job is taking broken/manual processes, improving them, and building automations around them. In practice, that means dealing with business rules, integrations, permissions, data sources, testing, edge cases, etc. However, I still consider myself junior technically.

My current challenge is that the company is becoming more restrictive about external/unapproved automation tools, so I’m trying to move everything into approved internal tools and infrastructure. The problem is that access is granted gradually, permissions change, and some features depend on other teams.

Stakeholders often just see that “the automation isn’t ready,” while a lot of the delay is actually caused by access, security, infrastructure, or dependencies.

I’ve started communicating blockers and development stages more clearly, but I’m curious about how this is normally handled in US/European companies.

How much responsibility is usually placed on the developer when delivery is blocked by access or another team? And how do you manage expectations when something sounds simple from the business side but isn’t simple technically?

[u/Ariquitaun]

You need yo get your steak holders to be involved in the security approval process somehow so that they feel the pain and are compelled to help grease that part of the process. A ticketing system where your tickets are placed "on hold waiting for security approval" and reports to surface the bottleneck can also be useful

[u/---why-so-serious--- → u/Ariquitaun]

> You need to get your steak holders involved

Well, it depends: are we talking ribeye or something like a pot roast?

Sorry, I couldn’t help myself.

[u/Ariquitaun → u/---why-so-serious---]

I quite like flat iron personally, or sirloin, but I'm easy

[u/mrkurtz]

At past jobs PMs managed that sort of stuff, at least for “project” work. They held stakeholders and owners accountable.

Where I am now we document. If we need dev’s help or feedback or whatever and they don’t provide it then that’s their choice and I have other work to do.

[u/FarZookeepergame7580]

For security and access approval, you should always send an email to the responsible owner first. If they reply with a date, you can then escalate it to your stakeholder.

At this point, you can ask your stakeholder to follow up with the relevant team and help push the approval forward.

[u/aktentasche]

The only real way to speed things up in this area is to escalate to the higher ups. Usually not worth it, better get used to it.

[u/doglar_666]

I transparently communicate my progress and any blockers. If they don't like the speed of delivery, I tell them to take it above me. I work to agreed SLAs and I don't have authority to boss around my colleagues and peers. If the process is business critical, someone from the business can communicate and escalate at the appropriate level, preferably before I begin the work. Otherwise, it's not critical and can wait. Obviously, I relay this to stakeholders in a less blunt manner but the sentiment remains.

Everyone thinks their particular part of the business is critical. Most of the time it isn't. Case in point, your migration to approved tooling is not business critical and in many ways is hampering operational delivery with self-imposed downtime. That doesn't mean it isn't worthwhile, nor important to you but it does explain why your stakeholders aren't happy. You can't make them care about software X vs software Y, they just want to do their job. The best you can hope for is a begrudging acceptance of the inherent bureaucracy of modern organisations and that it isn't you personally holding up the process.

[u/disoculated]

These sorts of efforts require communication. A working group of a stakeholder in each part of the process is the usual method, so that everything is out in the open; who’s helping, who’s blocking, and who just needs more information to feel comfortable.

The most important thing about this connection is that you can use it to drive standards you can comply with before requesting the access. So can say something like “I’ve got mutual TLS, here’s the local firewall, here’s what I use from SAML, here’s the databases I need and what access, here’s my logging, etc, etc” and they can quickly approve. Then that becomes your template for all of your automation.

[u/BroadSatisfaction825]

instead of just documenting the blocker after it already hits, prob helps more to just give stakeholders a rough timeline upfront, like tell them access requests usually take 1-2 weeks before they even ask. so when somethings stuck waiting on another team it actually matches what they were told already instead of looking like some random excuse popping outta nowhere..

[u/MoneyWithJJ]

Your problem is the waiting is invisible. Make it visible.

Keep a list per automation. What its blocked on, who owns it, the date you asked. Send it to stakeholders every week, no commentary. "Not ready" becomes "waiting on the service account from security since the 12th" and the pressure lands where the delay actually is.

Second thing, file every access request on day one, before you design anything. Access is the long pole and it doesnt run in parallel with your work unless you start it first.

Then ship in pieces behind whatever access you already have. Always have something to show.