Figure out who's leaving the company: dump, diff, repeat
One common element of the larger places where I've worked is that they tend to have a directory service of some sort that keeps track of who's an employee and who isn't. You can learn some interesting things by periodically dumping that list and then running comparisons against the previous dump.
A certain company had this rolled up into an internal service called "epitaphs" where an entry for a person would appear a day or two after they "disappeared from LDAP" - meaning, they left the company. Then other people who still worked there could add comments like "went back to school", "moved to Idaho to raise sheep", that kind of thing.
This had an interesting side-effect that you couldn't write to your own "epitaph" because by definition you had to already be gone from the company for your page to exist. Someone else who knew you had to add it. I actually received an e-mail to that effect one time: "I'm leaving, so when it shows up, please add XYZ". I was pleased that they trusted me to do that, and a few days later, I pasted it in as requested.
Another place I worked didn't have anything quite like this. There was the "internal profile" where you could see that so and so worked at the company from <date> to <date>, but there wasn't any sort of periodic update available. I decided to roll my own. It didn't take much in the way of effort, really. A cron job on my dev server (a physical box in a datacenter with access to my home directory) woke up a couple of times every day and dumped the entire list to a file. Then it compared it to the last one, crunched it down to just the uid (unix account name) field, and appended the results to a log file.
Over time, various other people learned about this, and since I had left it world-readable, they were able to leave up a "tail -f <path>" to keep tabs on it, and sometimes something surprising would show up during the day. People would sometimes just vanish. Other times, there were bizarre things going on that added a bit of context.
The log entries looked like this:
Thu Feb 08 18:26:42 PST 2024 : uid: <someone>
That was enough to let you go digging and find out more if you actually gave a damn about why that particular person no longer worked there. Otherwise, it didn't flood you with useless data.
One time, I pasted in a line like that into an IRC channel and that <someone> popped up and said "yeah, I don't work here any more". It turned out their account had been deactivated, but they still had a client connected. When I mentioned their account name, they got a notification, flipped to that window, and replied. We had a few minutes to chat about it.
It was weird saying farewell to someone that way. Normally, the electronic lines of communication are severed early on. I think what happened here is that the IRC servers only checked auth at connect-time, and then nothing went back to make sure that sessions remained associated with current employees. (It's a bit of a hard problem.)
Another time, some manager type said they were going to be late for a meeting because of some "dumb manager thing" they had to do. Sure enough, a few minutes into that meeting, a line scrolled across showing the deactivation of an account of one of their direct reports. Obviously, they had to go into one of those HR meetings where they showed someone the door.
I'd say the best time to start doing this is when you start at a company, or when that company grows big enough to actually have LDAP or whatever. That means the second-best time would be today.
Incidentally, the 'comm' tool is great for this sort of thing.
comm -2 -3 <(grep ^uid: old | sort) <(grep ^uid: new | sort)
... and there you go.
Now, this sort of thing is not perfect. If you don't catch errors, the first time it fails to dump and yet diffs a full list against an empty list, it'll look like everyone quit. This is not what you want. Also, once you work at a big enough company, there WILL be days when some automation will run amok and "fire" everyone, and every account will be deactivated. This will happen more than once if you stay there long enough.
Incidentally, if someone gets mad about you running this sort of thing, you probably don't want to work there anyway. On the other hand, if you're able to build such tools without IT or similar getting "threatened" by it, then you might be somewhere that actually enjoys creating interesting and useful stuff. Treasure such places. They don't tend to last.