Code of conduct: writing one that settles arguments

A code of conduct sets out how people in an organisation are expected to behave towards each other and towards customers, suppliers and the public — and what happens when they do not. It is one of the few documents that everybody in a company is supposed to have read, which makes the usual version, three pages of values written in the abstract, a wasted opportunity.

The test of a code of conduct is not whether it sounds right. It is whether, when something awkward happens, two reasonable people reading it reach the same conclusion about what should be done.

What a code of conduct should contain

• How people treat each other: the standard expected, and the behaviour that is not acceptable, stated concretely.
• Harassment and discrimination, with a definition specific enough to apply and a route to report.
• Conflicts of interest — outside work, family relationships, personal financial interests in a supplier.
• Gifts and hospitality, with an actual threshold rather than the word reasonable.
• Confidentiality: what may be discussed outside the company, including on social media.
• Use of company property and systems, briefly, with a pointer to the detailed policy.
• Honesty in records and reporting — expenses, timesheets, customer claims.
• How to raise a concern, who hears it, and the assurance that raising one in good faith carries no penalty.
• What happens when the code is breached, described in outline rather than promised in detail.

Thresholds are what turn a code into a usable document. A supplier offers concert tickets: is that acceptable? A code saying employees must avoid inappropriate gifts leaves everyone guessing. One saying gifts above a stated value must be declined or declared, and hospitality above a stated value needs approval, answers the question in the moment somebody has to answer it.

Values are not conduct

Most codes of conduct open with a page about integrity, respect and excellence. Those statements are not harmful, but they carry no information: nobody has ever resolved a dispute by reading that the company values integrity. The useful content starts where the abstraction stops — when the document says what to do about the specific situations that actually recur.

A practical way to find those situations is to look back at the last two years of awkward moments. The dispute about a manager hiring a friend, the argument about what could be said publicly about a customer, the expense claim that was technically allowed and clearly wrong. Each is a section the code should have.

Writing and adopting it

1. List the situations that have actually come up, or that plausibly will in your line of work.
2. Write each as a short rule with an example, in the second person, addressed to the reader.
3. Put numbers where numbers help: gift values, approval thresholds, notice periods.
4. Say who to go to, including an alternative route when the concern involves that person.
5. Have someone outside the drafting group read it and mark anything ambiguous.
6. Adopt it visibly — leadership going first, and acknowledgement recorded at onboarding.
7. Apply it consistently the first time it is tested, since that is the moment it acquires or loses authority.
8. Review annually and after any incident it handled badly.

Enforcement is what makes it real

A code applied to junior staff and waived for whoever is currently indispensable is worse than no code, because it documents the double standard. The first serious test is where the document becomes either the organisation's actual standard or a piece of decoration everybody now understands to be decoration.

Related to that: keep the disciplinary detail in the disciplinary procedure, not the code. Those procedures are often prescribed by employment law, and a code that promises specific sanctions can conflict with the process you are legally required to follow. The code says what is expected; the procedure says how a breach is handled, and that part deserves a check against local rules.

Keeping it

Ettex Docs is the practical home: one document with version history, so the code in force when an incident happened is still readable afterwards, comments for gathering objections during drafting, and a single link rather than a PDF attached to an old email. The related policies sit alongside and get reviewed on the same cycle.

It does not record acknowledgements — there is no per-person accepted this document tracking, no acknowledgement workflow and no reminders. If you need evidence that each person has read it, that is collected separately, and it is worth collecting: it is the first thing asked for when a breach is disputed.

Write the situations that actually happen, put numbers where numbers help, name the route for raising a concern — and apply it the same way to everyone the first time it matters.