Appendix C: Common scenarios
Appendix C: Common scenarios
Tell us our competitor’s secrets
Often people are hired for a job on the strength of what they have learned working for a competitor. The assumption, often unstated, is that the new-hire will bring specific knowledge of their former employer’s competitive advantage.
In this situation, it is permissible to bring general knowledge of a competitor’s business to a new employer. You will have signed a legally binding employment contract with the first employer, and this prohibits the disclosure of any proprietary information to a third party without written permission. So you must not make copies of commercial-in-confidence material, and especially not sell that information to competitors, whether directly or by going to work for them. Severe penalties apply for proven breaches.
A recent press report describes how a man was sued by his former employer because he took with him 17,000 followers of a promotional Twitter account when he left. The former employer alleges that each follower is worth $2.50 and was seeking damages. The man was working for a competitor by this time.
Intellectual property protection or copyright applies to specific implementations of an idea. It is the implementation that is copyright. Organisations can try to patent or copyright an idea, but it is often problematic. An abstract idea can be implemented in any number of ways. If the implementation is sufficiently different from the original then copyright breach cannot be proven.
The history of innovation is full of instances where good ideas have been thought of independently yet simultaneously. The underlying idea might be similar, but the way it is implemented will differ significantly.
Work for us, but we won’t pay you
It is common practice for unscrupulous employers to hire interns; enthusiastic, usually young developers on low or non-existent salary, on the understanding that the experience they are getting is adequate compensation.
The employer exploits the intern by obliging them to work long hours, often at some considerable personal cost. Most people will burn out after a few months of this, and when that happens, they are discarded and replaced by a new wave of intern.
While it may be true that you are getting experience that will look good on your resume, as a rule you should not allow yourself to be exploited in this way, at least not for long. You deserve fair payment for the work you do. This may not be much money, given your lack of experience, but if you are creating something useful and profitable for your employer, you deserve to be paid.
Any attempts to exploit you like this should be treated with the contempt it deserves (short-term internships may be acceptable). If an employer’s business model relies on using free, skilled labour, it is questionable.
The costly patch
It is common practice by some software development companies to release defective software to their clients and then charge them to fix the defects that should not be there in the first place.
In some cases, the developer becomes aware that all their customers have a potential problem, yet instead of proactively sending out a patch to their customers, they wait for a customer to complain, and then charge them to fix the problem.
It is understandable why a developer might want to use a strategy like this, but it is clearly unethical if the software has been sold on the understanding that it is defect free. It is most unlikely that the customer agreed to accept faulty goods that they would be required to pay twice for, or three times if there is a maintenance/support agreement in place.
No, that doesn’t fit with our strategy
Software development companies with an idea for a software product will often look for a client who is willing to finance the production of the software which will then be sold to as many of the client’s competitors as possible.
If the client can be persuaded to pay full price, then so much the better. To secure the deal, the developer may offer a discount.
The client probably realises that they are funding a project that will not only benefit them, but also their competitors. Perhaps they trust a non-disclosure agreement with the developer to safeguard their interests. This trust may prove to be misplaced.
As development proceeds, there are sure to be times when the client says to the developer, thinking about it, we now want the software to do this or that (specific requirements). Unless this fits with the developer’s own product strategy, the client is likely to be told, no that cannot be done. It would be a rash or arrogant developer who then says, it cannot be done because it does not fit with our development strategy, though I have personally heard these words spoken in a client-developer meeting.
If the client is paying for it, they are entitled to get what they are paying for. If the developer wants to go in a different direction, they should do it at their own expense, on their time.
Two sets of accounts
Some businesses that accept cash money have been known to keep two sets of accounts; one for the purposes of paying tax, the other to tell the full financial story strictly for in-house use.
As a software professional working on an organisation’s accounts, you are likely to see information that your employer expects you to keep confidential. It may only be relatively minor matters, not necessarily a whole second set of book.
Confidentiality of the employer-employee relationship is extremely important in professional practice. Like a doctor or lawyer, what you learn must not be disclosed to a third party except under certain prescribed circumstances.
Becoming a whistle-blower is an extreme act, though sometimes it is justified. Before doing it, it is highly recommended that you seek the advice of your professional association. With good advice, your ethical concerns can be resolved without breaching your obligation to treat your employer’s information confidentially.
You should be aware that whistle-blowers, regardless of how well-intentioned they be, almost invariably become despised and unemployable.
