Week 29 Day 2: The Context Transfer Problem: What You Know but Did Not Say

Every task you delegate comes with context you have accumulated over time -- context that shapes how you would approach the work, what pitfalls you would avoid, and what shortcuts you would take. Most of that context lives in your head as intuition rather than explicit knowledge. When you delegate the task without transferring the context, the recipient has to rediscover everything you already know. That rediscovery costs time, produces mistakes, and creates frustration.

Here is the context transfer protocol I use for every significant delegation. I call it the 'If I Were Doing This' exercise. Before handing off the work, I spend five minutes writing down how I would approach it if I were doing it myself. Not a detailed plan -- just the decisions I would make and why. Which approach would I take? What would I try first? What would I avoid? Who would I talk to? What documentation would I check? What happened the last time someone did this work? The writing is important because it forces me to externalize intuitive knowledge. When I think about the task, my brain produces a compressed summary: 'just update the config.' When I write about the task, I have to unpack the compression: 'Update the config, but check the staging environment first because the config format changed last sprint, and make sure to notify the ops team because the last config change triggered a monitoring alert that caused a 2 AM page.' The gap between what I think ('just update the config') and what I write (the full paragraph) is the context transfer gap. That gap is where delegation failures live. Here is a real example. I delegated a customer migration to a senior engineer with the instruction: 'Migrate the customer data from the old schema to the new schema.' What I did not say: there are three customers on custom contracts whose data has non-standard fields that the migration script does not handle. I knew this because I had been in the meeting where the custom contracts were discussed. The engineer did not know this because he was not in that meeting. The migration script ran, corrupted three customer records, and we spent two days in incident response. Five minutes of context transfer would have prevented two days of repair.

The context transfer problem is a specific instance of what Polanyi (1966) calls 'tacit knowledge' -- knowledge that the holder possesses but cannot easily articulate because it has been internalized through experience. Polanyi's famous observation that 'we know more than we can tell' describes exactly the delegation gap: the delegator knows more about the task than they can transfer through verbal instruction alone. Research by Nonaka and Takeuchi (1995) on organizational knowledge creation identifies four modes of knowledge transfer: socialization (tacit to tacit, through shared experience), externalization (tacit to explicit, through dialogue and writing), combination (explicit to explicit, through documentation), and internalization (explicit to tacit, through practice). The 'If I Were Doing This' exercise is a deliberate externalization process -- converting tacit knowledge into explicit knowledge through the act of writing. Research by Klein (1998) on naturalistic decision-making demonstrates that experts make an average of 80% of their decisions using 'recognition-primed decision-making' -- pattern matching based on accumulated experience rather than analytical reasoning. This means that 80% of the context an expert would bring to a task is encoded as patterns that are invisible to the expert until they are deliberately externalized. The five-minute writing exercise connects to research by Luchins (1942) on 'Einstellung effect' -- the finding that simply articulating one's approach before executing it reduces fixation errors by making implicit assumptions explicit and therefore examinable.