Why this exists

Most writing about technology leadership is produced by people who are selling something and have not done the work recently. It generalises, because the specifics belong to a client.

This will have the same constraint. What I can do is write about the patterns that recur often enough to be worth naming, with enough detail to be useful, and without pretending the answer is always the same.

What gets written here

Things that come up repeatedly in engagements: how to tell an advisor from an interim, what technical due diligence is really pricing, why a capable team can still miss dates, when a discovery is worth the two weeks it costs.

Mostly the recurring decisions, and how to tell which situation you are actually in. Getting that wrong is more expensive than getting the answer wrong afterwards.

What does not

No client names or details without permission, which in practice means very few. No case studies where the outcome is attributed entirely to the engagement. No predictions about which framework wins.

If a post is a sales argument wearing a hat, it does not go up.

Who it is for

Founders and boards making technology decisions they cannot fully assess, at a moment when the decision matters. If you are an engineer, some of it may still be useful, but that is not who it is written for.