If you have ever wondered why I am particular about wording, framing, and delivery, here is the straight answer: how we write reflects how we think, and how we think shapes the outcomes we create.
This is a lightweight reference you can use to collaborate with me efficiently and with minimal friction.
Clarity is not optional
I value clarity over noise and outcomes over activity. I prefer calm, direct communication that is intentional and grounded in reality. Theatre and hype may look impressive, but they rarely improve outcomes.
My default writing guardrails are simple:
- I write using UK and South African English, and I avoid contractions.
- I hate and avoid jargon unless it is defined. If an acronym is needed, spell it out on first use.
- In meetings and collaboration, I strongly prefer no three-letter acronyms (TLAs) or jargon, unless everyone shares the same definitions.
Clear writing is respectful. It reduces interpretation gaps, avoids rework, and scales beyond tribal knowledge.
Value before effort
When I look at a proposal (or ask agent ubuntu to analyse), an architecture, or automation, my first question is:
What changed as a result of this work?
Every meaningful initiative should contribute to at least one of the following:
- Improving stakeholder experience.
- Reducing risk.
- Avoiding unnecessary cost.
- Enabling less mundane work and more valuable engineering outcomes.
If the value is unclear, the work is not ready. Busy teams are easy to find. Teams that deliver sustained, measurable value are not.
Outcomes beat activity (and ambiguity is expensive)
I care far less about how busy we are than about what improved. Activity is a means, not a result.
If you want fast alignment, bring one clear page:
- the problem statement,
- the intent,
- the expected outcome, and
- ownership and next steps.
One clear page will consistently outperform ten vague slides packed with buzzwords. If I have to scroll or page, you have likely lost me. If I have to ask for clarification, you have likely lost others.
Systems thinking over local optimisation
Most real problems are systemic. Optimising a single component while degrading the overall system is not progress.
This is why I favour:
- Single, authoritative defaults with deliberate overrides.
- Guardrails rather than heroics.
- Automation and repeatability over bespoke fixes.
These principles are not about control. They are about resilience, supportability, and safer change at scale.
Learning is a responsibility (bring fault lines and gems
A healthy engineering culture treats learning as part of the job, not a side activity. I am more interested in honest fault lines and practical gems than polished success stories. Curious engineers who ask good questions will always outperform loud experts who defend fragile certainty.
Ubuntu, always
I am because we are.
I believe in collaboration, stewardship, and collective ownership. Silence creates risk. Early conversations reduce it.
If you want to engage me effectively, do this:
- Provide context: the WHAT, WHY, and WHEN.
- Anchor on: Do the right thing, at the right time, all the time.
- Show up with optimism, passion, and empathy.
- Start with a one-pager. That is more than enough.
Closing thought
If any of this resonates, you are already aligned with how I write, think, and work. Clear intent, disciplined engineering, and measurable outcomes are not constraints. They are accelerators.
That is it for today!
Enjoy your favourite brew. I will savour my hot chocolate and raise it to disciplined engineering, sound judgement, and value‑driven progress.