The Hodgkiss Method

Think is the process of loading your existing knowledge before seeking clarity anywhere else.

This phase is entirely internal.

Nothing new enters the system.

No research.

No AI.

No documentation.

No Google.

No conversations.

Just your existing knowledge.

Why Think Exists

Every problem is brought to you by a person.

Before I think about the problem, I think about the person.

Who are they?

How do they communicate?

What do I already know about them?

What history do we have?

What context already exists?

The same request from two different people rarely means the same thing.

If I misunderstand the person, I'll probably misunderstand the problem.

What My Brain Is Actually Doing

I'm loading knowledge.

Not collecting it.

The difference matters.

I'm allowing my brain to naturally surface:

• experience,
• context,
• previous situations,
• use cases,
• relationships,
• patterns,
• assumptions I need to verify.

This isn't brainstorming.

It's orientation.

I'm establishing where I already stand before I move.

The Goal

By the time Think is over I should know two things:

1. What I already know.
2. What I still need clarity on.

Nothing more.

Nothing less.

The Exit

Think ends naturally.

Not when I know everything.

Not when I stop thinking.

It ends when my brain stops naturally surfacing additional knowledge.

At that point...

I'm no longer thinking.

I'm ready to seek clarity.

If I Skip Think

If I skip Think...

I'll ask questions I already know the answers to.

I'll waste other people's time.

I'll solve the wrong problem.

I'll borrow someone else's understanding before I've loaded my own.

Everything after that becomes more expensive.

The Lens

After reading this chapter, I want you to become incapable of hearing a request without first thinking:

Who is asking?

Because once you understand that different people require different questions...

You'll never approach another problem the same way again.

Define is the process of creating a shared understanding before anyone invests effort solving the problem.

Think loaded my knowledge.

Define aligns our understanding.

Until that happens, we're not solving the same problem.

Why Define Exists

Requests tell you what people think they need.

The end goal tells you what they're actually trying to accomplish.

Those are rarely the same thing.

Someone asks for:

• an AI chatbot,
• a dashboard,
• another report,
• a new process,
• more automation.

Those are requests.

Not objectives.

My job isn't to build the request.

My job is to understand the outcome they're actually trying to achieve.

What My Brain Is Actually Doing

I'm not evaluating solutions.

I'm removing ambiguity.

I want to understand:

• What do they actually want?
• Why do they want it?
• What problem are they trying to solve?
• What does done look like?
• What does success look like?
• Are we using the same words to mean the same thing?

Because if we aren't...

Everything built afterward rests on a misunderstanding.

What Define Is Not

Define is not brainstorming.

Define is not diagnosing.

Define is not researching.

Define is not designing.

It is simply creating alignment.

Sometimes I do that by asking another person.

Sometimes I do that by asking AI.

Sometimes I do that by reading documentation.

Sometimes I do that by opening the software.

The source doesn't matter.

The purpose does.

Every action in Define exists to reduce uncertainty about what we're actually trying to accomplish.

The Goal

By the time Define is complete:

We all understand:

• the request,
• the desired outcome,
• what success means,
• what done means,
• and what still needs to be understood before moving forward.

Not because someone said:

"Yep."

Because we've demonstrated that we're talking about the same thing.

The Exit

Define is complete when everyone can explain the problem, the goal, and the desired outcome back to each other in their own words...

...and still arrive at the same understanding.

Agreement isn't enough.

Shared understanding is.

If I Skip Define

If I skip Define...

I'll build the right solution...

...to the wrong problem.

I'll solve the request instead of the need.

I'll optimize for activity instead of outcomes.

The farther I get without alignment, the more expensive every correction becomes.

The Lens

After reading this chapter, I want you to become incapable of hearing a request without immediately asking yourself:

"What are they actually trying to accomplish?"

Because requests describe solutions.

Objectives describe destinations.

Never confuse the two.

Diagnose is the process of understanding exactly what is preventing today's reality from becoming the desired reality.

Think loaded my knowledge.

Define aligned our destination.

Diagnose explains why we aren't there.

Why Diagnose Exists

