Methodology
How the work
actually gets done.
This page describes how consulting engagements are structured: the phases, the working rhythm, what I need from a client organization, and what they can expect at each stage. If you are evaluating whether to reach out, this is the right page to read first.
The core principle
Most knowledge problems are architecture problems, not execution problems. The approach I use reflects that. I start by understanding the structural situation before recommending anything, and I design solutions that the client organization can maintain independently after the engagement ends.
An engagement that creates dependency on me is a failed engagement. The measure of success is whether your team has the system, the documentation, and the understanding to operate it without me.
Engagement phases
Phase 0: Scoping
A 30-minute conversation to understand the problem, assess fit, and determine whether an engagement makes sense. I ask about the organizational context, the specific symptoms you are experiencing, what has already been tried, and what success would look like. You do not need to have a fully formed brief. Most organizations come in knowing something is wrong without knowing exactly what.
Phase 1: Discovery and diagnosis
The engagement begins with structured discovery: mapping what exists, identifying the structural problems causing the symptoms, and understanding the organizational constraints that any solution must respect. This phase produces a clear, shared understanding of the problem before any design work begins. Most clients find that the diagnosis phase alone is worth the engagement.
Phase 2: Architecture and design
Based on the diagnosis, I design the solution: the architecture, the governance model, the content structure, or the workflow redesign, depending on the engagement type. Design is iterative and collaborative. I do not produce a finished specification in isolation and hand it over. I work with your team throughout the design phase so they understand the rationale behind every decision.
Phase 3: Implementation and validation
For engagements that include implementation, this phase applies the designed architecture to real content and real systems. I work alongside your team rather than handing off a specification for them to execute alone. Validation happens continuously — we test the design against real use cases as we go and adjust when the design meets organizational reality.
Phase 4: Documentation and handoff
Every engagement closes with documentation designed for the people who will maintain the system, not for me. That means decision rationale, not just decisions. It means governance documentation written for the people who will enforce it. And it means a handoff meeting where I walk your team through everything they need to know to operate independently.
Working rhythm
Most engagements run on a two-session-per-week cadence: one working session with the operational team and one strategic check-in with leadership. Between sessions I am available for asynchronous questions on decisions that cannot wait. The cadence is flexible and adjusts based on organizational pace and engagement type.
I document decisions and rationale as we go, in a shared workspace your team controls. Nothing important lives only in my notes or my head.
What I need from a client organization
Access to the right people
Knowledge architecture decisions affect how content is created, governed, and used across the organization. I need access to the people who own those decisions — not just the people who will implement them.
Honest visibility into current state
The most useful thing a client organization can do at the start of an engagement is give me an unvarnished picture of how things actually work, not how they are supposed to work. Surprises in phase 3 are expensive.
Willingness to make decisions
Architecture requires choices. Some of them will be uncomfortable: retiring content that people are attached to, establishing governance that changes how teams work, or acknowledging that an existing system cannot be incrementally improved. Engagement works best when the organization is ready to make those decisions.
A dedicated point of contact
I need one person in the client organization who owns the engagement on their side, can make or escalate decisions, and is available on the agreed cadence. Engagements without a clear internal owner tend to stall.
What is out of scope
I do not produce content in bulk. I design the systems that make content production efficient and governable, and I produce reference examples as part of design work, but large-scale content creation is not what this practice does. If your primary need is production volume, I am not the right fit and I will tell you that in the scoping conversation.
I also do not take engagements where I cannot have access to the people and information needed to do the work properly. Engagements that are scoped to produce a deliverable without real discovery produce wrong deliverables.
Ready to have the conversation?
If this sounds like a structured, professional engagement rather than an open-ended consulting arrangement — that is the point. Start with the scoping call. No commitment required.