← All writing
Published3 min readPersonalLeadership

What I want this site to be useful for

A place for practical writing about technology leadership, security, data and building useful tools. What I will share, and what stays private.

I want this site to be useful before anyone gets in touch about working together.

If you are leading a technology team, deciding where AI fits or trying to make disconnected systems work better, I hope you find something here that helps you think through the next step. That might be a question to ask a supplier, a way to review a proposal or a reminder to check the less visible parts of a build.

My work spans technology leadership, cybersecurity, data, AI and automation. I don’t see those as separate worlds. A technology decision affects the people operating it. A security requirement changes the design. An integration can be more useful than a new application. A capable team needs room to work as well as a plan.

Advice and building belong in the same conversation

I enjoy both sides of the work. Sometimes the useful contribution is helping a leadership team choose a direction. Sometimes it is building a small tool and finding out which assumptions survive contact with a real task.

This site should reflect that range. Custom internal AI platforms are a particular interest, but they are not the whole of what I do. You’ll find the business decisions alongside the practical work of getting something built and handing it over.

I want the writing to explain the decisions, not just describe the finished result. What was the problem? Which options were worth considering? What would make an approach unsuitable? What needs to be checked before people rely on it?

Useful detail without exposing private work

Some of the most valuable lessons come from work that should not be published in detail. I can discuss a design decision or a way of approaching a problem without naming an internal system, showing staff conversations or sharing sensitive information.

Where an example is hypothetical, I’ll say so. Where a conclusion is my judgement, I don’t want to dress it up as a universal rule. And where a number hasn’t been measured, it shouldn’t appear as a result.

That leaves plenty to write about. The questions around permissions, ownership, handover, change and human review are often useful well beyond the organisation where someone first encountered them.

Writing that can be used

I’d rather publish a piece that helps someone make a decision than fill a calendar with short posts. Some articles will be practical guides. Others will be reflections on how I work and what I’m still learning.

I will also revisit older pieces when my thinking changes or they need more detail. Those revisions should be visible. A current update is not a reason to pretend an article was first written yesterday.

If you only read one article, it should still make sense without having followed everything else I’ve published.

Start with the problem you have

If your team is constantly interrupted, start with leading an IT team out of firefighting.

If you are using AI to prepare decisions or documents, using AI without outsourcing your judgement covers the checks I think matter.

If you are considering an internal AI platform, the decisions behind the build goes into access, company knowledge, model services and operating responsibility.

And if you are wondering why a CIO still spends time building small tools, why I stay hands-on explains what I get from it and where the limits should be.

If something here connects with a problem you’re working through, I’m happy to compare notes. You don’t need a fully formed project brief to start a conversation.

Working on something similar?

If this connects with something you’re working through, I’m happy to talk about where you’re stuck and whether I can help.

See how I work