1–10 of 77 posts
Edit: I’m thinking primarily about technical decisions, though of course these are made in a wider context (eg choosing tech that’s impossible to hire for).
as i recall part of the slogan was "long term thinking"
- Saying nothing about it, but "secretly" moving the team to another country by changing the manager and director, and not hiring anymore in this country, even when team members quit. It took awhile but I figured out that the plan was to let natural attrition take over and for every person who quits from here, hire their replacement there.
- Different company: after being acquired, the acquiring company communicated for eight months that no changes in staffing would take place, and that once the acquisition closes, everyone will be put on exciting new projects and a new bright future will emerge. Then, after the acquisition closed, laying off a third of the company immediately. Another third chose the exit soon after. Eventually, the company died.
- Third company: after being acquired by a large competitor, the director of technology for this third company promised them a new product for four years. I'm led to understand by those closer to the situation than myself that this director then proceeded to coast on vaporware demos for those four years, claiming the need to "pivot" or "reboot" the product as necessary, and promising more and more pie-in-the-sky fantasies until finally the gig was up and he was fired. That subsidiary also officially closed its doors eventually.
Just a few from my own experience!
I think you're probably asking about mistakes like deleting a database? But more often companies, orgs, or teams dying has to do with engineering management in my experience. I'll name a few I have experienced and you all can decide whether or not these count as "engineering mistakes?" - Saying nothing about it, but "secretly" moving the team to another country by changing the manager and director, and not hiring any…
To protect their identity I won't go into specifics, but not implementing anti-tampering on local and remote backups i.e. protection from root. Backups only residing on live systems. Not protecting systems from bad automation. Not deprecating old automation frameworks and continually adding new automation frameworks. I am intentionally excluding specific incidents.
How do you accomplish this? I have some ideas/assumptions, but I'd like to hear more about the best practices here.
To protect their identity I won't go into specifics, but not implementing anti-tampering on local and remote backups i.e. protection from root. Backups only residing on live systems. Not protecting systems from bad automation. Not deprecating old automation frameworks and continually adding new automation frameworks. I am intentionally excluding specific incidents.
> but not implementing anti-tampering on local and remote backups i.e. protection from root. How do you accomplish this? I have some ideas/assumptions, but I'd like to hear more about the best practices here.
(If 1 account gets compromised the other is still available)
Perhaps 2nd level is by using cloud specific features - such as AWS S3 Object locks (even owner can't delete the object till the retention period).
my 2cents
Ignoring the cloud for too long.