← Back to context

Comment by roblh

4 days ago

I'm really curious, can you share even the broad strokes of how you approach that? I feel stuck in that loop all the time.

I probably made it sound fancier than it is, but in a consulting situation by the time someone is willing to listen to what I say they've likely been experiencing considerable pain and are willing to take advice, so it's a little different than when you are stuck there. which is basically, biting off the smallest pieces you can that give the largest value you can (to me, the value I use to measure this is roughly by time spent per week estimates). So if it takes me 20 mins to automate a task that is spending 3 hours a week of devops time, of course this is a super easy target. Not all tasks are like this and people are bad at estimating how much time they spend on stuff like this, so it requires a diligent approach and honest introspection (one of the hardest parts to me, people are wildly delusional sometimes). This involves a lot of meetings, alignment, etc.

The time I've been stuck in these situations, it's mostly about inflicting or bringing notice to enough pain that the business backs off on some tighter deadlines to give more time to automate the tasks that will free up the most bandwidth or time - and it's a lot of small bites. I typically will start (if I can) by insisting anything new that makes sense to be automated (making a basic estimate of time per week, and effort to automate, also something you need to factor in is long term maintenance to use as a pitch to sell to management) and stick rigidly to that until it starts taking over other legacy processes in sort of a slow strangler pattern. This can look wildly different depending on the infrastructure setup and needs and how much firefighting you're doing - which there is usually a lot of. So sometimes that first step is just putting out all the fires or gaining enough visibility/monitoring to ensure you know what fires need to immediately be jumped on and which ones don't, and most importantly, proving that to the business.

Unfortunately though, leadership buy in (to me) is the hardest part almost always which is why I say "inflicting pain" the way I do, it sounds bad, but if they do not feel pain you will never, ever get priority to do anything, because IME like I said "devops" guys to most businesses (and even a lot of technical people) are glorified sysadmins that cost and demand way too much.