I'm pretty sure he wasn't saying to leave them unlocked indefinitely. Some companies lock accounts as soon as they lay people off (or even before), because they're paranoid that someone will grab trade secrets or sabotage something. Treating people this was is really insulting. It's generally reasonable to let people retain access for a short period of time (i.e. the rest of the day) so they can do things like send goodbye emails to the team, grab the e-tickets (or whatever) that they had sent to their work address instead of their personal address. No one should expect their accounts to remain unlocked for long, but long enough to close out any open threads and say goodbye is just being respectful.
The title is not entirely correct. The employee got logged out and locked out of everything. It's a sign of well integrated IT that this happened at the same time.
Ignoring the motivation and all the context around the lay-offs, it's probably the best way if you're going to piss of hundreds of people with access to various bits of the system.
From the administrative/IT point of view, I understand it entirely. It's a simple risk/value proposition. If an employee gets mad they were laid off (and that does happen) and decides in a fit of rage to start deleting Slack channels, damaging or even just accessing production environments, deleting shared logins in the team password manager, downloading company/employee/customer/client data, stealing company IP, etc., they could seriously hurt the company. Even if what they do is illegal or you can sue them afterward, it's a very significant short term loss and in some cases, they may be able to do damage that cannot be reversed like deleting Slack channels.
Obviously, every company should have good access controls in place that would prevent this from a regular employee. But that's not always possible and at the end of the day, some employees have to have those privileges. It's easier to just immediately lock them out of anything and avoid any potential damage. It seems cold to you (and it probably is), but even one ex-employee going rogue before lock-out could be disastrous. And that's without going into the "ex-employee drags down team morale by ranting about company/job" aspect and in many cases insurance companies will require it. It's just not worth it, even at a much smaller company than DO like where I work.
That's a common practice, but very foolish. If your employee is at all trustworthy they don't need to have their access revoked (and if they aren't trustworthy they'll just do the damage before they tell you they are leaving). So your org is robbing themselves of employee time without any actual benefit.
I’m would say pretty common? Sometimes it happens to personal accounts if the user has access to sensitive data. For setups that aren’t as sensitive or groups of employees that don’t have access to such data, various systems may be locked down for a period. For example, access to source control or staging/production environments may be generally limited. For unexpected one-off firings, the user is often locked out before they’re aware they’ve been let go.
If they leave the company, their access might be left running for a while in case they're asked to come back on and fix something during that post handover period.
Or maybe they had backups running under their account and when their account was disabled everything failed so they re-enabled it while they sorted out the mess...
Or they had multiple accounts as part of "security" and HR only knows to disable one and didn't find the other one in time.
There's a whole bunch of reasons why shit like this goes wrong. Every time. You'd cry.
(Warning anecdotal evidence)
Having worked in China on a number of startups and worked alongside people who have had to fire employees, it's often common practice to just lock fired employees out of their systems. I've had this happen to people I know and had to do it once when letting a programmer go (which is nearly impossible to do after a probationary period due to the labor laws in the country, it's very very difficult to fire somebody, the company has to provide reason, pay social benefits, or face the employee in a court--forget it if you're a foreign company).
I have heard stories of letting people go to find out that all of the work that employee did for the last month or two deleted, source missing, machines just wiped clean.
I read that title and kind of laughed because, well, it is a seemingly commonplace response in some parts of the world.
Emotions aside, isn’t it just sensible security policy to delete all permissions and invalidate all credentials of a terminated employee as soon as possible? Any other approach would be exceptional.
So I’ve been both an employee and a manager in companies that aren’t faang level but break 1 billion in yearly revenue.
This is advice from someone privileged enough that it was easier for their manager to ignore them as a problem, rather than deal with them.
Off the get go, it’s standard practice to remove all permissions and access to systems from someone who has tendered notice, in the interest of investors, security execs, and anyone who cares about the long term health of the applications being worked on.
The investors and security execs are placated by knowing that someone who has indicated they might possibly be disgruntled doesn’t still have access to damage the systems. Any manager who cares about the long term health of their systems doesn’t want someone involved in the day to day architecture and design designs who already knows they won’t have to deal with any problems that arise after a few weeks.
This isn’t even to blame the employee in question, they just no longer have the incentives to care about the codebase after their notice.
I have also definitely never seen a single person who gave notice and didn’t have access cut off, get to “focus on the fun parts of the job”. In that case they were normally tasked with knowledge transfer the whole time as if it’s an org that can afford the sudden loss of a single person, they also likely don’t have good documentation
For my recent layoff from a 100% remote role at a well known BigTech co, I was in the midst of a meeting and was abruptly signed out of my laptop and presented with a screen saying it had been frozen and prompting for a 6 digit passcode to unlock it. I had no idea what was going on and began calling IT support to get back in so I could let coworkers on my team know I was completely unable to do anything. They evidently hadn't been informed either as they actually gave me the passcode! I put two and two together when I got back in and was still locked out of everything, and a friend in a personal non-work Slack @'d me with the headline that my company was doing layoffs.
I asked the tech lead at a past job if he'd have been willing to resign over his decision to store our keys in the "cloud", using LastPass. He never responded.
The lesson is that employees should only have access to the resources that they need to do their job at all times, and that there should be a fine-grained permission system to check if someone can read or read-write to all these resources.
Even when I am working on my projects, by myself, I use different accounts to access my services, depending on the role. At first it might seem crazy, but if you learned how to do this and you automate this process, it is a life-saver if you suddenly find yourself need quick help from some contractor or if you want to give a backup key to a trusted friend as a way to say "here is what you need to do in case something happens to me".
And this is why corporations tend to have strict policies of revoking all access before people are informed that they are fired, or perhaps simultaneously while they're being told so that when they go out of the meeting room it's already done.
The vast majority people won't do stupid crimes like this, but the fraction who would can cause a sufficiently painful disruption (even if you have great backups, recovery and verification takes time, effort, downtime and organizational confusion) to justify that.
What I find curious here is the staggered shut down of access. Why wasn't it all immediate? Sure it might have taken time for parking access to disappear, since that message would have been sent over to facilities, but email and keycard access should have been shut down instantly at any large employer.
My employer is I suppose mid-size, and the shutdown all happens very quickly once that ticket is filed, even though it's a largely manual process.
(Of course I also find it curious, and alarming, that no one could/would shut down the automated process in his case.)
"A month earlier, someone in Bird's IT department had been tasked by his superiors to write a script that would allow the company to instantly shut down all of a user's accounts – computer, email, Slack – with the click of a single button, according to an employee. He was told the script would be used for general off-boarding rather than the mass layoff that he ended up being included in. Last Friday, the script seems to have been activated early."
He could have unpushed work, or some tools that he would like to recover. Effectively, wasted effort.
Also, I could imagine it being frustrating trying to figure out why your access has been revoked for two hours until some company rep calls you to tell you that you are no longer wanted.
reply