Language Matters
If you read Data & Grit for long enough, you’ll notice something.
It’s not written like a corporate document.
It’s direct.
It’s conversational.
Sometimes it’s blunt.
Sometimes it’s slightly provocative.
That’s intentional.
But here’s the important bit:
This writing style would be completely inappropriate in a formal technical specification, governance framework, or contractual document.
And that’s not hypocrisy.
That’s understanding audience and function.
Writing Has a Job
Every piece of communication has a job to do.
A blog post like this exists to:
- Engage
- Clarify thinking
- Share experience
- Invite discussion
- Build identity
A professional document exists to:
- Remove ambiguity
- Define accountability
- Assign responsibility
- Withstand scrutiny
- Prevent legal exposure
- Survive audit
Those are completely different jobs.
So the language must change.
If you mix them up, you create problems.
Where It Goes Wrong
One of the biggest failures I see in organisations isn’t technical.
It’s linguistic.
Badly written specifications.
Ambiguous Jira tickets.
Vague acceptance criteria.
Policies full of “should” instead of “must”.
And when that happens, something fascinating appears:
Malicious compliance.
What Is Malicious Compliance?
Malicious compliance is when someone follows instructions exactly as written — while knowingly violating the intent.
Not by breaking the rules.
But by exploiting ambiguity.
For example:
“The system should load customer data daily.”
What does “daily” mean?
- Once every 24 hours?
- Once per calendar day?
- Before 9am?
- End-of-day batch?
- UK timezone?
- UTC?
If someone loads it at 23:59 UTC and says,
“Technically it runs daily.”
They’re correct.
And the organisation suffers.
That’s malicious compliance.
It thrives in poorly written documents.
Why It Thrives in Vague Environments
Malicious compliance flourishes when:
- Accountability is unclear
- Outcomes aren’t defined
- Language is soft
- Nobody wants to be explicit
- Nobody wants to own risk
It’s rarely about bad engineers.
It’s about badly written instructions.
Engineers are literal creatures.
We optimise for what is written.
Not what was “meant”.
Audience Determines Tone
If I write on Data & Grit:
“If you don’t define your partitions properly, you’re building a time bomb.”
That works here.
It’s vivid.
It’s memorable.
It makes the point stick.
If I write that in a formal architecture document?
It becomes:
“Improper partition strategy may lead to performance degradation and operational instability.”
Same meaning.
Different function.
Different audience.
Professional communication is not about being less expressive.
It’s about being more precise.
Function-Based Communication
Ask yourself before you write anything:
- Who is the audience?
- What decision does this enable?
- What risk does this mitigate?
- What ambiguity must be eliminated?
- What will happen if this is interpreted literally?
That last one is critical.
Because in regulated industries — insurance, energy, finance —
everything eventually is interpreted literally.
By audit.
By compliance.
By legal.
By operations at 3am.
Why This Matters for Engineers
As engineers move toward architecture and leadership, language becomes part of the job.
You’re no longer just writing code.
You’re writing:
- Standards
- Guardrails
- Contracts
- Policies
- Definitions
- Diagrams
- Roadmaps
If your writing is vague, your systems will be vague.
If your language is sloppy, your governance will be sloppy.
And if your requirements are ambiguous?
You’ll get exactly what you asked for.
Not what you wanted.
The Discipline
The discipline is knowing when to:
- Be conversational
- Be inspirational
- Be sharp
And when to:
- Be exact
- Be measurable
- Be auditable
- Be boring
Boring documents save companies.
Engaging writing builds people.
They are not the same thing.
And that’s okay.
Language matters.
Because systems do exactly what we tell them to.
And so do people.
Gareth winterman