Information is not change.
Most organizations confuse access to information with actual human development. We’ve all experienced it: another training seminar, another deck, another knowledge base that promises transformation and delivers information. People sit through presentations, nod along, maybe pass a quiz, and nothing changes. The underlying assumption is that if people just knew more, they would do differently. This is almost never true.
Yet information access does improve performance, in specific ways. A surgeon with the right reference during a rare procedure. A new employee with immediate answers to process questions. A community manager with real-time visibility into audience sentiment. The problem isn’t information systems. The problem is treating information delivery and human development as the same thing.
The kind of development that changes behavior and builds lasting capability happens through different mechanisms: challenging experiences, developmental relationships, community belonging, reflective practice. The 70-20-10 model captures this: roughly 70% challenging experiences, 20% developmental relationships, 10% formal learning. Most organizational L&D budgets invert that ratio.
Procedural knowledge should be findable, not memorized. Capability has to be built, not transmitted. Most programs confuse the two and underdeliver on both.
Knowledge externalization.
Procedural knowledge is hard to retain because it’s procedural. Flat, context-free, only meaningful when you actually need it. Trying to cram it into people’s heads through training fights the nature of the knowledge. Worse, it spends scarce training time on the part of the work that benefits least from it.
Better to put procedural knowledge where people can reach for it in context: job aids, search-friendly references, environmental cues, behavioral nudges, AI assistants. The form matters less than the principle. Design the environment so the right knowledge surfaces when context calls for it, and engaging with it in context becomes how the knowledge gets connected to practice in the first place.
That reframe is what frees training and development to do what they actually do well: develop the tacit capacities that can’t be externalized. Judgment under pressure. Reading a room. The felt sense of when to push and when to back off. The relationships that make growth possible. These exist only inside the practice that builds them. They have to be lived to be learned.
Procedural knowledge: searchable, contextual, just-in-time.
Job aids, search-friendly references, environmental cues, behavioral nudges, AI assistants. RAG systems and knowledge graphs are one expression; a well-designed checklist is another. The form matters less than the principle: don’t ask people to memorize what they can reach for in the moment.
Tacit knowledge: practiced, situated, relational.
Judgment under pressure. The felt sense of when a coaching question lands and when it doesn’t. The relationships that make growth possible. These can’t be externalized because they don’t exist outside the practice that builds them. This is where training, development, community, and mentorship matter, and where attempts to automate produce visible damage.
When the externalization runs through an AI system specifically, there’s a failure mode worth naming: AI systems need to maintain fidelity to organizational expertise. Generic AI gives you crowd-sourced answers that overwrite your hard-won institutional knowledge with generic best practices. Organizations need AI that preserves their specific, contextual expertise, which is, often, their actual competitive advantage.
Generic AI gives you what the internet thinks. Organizations need AI that preserves what they know.
Where the question got sharper.
The principle didn’t arrive whole. It got sharper at each scale, and the sharpening was usually the result of something I tried that didn’t work as expected. Four moments mattered most.
Individual scale: K-12 distance learning.
I built asynchronous, self-regulated STEM courses for 150–300+ concurrent students annually, with completion rates 15–25% above typical distance-education benchmarks. The courses themselves weren’t the work; they were the externalization that made the work possible. The actual work was one-on-one coaching, helping students develop metacognitive skills, academic advising. The content freed me to spend time on the parts that moved the needle.
When information is well-organized and accessible on demand, human capacity can focus on application, coaching, and problem-solving. This was the principle’s first articulation.
Organizational scale: UBC.
At UBC I designed learning ecosystems for 6,000–8,000 students annually across two undergraduate-development departments, during a period of organizational restructuring. Blended models that reduced face-to-face time by 60% by externalizing procedural content so human interaction could focus on application. Communities of practice as primary development vehicles, not curricula. Multi-layered mentorship. Experiential workshops grounded in 70-20-10. Cultivating the Future, the 12-chapter leadership development framework I authored, benchmarked against fifteen peer institutions.
The Jump Start Leader Training program reached 330 student-staff with 91% satisfaction. The Learning Lecture Series reached 7,000 first-years through 50+ presenters. The principle worked at scale when the externalization was rigorous and the human-delivery layer was preserved deliberately.
Development happens through community, belonging, and experience. Content delivery alone doesn’t move the needle. The systems I designed at UBC put this into practice and showed the principle could survive scaling.
The pivot: when generic AI met institutional knowledge.
During roughly 80% departmental turnover, I became the de facto institutional memory. Critical knowledge was scattered across 500+ documents with no systematic way to retrieve it. I manually synthesized this into actionable performance aids while maintaining programs for 10,000+ participants. I also piloted grassroots AI adoption, training around twenty colleagues on LLM-assisted knowledge work.
That pilot showed me both AI’s potential and its key limitation in a corporate context. Generic AI didn’t just fail to capture institutional expertise. It actively replaced it. Colleagues stopped asking the senior staff how things worked here, and started asking ChatGPT how things work in general. The answers were plausible. They were also wrong, in the specific ways that mattered most: the contextual judgments, the accumulated edge cases, the things this organization had learned the hard way.
Organizations need systems that preserve their specific, hard-won expertise. Generic AI actively undermines that by overwriting contextual knowledge with generic best practices. This is the moment the principle became a build problem.
The current practice: building from the principle.
What I’ve built since is the principle made operational. The Insight Engine (a production-oriented RAG prototype with citation tracking and multi-hop reasoning) was the architectural answer to the question I’d watched go unanswered at UBC: how do you build AI that preserves what your organization actually knows? Headwater commercialized the same infrastructure for community intelligence, where the analogous problem is preserving what a specific audience actually thinks rather than what a generic sentiment model assumes. ZKXP is where the practice now sits formally, applied to mid-market clients in regulated industries.
The position I now work from has a name: the Information Advantage Framework. Holding the gap between what is true and what is believed, and treating that gap as the asset rather than as a measurement error, is where the practice goes from here.
Technology, plus the work that doesn’t scale.
AI won’t replace human development. But it changes what humans need to spend their time on. By handling information retrieval and pattern detection, technology frees human capacity for the work that actually produces lasting change: building relationships, navigating ambiguity, creating belonging.
My work sits at this intersection: understanding what’s distinctly human about development, and building systems that handle the rest. Most people in this space have depth on one side or the other. The combination is rarer than it should be, and that’s the position I’ve worked to build.
Externalize, scale, retrieve, surface patterns.
Externalize procedural knowledge for just-in-time access. Process qualitative data at scale to surface patterns. Preserve institutional memory through transitions. Accelerate retrieval and synthesis across messy organizational corpora. Each of these compounds when the architecture preserves source-level traceability.
Belong, judge, relate, experience.
Create the belonging that enables development. Replace the judgment that navigates ambiguity. Substitute for the relationships that drive real behavior change. Provide the experience that builds tacit knowledge. Attempts to automate this layer don’t produce neutral outcomes. They produce visible damage that the metrics often miss.
Practitioner depth on both sides.
A working understanding of how adults actually develop, drawn from 10,000-participant programs. The technical capability to implement, not just recommend: to build the system, debug the integration, evaluate the vendor. And the judgment to know which problems benefit from which approach.
What I don’t claim.
The temptation in this kind of essay is to position oneself as the answer. The honest version is narrower than that, and worth stating directly so the work can be evaluated on its actual scope rather than on flattering inferences.
- Architect AI solutions for organizational problems.
- Build production RAG pipelines, knowledge graphs, and data integrations.
- Evaluate vendors and specify technical requirements.
- Translate between domain experts and engineering teams.
- Design training and change-management for AI adoption.
- Process qualitative data at scale to surface patterns.
- I’m not a traditional software engineer. My development is AI-assisted and project-driven, not CS-degree-driven.
- I don’t have formal CS fundamentals (data structures, complexity theory) at depth.
- Headwater is operating but the client base is still growing. The methodology is validated; the traction is early.
- The Insight Engine is a working system, not enterprise-hardened software.
I know enough to have good judgment about what I don’t know, which is what organizations need most when adopting AI.