Thursday, February 07, 2008

4 Ds of Information loss – Demotion

Demotion is something of a kludge. I wanted a word which started with D. So "Demotion" covers being fired, leaving a job, redundancy and in a limited case... death. Simply put, demotion covers anything to do with leaving a job or letting someone's job go.

But loosing information? Yes.

It's not yours

Everyone know that, unless you own the company, the computer at work is not theirs to own, in much the same way that the company car does not belong to them, and that the telephone provided by the company does not belong to them. Yet in the same way that a company rep can fill the company car assigned to them with their stuff, many people customize their work computer and fill it with at least a little of their data.

Which isn't a good idea. While a representative can request a little time to remove any personal belongings from the company car, the same shouldn't be expected from the company computer. I know of one case where the staff left their desks to a meeting in the canteen, and upon being told that the company was laying them off, returned to their desks to find that they were locked out of their computers. Anything not on removable data was trapped in there.

With the ubiquity of USB Flash disks and cloud computing, no one has an excuse to have their personal information on the machine. But what if it's not just personal data.

All your database

How would you feel if your boss asked you for every email address and phone number you had accumulated over the course of your employment? This is what happened to Junior Isles. He worked for 9 years as a journalist and helping with putting on conferences for PennWell. When he left to set up a rival company, PennWell issued an injunction on the three requiring them to "return all the claimant's property including any information in paper form or stored on any computer". Isles had uploaded the details of hundreds of contacts into Microsoft Outlook on his desktop when he joined the company. Under UK law a journalist can retain his journalistic contacts. Every time he got a new contact, he added it to Outlook. PennWell claimed that these numbers were company property. Isles went to the high court. He lost.

Had Isles kept his journalistic contacts separate from his other work-related numbers, he would have been able to take them with him. His mistake was to mix the numbers up with non-journalistic ones - those with whom he worked setting up conferences - which should have remained with the company.

The technology used is no defense either. Be it on paper, SIM card, cloud or PDA. It means that legally your employer owns the details of your LinkedIn or FaceBook account if you mix personal and company contacts. And if you do, well its your own fault for doing it.

An untried and nested consequence of this is a small company using cloud computing. Using Google Docs, GMail and a VoIP solution such as Skype, it is possible to create a reasonably cheap office environment. If an employee uses and does all his or her work on these systems using their own personal id, then, legally, the company owns their electronic identity and not the person. The lesson is if you find yourself in such a situation, create a new id. Or use multiple profiles on the same machine. Either that or make sure your contract specifies that you keep all data stored in such accounts when leaving the company.

But let us assume that you have correctly separated (and kept separate) work and play. Lets assume that you leave the company with all your data intact. It is still possible for the company to loose data.


When someone leaves a company, everything that the person learned in there goes with them (which is why you have "no competition" clauses in contracts). Frequently when a person leaves a corporation, everything that the person created is also destroyed. The corporate e-mail account is erased. The machines used are re-formated. This means that unless someone searches for the data and takes it off the machine, its lost.

Even is the data is carefully stored away, its not always possible to get everything back...

What use is building a great home-grown billing system if it's not documented by the implementer? All over the industry are people who make themselves irreplaceable by refusing to detail what their data means.

I'm sure many contractors have been given a tarball of 'code' that someone wrote before moving on, and asked to 'make it go, it just needed some final tweaks'. Alas, without a database schema, some insight into what was being attempted, it's invariably easier to start from scratch again.
-- John Looney

Password unavailable

If someone leaves in an ordered fashion, then data is somewhat recoverable. If someone walks away unexpectedly from the company, there is some recourse. When an employee dies, well you can't ask them for their old passwords. While a company should have some "back door" (or even an alternative "front door") in to their systems, some companies may face similar problems as next-of-kin due to security and procedures of third party providers. Besides. Can you remember a password you last used a few months ago?

While not everything is cut-and-dried, remember to keep work and play separated.

Take care,
William Knott

With kind thanks to John Looney of Google (for the tech and social angles) and Simon McGarr of (for the legal questions and answers) and for all the people quoted above for providing their perspectives.

tags : , ,, , , , , , , , , ,

Labels: , , , , , , , , , , ,


Anonymous Anonymous said...

The judgment in the Isles vs Pennwell case was folly, given by a judge who was probably out of his depth. Note the line of the judgment which said: "Had Isles kept his journalistic contacts separate from his other work-related numbers, he would have been able to take them with him." As a journalist, his journalistic and work-related contacts are one and the same. Journalists are expected and in job ads often required to have a good contacts book...probably the reason Pennwell employed him in the first place.

11:42 p.m., May 27, 2008  

Post a comment

<< Home