i

Description

Apollo 13 mission control and the “mailbox”

Source

NASA · original page

Licence

PD Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

Functional fixedness

Something known to serve X is hard to see as serving Y, even when Y is exactly what is needed.

In brief

• What: we only see an object, a component or a method in the function for which we know it.
• Why: the usual use is the first to come to mind and hides the object's other properties.
• Detect: we are stuck although the “ingredients” of the solution are right in front of us; “it's only good for that.”
• Avoid: describe things by their properties, change vocabulary, list possible uses, ask a non-specialist.

On this page

1. Definition
2. The mechanism
3. Where we encounter it
   1. In project management
   2. In management
4. Famous cases
   1. Apollo 13 and the “mailbox” April 13-17, 1970
   2. The candle problem 1945
   3. The Shuar of Ecuadorian Amazonia 2005
5. Warning signs
6. Avoidance reflexes
7. With AI: detect, remedy, mitigate
   1. Detect
   2. Fix
   3. Mitigate
   4. Prompts to build into your practice
   5. How to build them in
   6. Precautions
8. Limits
9. Sources and verification
10. See also
    1. Combines with, or reinforces
    2. Related biases
    3. Counterweights and related reflexes

Definition#

Fictitious illustration

Functional fixedness is the difficulty of using an object in any way other than the function for which we know it. The German psychologist Karl Duncker described it in On problem-solving (1945), based on experiments carried out in the 1930s: an object whose usual function has just been used becomes harder to perceive as an element of another solution.

The problem remains famous as the candle problem: a participant is given a candle, a box of thumbtacks and some matches, and is asked to fix the candle to the wall so that the wax does not drip onto the table. The solution is to empty the box, tack it to the wall and place the candle on it: the box serves as a support, not as a container. Many participants do not see this, because the box is presented to them full of tacks: it “is” a container.

The mechanism#

• The functional label. An object is memorized together with its function (“a box of tacks”). It is this label, more than its shape, material or dimensions, that comes to mind.
• Recent use takes the place. As soon as an element has just been used for one function, it is “taken”: reassigning it takes an effort that we do not make as long as another lead is available.
• The framing of the problem. The way the problem is posed already points to the tools to use, and we search within that space, instead of going back to the properties of what we have.
• Expertise as a filter. The better we know a tool, the more entrenched its standard uses are; the expert is sometimes more affected than the novice (see the law of the instrument, or hammer effect).

Where we encounter it#

In project management#

• Technical problem solving: a system feature is seen as “only for X”; we do not think of using it for Y (a message queue as a log, a free-text field as an extension, an export as an interface).
• Component reuse: a module built for one use is never considered for another similar need, and a new one gets written.
• Data: data collected for billing is not imagined as material for analyzing quality or usage.
• Tools: a ticket-tracking tool is seen only as a ticket tool, not as the basis for a decision log, a knowledge base or a dashboard.
• Crisis management: running short of resources, the team looks for the intended tool, not for what in the environment could do the job.
• Design: we reuse the solution we have already used for a similar-looking problem, without asking whether another function of the same tool would be simpler.

In management#

• Assigning people: a colleague is “a tester” or “a support agent”; we do not see that they could run a workshop, train others or lead a topic, because their job title confines them.
• Roles and meetings: the steering committee is for steering, the retrospective for looking at the past; we do not imagine using them differently, even when they no longer meet the need.
• Budgets and spaces: a training budget “is only for courses”; a meeting room “is not a quiet place to work.”
• Work organization: a process designed for one situation is applied as is to another, instead of keeping only its intent.

Famous cases#

Warning signs#

• “It's only good for that,” “it wasn't made for that.”
• The problem is stuck although, in everyone's opinion, we have the necessary resources.
• The discussion revolves around what the tool is (its name, its category) rather than what it does.
• We buy or develop a new tool when an existing one has the required properties.
• A newcomer or a non-specialist proposes within two minutes an idea nobody had considered.
• The solution is “obvious” once it has been found.

Avoidance reflexes#

1. Describe by properties. Replace “a box of tacks” with “a small, rigid, flat container that can be fixed to a wall.” Do the same for a module, a table or a meeting: what they do, not what we call them.
2. List before searching. Take inventory of what is available (tools, data, people, time), then ask “what else could each element do?” before looking for the solution.
3. Reframe the problem. Move from “how do we do X with Y?” to “what is the function to achieve?” The more abstract the need, the more possible solutions there are.
4. Change vocabulary. A trade term confines: using the vocabulary of another field or a neutral word loosens the frame.
5. Ask a non-specialist. Someone who has never used the tool is not hampered by its official function.
6. Look for repurposed uses. Find out how others have repurposed the same tool; the user community has often found some.
7. Take a break. After getting stuck, switching activity and then coming back often allows a fresh start from another representation of the problem.

With AI: detect, remedy, mitigate#

Prompts to build into your practice#

1. Redescribe resources by their properties. When you are stuck although, in principle, you have everything you need.

Here is a problem: [description]. Here is what we have: [list of tools, components, data, people, constraints].
1. Redescribe each element by its properties and capabilities, without using its name or its usual function.
2. For each one, give three unusual uses that could help solve the problem.
3. Combine two or three elements to propose five solutions, from the most conventional to the boldest.
4. For each solution, indicate the constraint or risk that could make it unworkable.

2. From problem to function. To get away from the solution you had in mind.

My problem is worded as follows: [wording]. It probably contains an implicit solution.
Reformulate it at three increasing levels of abstraction, more and more focused on the function to achieve (“enable ... to ...”).
For each level, name very different families of solutions that would meet it, including solutions with no technology or no new tool.
Do not assume that my current tools must be kept.

How to build them in#

• When stuck: run prompt 1 before calling a meeting, then discuss the leads as a team.
• At the start of a project: prompt 2 avoids starting from the usual solution.
• In a workshop: project the AI's results and have people vote on feasibility.

Precautions#

• AI sometimes suggests uses that do not exist or do not work; test before committing.
• Do not paste internal architecture, data or customer information into an unauthorized tool.
• It can itself be “fixated”: if you give it the solution you have in mind, it elaborates on it. Describe the need before the solution.

Limits#

• The candle experiment has become a symbol of creativity, but its results concern an artificial task and small samples; links to professional creativity are plausible, not demonstrated.
• Replications are numerous but their magnitude varies, and the literature still debates what causes the effect (presentation, experience, instructions).
• A conventional use has good reasons to exist: repurposing a tool can introduce risks (maintenance, security, support). Functional fixedness is a problem when it prevents us from considering, not when it leads us to choose the standard use after examination.
• The Apollo 13 story is known largely through testimonies and reconstructions; the 19-step procedure is held in the NASA archives.

Sources and verification#

• Duncker, K. (1945), “On problem-solving” (translated by L. S. Lees), Psychological Monographs, 58(5), no. 270.
• Adamson, R. E. (1952), “Functional fixedness as related to problem solving: A repetition of three experiments,” Journal of Experimental Psychology, 44(4).
• German & Barrett (2005), “Functional fixedness in a technologically sparse culture,” Psychological Science, 16(1)
• NASA, Apollo 13 Flight Journal — the “mailbox” (CO₂ adapter)
• Lovell, J. & Kluger, J. (1994), Lost Moon: The Perilous Voyage of Apollo 13, Houghton Mifflin.

See also#