I've bounced between engineering lead and engineering manager for most of my career. I was an engineering manager (internal IP) at a MSP that got acquired early in the pandemic, and chose to move to another (better-reputation) consultancy that got acquired by the same large multinational in 2019, but didn't get rebadged instantly. I enjoyed being an IC for a year, and managed to grow an account from 0 to 20+ staff in that time, got "promoted" back to management again - found that the company was in complete limbo due to an as-yet-unannounced fold-in to "megacorp" and left.
I've now gone to a basketcase of a smaller company, in a player/coach role - and I'm happier than I've been in a long time.
It wasn't for the money - I took a pay cut. I have more problems than I had at my last role - the key thing for me is I have the latitude again to solve problems.
Whether it's pure technology or people, either way it's a system engineering issue - and the more "fun" the problem - the more fun I've found I have solving it.
I've worked with at least several hundred of them over the past 5-10 years. Granted, I'm in Europe and the author is in the US, perhaps you are too. I'm not sure what talent/skills are like there.
In several firms I've worked in now someone missing so many things wouldn't be above consultant level, and wouldn't be approving PRs let alone deleting a live prod off from their local laptop without some significant questions being asked.
I get everyone must learn things, but when you position yourself as a technical expert (Director, in this case) you should have enough experience to be a bit more thorough with your work so if a mistake happens, there's a way out, or just not make what amounts to several design and implementation mistakes.
Part of what I think makes this a little egregious is the author didn't f** up his own systems, he f**'d his clients. I'd understand a little more if it were "I'm the in-house guy upskilling" rather than "look at this mistake I made as a (presumably) highly paid outside consultant literally brought in to make sure stuff like this doesn't happen".
However, I still must give absolute kudos for sharing mistakes publicly. We all do make mistakes, and most people try and hide it. When the author realised there was an issue, every step after that was handled like a pro.
Y'know, normally I'd be relatively forgiving as none of us are perfect, but jeesus this is a clusterf** of an article.
The author, a "Director of Consulting" might want to do some training (Both Hashicorp and Microsoft have free training).
Why in the hell would you have the same statefile for different environments? Why would you have these environments in the same Azure subscription? Why would you run your terraform so infrequently that you'd forget about a botched statefile move? Why would you not read TERRAFORM PLAN (It's LITERALLY WHAT TERRAFORM DOES)?
I also suspect that while the author's probably heard of a CI/CD pipeline, they're running their IaC from their local machine, given the tone of the article.
Why, for a production database that contains information not contained elsewhere, would you not configure an Azure Recovery Services Vault?
Like I get it, people make mistakes. I once did something similar with an overenthusiastic use of terraform destroy, but this guy just seems like an absolute cowboy who doesn't really know what he's doing.
I've now gone to a basketcase of a smaller company, in a player/coach role - and I'm happier than I've been in a long time.
It wasn't for the money - I took a pay cut. I have more problems than I had at my last role - the key thing for me is I have the latitude again to solve problems.
Whether it's pure technology or people, either way it's a system engineering issue - and the more "fun" the problem - the more fun I've found I have solving it.