Part of how I’ve made myself useful as a consultant sometimes in my career is by insisting on a strict set of processes that break down and identify bottlenecks like this. It’s almost always ops, it almost always can be automated, but there’s “no bandwidth or budget” to fix the problems so they expect superheroes to constantly save the day by pulling absurd hours or by inventing genius solutions that management buys into.

For me, as an IC or sometimes as a consultant, I try to chip away. We spend X minutes a week doing Y thing manually. what’s the easiest thing we can do to reduce X? and then slowly introduce whatever arises out of those processes, and then slowly “eat the elephant” one bite at a time.

when people come into a big messy manual legacy system they often, imho, make the mistake of wanting to tear it down and recreate it from scratch. having done several cloud architecture/IAC refactors in my career, I can tell you its definitely a way easier sell to management and other teams to whittle away at it than to recreate it entirely, and i think that’s also what the video is poking fun at. There’s always skeletons that your perfect solution will run into. Processes, standards, and monitoring will expose these dead bodies, but it’s not a one shot solution and I’m immediately skeptical when anyone proposes something in this space that is. Every situation is a snowflake.