> Companies must trust their employees at some level, generally the level of trust grows in relation to the employee's responsibilities.
Hard disagree. People should be trusted with the things they need to perform their role, and no more than that. You would not give access of a production database to a CTO just because they have more responsibilities than a sysadmin, and any CTO that tries to bludgeon their way into getting access to it should be considered unfit for work.
It sounds like we actually see that the same, I'm trying to make a slightly different point.
Say I'm a software developer specifically working on the frontend library for an authentication service. The company needs to trust me with access to parts of the system and infrastructure pertinent to that feature. I very much agree that I should be locked out of other areas that I don't need for the job, for example I shouldn't have access to employee records, accounting, etc.
Once I am fired, though, the company has to continue to trust me to not misuse the parts of the system that I do already have access to. If I am fired but allowed to stay for a transition period and my permissions aren't revoked immediately, the company is trusting me. If I am fired and immediately blocked, its a sign that the company didn't trust me rather than an indication of my own mistrust for the company/institution.
You could continue to work on things, but your access would be set to read-only and you'd lose commit rights, or you'd be working on a completely separate branch and as part of the transition process someone else on the team would have to be able to report they have successfully merged worked from your tree to the main one.
Going back to my original point in this thread, aren't you describing how the post-firing lockout is based on the company's mistrust of the employee rather than the other way around, right?
My point was never that there aren't security protocols that could be used, only that its not relevant whether the employee trusts the company in that scenario.
But it's the existence and application of these security protocols that can make all the difference, and having these protocols in place shows already some type of institutional maturity.
With the proper protocols in place, a company doing layoffs signals "we trust you can still perform your role as a developer, you can still communicate/collaborate with your colleagues and you can even access the source code (because who really is going to check if you are deleting the code repo from your machine?), and the removal of write-access to the systems can be seen as a smoke test if the transition can be done orderly", while the standard current procedure just says "Through no fault of your own, you will be seen now as a potential threat so we will treat you as toxic material".
Hard disagree. People should be trusted with the things they need to perform their role, and no more than that. You would not give access of a production database to a CTO just because they have more responsibilities than a sysadmin, and any CTO that tries to bludgeon their way into getting access to it should be considered unfit for work.