* Security implications of moving staff from one department to another
I was chatting with my friend Hamid the other day and he told me about how he had just come back from a little gathering in the departmental office at the university where he works. Seems the janitor, Sandy, had been moved from the Computer Science building to the Humanities building despite roars of protest from the entire CS faculty and staff. Sandy had been working for CS more than 18 years and was beloved by everyone there. She was always ready to help in any way possible and kept the building spotless. She and the departmental secretary, also called Sandy, would have coffee every morning and were a pleasant sight as they chatted amiably.
Well, it wasn’t a pleasant sight for everyone, apparently.
The people in charge of facilities management decided unilaterally, without consulting anyone, that Sandy the janitor was too friendly with the faculty and staff at CS. They moved her suddenly to Humanities and ordered her not to spend any more time chatting with people. “Just do your job,” they said.
Sandy was heartbroken. All the people who smiled at her and stopped to chat every day at CS were also pretty displeased; they organized a petition, formed a committee, and got the department chair to protest to Facilities demanding the return of Sandy.
No result.
Eventually, Hamid and all the other faculty and staff chipped in some cash and got Sandy a nice farewell card. The department chair said a little speech and then read out a letter that the chair of Humanities had already written even though it was only a month since Sandy had switched. In that short time, Sandy had already so impressed the new group that the Humanities chair had written a letter of thanks saying that she had never seen the building so clean! Hamid and his colleagues all wished Sandy well and told her to come back to visit them.
And what, pray, does this charming tale have to do with security management?
The relevance is that two of the suggestions commonly heard in IT management circles are that
(a) One should assign a specific technical support or security person to a specific department or other group so that the IT person can form bonds with the personnel and get to know their needs; and
(b) One should rotate personnel from department to department periodically to prevent collusion.
The problem is that these recommendations lead in opposite directions. It’s very nice to talk about forming bonds and it’s no doubt very efficient to talk about preventing collusion, but how do we reconcile these diverging goals?
I don’t have easy answers, as you can probably tell from the way I’m framing the story and the question. I think that part of the problem is expectation; another part is timing. Now I’m going to speculate that Sandy the janitor was never told that she would be moved from building to building. My guess is that none of the janitors were told that there was any reason to avoid being friendly – who would reasonably think that being friendly could be viewed negatively? So suddenly moving her must have been a real shock. If it is true that the move was sudden and exceptional, then it was also a slap in the face: presumably Sandy felt that she was being told she had done something wrong. Clearly Sandy wanted to do the right thing, so such a judgment and punishment must have been doubly painful.
As for timing, 18 years is a long time to wait before being rotated. Rotating staff can be viewed as positive; there can be benefits for everyone. For example, thinking now about security management, one can spread knowledge through the entire security team by having people learn about the work habits and security needs of a wide range of work units and individual people. Getting to know colleagues as individuals and becoming friends with many of them can really make a difference in developing and implementing security policies, emergency-response plans and disaster-recovery plans. So switching people around is not inherently bad and can be constructive.
The question is, how long should a security team member be assigned to the same beat?
My own guess is that it should be on the order of many months – maybe even a year. Much shorter than that and it seems to me that one would cause more disruption than growth. It takes time to earn trust and develop constructive relations; I’d let my personnel become acclimated to the new social environment and then enjoy the friendly relations for some time before gently moving them on to the next area. And I’d make sure that everyone knew what the plan was, that the new team member could be personally briefed and then introduced by the outgoing team member, and that occasional visits to the “old” beat were encouraged and praised.
With that kind of policy, moving would be more fun and less pain.