Every problem has symptoms.

Very few symptoms are the actual problem.

Most people begin fixing what they can see.

I don't.

I want to understand the first place where reality diverged from what should have happened.

Because everything after that is usually a consequence.

If I fix the symptom, another symptom appears.

If I fix the first divergence, everything downstream naturally improves.

What My Brain Is Actually Doing

I'm no longer trying to understand the request.

I'm trying to understand reality.

There are two realities I care about.

The first is the person's perceived reality.

What are they experiencing?

What do they believe is happening?

Their perception matters because it's the reality they're living.

The second is actual reality.

What is objectively happening?

What does the software do?

What does the documentation say?

What actually occurred?

Neither reality is enough by itself.

I need both before I can explain the gap.

What I'm Looking For

I'm asking questions like:

• What is actually happening?
• How should it be happening?
• What is causing today's reality?
• Can I go further back?
• What already exists?
• What tools, systems, or processes are involved?

I keep digging.

Not until I find a problem.

Until I find the first thing that became wrong.

What Diagnose Is Not

Diagnose is not solving.

Diagnose is not brainstorming.

Diagnose is not changing anything.

It is understanding reality deeply enough that changing it becomes obvious.

Sometimes that means:

• observing,
• reproducing,
• asking AI,
• reading documentation,
• opening the software,
• testing assumptions.

Those are tools.

Not the phase itself.

The phase is understanding.

The Goal

By the end of Diagnose I know exactly what is preventing today's reality from becoming the desired reality.

Not the symptoms.

Not the downstream effects.

The first place where reality diverged.

The Exit

Diagnose is complete when I cannot trace the problem any further back.

Everything before this point is functioning correctly.

Everything after this point is simply the consequence.

That's when I stop digging.

If I Skip Diagnose

If I skip Diagnose...

I'll fix symptoms instead of causes.

I'll create temporary improvements instead of lasting ones.

I'll spend time repairing downstream problems while the original failure continues creating new ones.

The Lens

After reading this chapter, I want you to become incapable of seeing a problem without asking:

"What was the first thing that became wrong?"

Because once you learn to find the first divergence...

You'll stop spending your life filling sinkholes while the foundation continues to crack.

Design is the process of intentionally resolving every requirement needed to achieve the desired outcome.

Diagnose identifies what must change.

Design determines exactly how it will change.

Why Design Exists

Knowing the problem isn't the same as knowing the solution.

A good design doesn't solve one problem.

It resolves every requirement associated with that problem.

Every decision creates another decision.

Every change affects something else.

Design exists to ensure every requirement has an intentional resolution before execution begins.

What My Brain Is Actually Doing

I'm mentally walking the entire system.

If this changes...

Then what?

If that happens...

Then what?

Who owns this?

What system does it touch?

What breaks?

What improves?

What dependencies exist?

What assumptions am I making?

I keep walking until there are no unanswered paths.

What I'm Looking For

I'm asking questions like:

• Have I resolved every requirement?
• Am I solving the actual problem?
• Am I introducing unnecessary complexity?
• Can existing tools accomplish this?
• Is a new tool actually necessary?
• What's the blast radius?
• What happens six months from now?
• What happens if the owner leaves?
• What happens when this fails?

Every answer becomes another branch.

I keep walking until every branch has an intentional resolution.

What Design Is Not

Design is not adding more.

More features.

More dashboards.

More workflows.

More automation.

More is not better.

Design is deciding what belongs...

...and intentionally leaving everything else out.

Every requirement must be resolved.

Not every possibility.

The Goal

By the end of Design...

The entire solution exists before anything is built.

The map is complete.

Every requirement has an intentional resolution.

Nothing important has been left to chance.

The Exit

Design is complete when every requirement associated with the issue has a complete resolution.

Not because there aren't more ideas.

Because additional ideas no longer improve the original objective.

I may still want to add more.

I don't.

Version 2 exists for a reason.

If I Skip Design

If I skip Design...

I'll create unnecessary rework.

I'll leave unresolved requirements.

I'll discover missing pieces during execution when they're far more expensive to fix.

