The Six Questions I Keep Returning To
How I organize the questions I investigate here: four tiers, six questions that never close, eleven playbooks, and a standing discipline of asking what we are not seeing.
Wherever something matters and tension exists, the same small set of questions needs answering. Most organizations never name them, so they re-litigate them by accident, in the middle of execution, when the stakes are highest. I name them once, up front, and keep returning to them on purpose. That is the whole method; everything else on this page is scaffolding for it.
Four tiers, from the most durable to the most living
Foundations and identity change deliberately; the questions endure and are re-answered; playbooks change when the approach changes.
Solid edge: durable tiers, revised deliberately. Dashed edge: living tiers, rechecked against the work. A healthy instance stays useful and current; how often it is revised proves nothing.
The foundations I work from
Curious eyes, sound judgment, quick feet. I explore what has changed, test what deserves belief and action, and adapt at the pace the consequences permit. I keep asking: what are we not seeing? and where has the constraint moved?
Pursue what matters. I direct effort to outcomes that matter, considering efficiency, effectiveness, and experience together. I make trade-offs explicit, including who benefits, who bears the cost, and what evidence could change the decision.
The identity sentence the whole structure serves: I help leaders focus their teams and their technology on pursuing what actually matters.
The six questions, as a cycle
Six practice areas, arranged as a lifecycle. Sequencing them as a cycle is a choice for transformation work, not a rule of the framework: define, deliver, measure, adopt, learn, scan, and back to define. This is the review order, not a sequence of permission: evidence and adoption are designed before delivery and rechecked during it.
6 → 1. The scan feeds the next definition. A gap in question 1 shows up later as a symptom in questions 2 through 5, which is why the cycle starts where it does.
What each question is really asking, and where you can watch it work
Selected briefings and practice notes show how I investigate these questions; they are not evidence that the architecture works in a client engagement, which stays private. Under each question is the test I hold an answer to.
Senior intent arrives at a level of abstraction that does not translate cleanly to execution. The gap between "improve the customer experience" and what each team hears is structural, not a communication failure, and it needs deliberate translation, success criteria before solutions, and trade-offs made out loud.
The test Which consequential decision is being made, whose outcomes count, what trade-off is accepted, and what evidence could reverse it?
Cheap execution raises the value of better questionsBound the work before you expand the autonomy
Resolution ownership rather than ticket ownership, governance that enables rather than files paper, and an authority path that reaches every channel an agent can act through. Activity is not progress.
The test Are we able and authorized to deliver the intended outcome: skills, dependencies, resources, delegated permissions, stop conditions, and recovery? Being set up is not the same as being authorized.
Why most AI pilots never shipControl the full authority pathThe scarce resource is the right to act
The efficiency trap, steering metrics against rearview metrics, what averages hide, and the economics of verification as the effort to produce analysis falls. Most dashboards measure what was easy to count.
The test What evidence, against a baseline and with an acceptance owner, shows we are achieving what matters, at what total cost and with what uncertainty? Counting a relevant metric is not enough.
Proxy metrics are theaterAI activity is not a performance scoreCheap analysis creates an expensive proof problem
The expectation gap, the frontline perspective, the trust equation, and adoption depth against vanity metrics. The curve is never uniform, and a mandate cannot produce what the organization has not enabled.
The test Is the work changing in ways people can use and trust, whether people use the tools or systems do delegated work: workflow outcomes, the ability to challenge or override, the correction burden, and justified non-use? Usage is not redesign.
Adoption is a workflow problemBehind the firewall, adoption is an operating modelAI adoption, drawn to scale
The invisible work problem, retrospectives that stick, failure as data, and the recovery patterns for a relationship that has gone wrong: the trust audit, symptom against structure, the first thirty days.
The test What capability or behavior changed, what outcome supports that judgment, and is expertise being lost as well as created?
What two AI reviews foundApproval is not verificationKnowledge outlives the mission only when someone owns the loop
Problem definition before prompt engineering, a thinking partner rather than an answer machine, context as architecture, and a systematic ear for pain points. Build, buy, or partner is a question you answer every year now.
The test What should we start, change, stop, or leave alone? Restraint, retirement, and the current setup are legitimate outcomes.
Mapping the enterprise AI stackThe tool curve is not the value curveControl the dependency and the receiver
The map: eleven playbooks, sixty-three topics
Topic names only. A playbook is a working document, revised as the world moves, and the depth stays in the work; the map is here so you can see the shape of what I keep returning to.
1 · Leader clarity 1 playbook · 6 topics
- The abstraction gap
- The articulation conversation
- Success criteria before solutions
- Cascading intent
- Trade-off facilitation
- Stakeholder alignment
2 · Execution architecture 3 playbooks · 16 topics
- The shift-left spectrum
- Self-heal against self-help
- Two sources of truth
- Every encounter is a checkup
- KB articles are decisions, not documents
- Action controls and content governance
- Code, configuration, and content
- The concierge model
- The support landscape
- The channel migration model
- Resolution ownership against ticket ownership
- Activity is not progress
- Adapting the plan
- Resource alignment
- Governance that enables
- Delegated action governance
3 · Measurement 1 playbook · 9 topics
- The efficiency trap
- Measuring what matters
- Steering against rearview metrics
- Closing the feedback loop
- The sampling blind spot
- Setting expectations for episodic tools
- What averages hide
- Measuring across the lifecycle
- Verification economics
4 · Adoption and utilization 1 playbook · 7 topics
- The expectation gap
- The healthcare model
- Reframing transformation narratives
- The frontline perspective
- The trust equation
- Adoption depth against vanity metrics
- The adoption curve is not uniform
5 · Recognition and improvement 2 playbooks · 14 topics
- The invisible work problem
- Recognition as signal
- Retrospectives that stick
- Capability building over time
- Failure as data
- Cross-team learning
- Apprenticeship and capability transfer
- The trust audit
- Symptom against structure
- The dual perspective advantage
- The first thirty days
- Trust infrastructure
- The narrative reset
- Stakeholder tier management
6 · Opportunity and awareness 3 playbooks · 11 topics
- Problem definition before prompt engineering
- Thinking partner, not answer machine
- Context architecture
- Choosing the right tool for the task
- The new division of labor
- Building IP as a byproduct
- Practical governance for new technologies
- The technology-ready meeting
- Listening to pain points systematically
- Build, buy, partner, or keep
- Evaluating emerging technologies
Fifty-three of the sixty-three topics are generic; ten belong to IT support, where the practice started. The map is current as of September 2026 and moves when the work does.
Where it came from, and where it went
None of this was invented at a desk. The structure was extracted from two working instances, a consulting practice and a marriage, and the fact that it moved between them without modification is the strongest evidence I have that the four tiers are natural rather than imposed. It says nothing about outcomes; that evidence is a real decision with a result, and it stays private. A third instance, a homeschool curriculum written by people who had never seen the framework, produced foundations and an identity on its own and settled rules where the questions should have been, which is how I learned the question tier is the part people skip.
The same structure runs at home, in a form that is not only mine to publish.
It is not a menu of services and it is not a maturity model. The questions never close. I use these six as a starting point; a client's decision owners test and adapt them to their own domain, commitments, and operating context. If you take one thing from this page, take the habit: name the questions before the work starts, and keep returning to them on purpose.