GC The Good Consultant Back to home

The book

The Good Consultant

A book about professional judgement, told through the experiences of a consultant who has spent decades moving between the boardroom and the engine room.

It answers one question: how do you become someone people trust with difficult technology decisions? Not through theory — through stories, observations, principles, approaches, and reflection. It isn't a consulting handbook or a collection of frameworks. Consulting is just the environment; the book is about judgement, and it's equally for founders, CTOs, architects, investors, and board members as it is for consultants. Reading it now means watching it get written.

Why I'm writing this

After twenty-five years of consulting, I've realised that the most valuable lessons were never the frameworks, technologies or methodologies. They were the observations that quietly changed how I think. This book is my attempt to capture those observations while I'm still learning them myself.

Story → Observation → Principle → Approach → Reflection

Most chapters follow this rhythm. Frameworks — DDD, Domain Storytelling, Event Storming, Team Topologies, Wardley Mapping, AI — show up in the Approach, but only ever as supporting actors. They're never the main character.

Currently in progress

Fire Seeking, Storytelling, Kind Isn't the Same as Good & Why Good Developers Behave Badly

The first four chapters to reach a full draft — becoming curious before becoming comfortable, why the best stories help people see reality for themselves rather than explain it to them, why being liked and being good aren't the same job, and why developer dysfunction is usually a systems problem wearing a people problem's clothes. The rest of the manuscript is still mostly notes; this is where the writing is happening right now.

The manuscript

A journey in six parts.

Not a finished table of contents — a living list, organised as the book itself is organised: not as reference material, but as a journey following the lifecycle of a consulting relationship, from the first conversation to leaving one engagement better than you found it. Some chapters are a full draft, most are still notes and an intention.

Part I — The Invitation

Consulting begins before the contract: referrals, first conversations, and building confidence before delivery begins.

  • Fire Seeking

    How do I notice the problems everyone has learned to stop seeing?

    Early draft

Part II — Joining

Earning the right to influence.

  • On Joining

    What do the first ninety days actually reveal, if you're paying attention?

    Notes only

  • Trust Is Your First Deliverable

    Trust

    How do I earn trust before trying to create change?

    Notes only

Part III — Understanding

See before you solve.

  • Curiosity Never Expires

    Curiosity

    How do I keep noticing, once I already know enough to stop?

    Notes only

  • The Fastest Route to the Wrong Answer

    Problem Space

    How do I avoid solving the wrong problem?

    Notes only

  • What Organisations Learn to Tolerate

    Toxicity

    Why do healthy-looking teams quietly tolerate what's hurting them?

    Notes only

  • Meet Them Where They Are

    Storytelling

    How do I bring people with me instead of talking at them?

    Early draft

Part IV — Creating Change

Helping organisations think together.

  • Simple Is Never Simple

    Simplicity

    Why is "just make it simple" the hardest advice to follow?

    Notes only

  • Designing Better Conversations

    Facilitation

    How do I help people think together?

    Notes only

  • Being Right Isn't Enough

    Influencing

    Why doesn't being right change anyone's mind?

    Notes only

  • Someone Owns This Decision

    Decisions & Accountability

    Who actually owns this decision, and do they know it?

    Notes only

  • Kind Isn't the Same as Good

    Honesty

    Am I protecting the relationship, or the outcome?

    Early draft

  • Choosing When Every Option Looks Plausible

    Solution Space

    How do I choose, when every option looks reasonable?

    Notes only

Part V — The Human Side of Engineering

Three years of pair programming and field observations.

  • The Last Competitive Advantage

    AI & Judgement

    What remains uniquely human?

    Notes only

  • Why Good Developers Behave Badly

    Developer Dysfunction

    What makes good engineers develop bad habits?

    Early draft

  • Pair Programming in the Age of AI

    What happens when your pair is a model, not a person?

    Notes only

Part VI — Leaving

Leaving people stronger than you found them.

  • Leaving People Stronger

    What's the only measure of a good engagement that matters a year later?

    Notes only

  • On Leaving

    Why does the way you leave say more than the way you arrived?

    Notes only

Great consultants leave capability behind.

Talk to me about the book