The work might still succeed.

It just won't be complete.

The Lens

After reading this chapter, I want you to become incapable of hearing a solution without immediately asking:

"What requirement does this leave unresolved?"

Because incomplete designs don't fail from the parts you remembered.

They fail from the one requirement nobody intentionally designed for.

Execute is the process of faithfully implementing the design.

Thinking is over.

The design is complete.

Now I move.

Why Execute Exists

Execution should not be where the hard thinking happens.

It should be where the thinking gets built.

Every phase before this exists so I can execute with confidence instead of uncertainty.

I don't earn confidence by building.

I earn confidence before I build.

What My Brain Is Actually Doing

I'm no longer asking:

• Should I?
• What if?
• Maybe...
• Another idea...

Those questions belonged earlier.

Now my job is simple.

Build what we designed.

Follow the map.

Trust the work that got me here.

What Execute Is Not

Execute is not redesigning.

Execute is not redefining the goal.

Execute is not adding "just one more feature."

Execute is not chasing perfection.

If I discover something genuinely new...

It goes into Version 2.

It doesn't interrupt Version 1.

Execution requires discipline.

Not creativity.

The Goal

The goal isn't to build quickly.

The goal is to faithfully build what was intentionally designed.

If the previous phases were done well...

Execution should feel almost obvious.

The Exit

Execution is complete when the solution has been built and validated against the original requirements.

Not every future idea.

Not every future enhancement.

The original requirements.

If the requirements were intentionally resolved...

The work is complete.

Validation

Before I consider execution finished, I test it.

Not because I expect it to fail.

Because reality deserves a chance to disagree.

I compare what I built against:

• the original problem,
• the agreed outcome,
• the requirements established during Design.

If reality exposes something I missed...

That's not failure.

That's Version 2.

If I Skip Execute

Ideas stay ideas.

Maps stay maps.

Nothing changes.

The best design in the world creates no value until someone builds it.

Eventually...

Thinking has to become reality.

The Lens

After reading this chapter, I want you to become incapable of endlessly refining something that is already ready.

I want your next thought to be:

"Have I earned the right to move?"

If the answer is yes...

Move.

Reality will teach you what thinking never can.

Transfer is the process of making the capability independent of you.

The work is not complete because the solution works.

The work is complete because the capability remains.

Why Transfer Exists

Every project leaves behind one of two things.

Capability.

Or dependency.

If people still need me to explain it...

The work isn't finished.

If the process disappears when I leave...

I didn't build a system.

I built a bottleneck.

Transfer exists so the work can outlive the person who created it.

What My Brain Is Actually Doing

I'm no longer thinking about today's problem.

I'm thinking about tomorrow's person.

If someone new walked in...

Could they understand this?

Could they run it?

Could they improve it?

Could they teach it?

If the answer is no...

I'm still part of the system.

That's not the goal.

What Transfer Is Not

Transfer is not documentation.

Transfer is not a training meeting.

Transfer is not recording a walkthrough.

Those things preserve knowledge.

They don't create capability.

Capability exists when someone understands the reasoning well enough to make good decisions without me.

How I Transfer

I demonstrate the completed work.

Then I teach the reasoning behind it.

Only then do I document it.

Documentation comes last.

Documentation preserves understanding.

It doesn't create it.

The Goal

The goal is not for someone to repeat my words.

The goal is for someone to understand the reasoning well enough that they can reach the same conclusion in their own words.

That's when I know the capability has transferred.

The Exit

Transfer is complete when someone else can:

• explain it,
• use it,
• improve it,
• and teach it...

...without depending on me.

At that point...

The organization owns the capability.

Not me.

If I Skip Transfer

The work survives.

The capability doesn't.

Every question comes back to me.

Every improvement waits for me.

Every problem depends on me.

That's not scale.

That's dependency.

The Lens

After reading this chapter, I want you to become incapable of calling a project complete without asking:

"If I disappeared tomorrow, what would happen?"

Because the goal isn't to build something people need you to maintain.

Your goal is to build something that remains valuable without you.