i

Description

A “Hammer and Nails” hardware store (old postcard)

Source

Tichnor Brothers, Publisher · original page

Licence

PD Public domain

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

The law of the instrument

When you have a hammer, everything looks like a nail: we apply the solution we master, whether or not it fits.

In brief

• What: the tool, technology or method we master becomes the default answer, even to problems it was not made for.
• Why: the learning effort is already paid for, the familiar solution is reassuring, and the problem is reformulated so that it applies.
• Detect: the solution is named before the problem is described; nobody has compared an alternative.
• Avoid: describe the need without naming a tool, compare at least two options against written criteria, ask what would make us give up the tool.

On this page

1. Definition
2. The mechanism
3. Where it shows up
   1. In project management
   2. In management
4. Famous cases
   1. The 15,841 cases lost by a spreadsheet September 25 - October 2, 2020
   2. Gene names turned into dates 2016
5. Warning signs
6. Avoidance reflexes
7. With AI: detect, remedy, mitigate
   1. Detect
   2. Fix
   3. Mitigate
   4. Prompts to build into your routines
   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

Fictitious illustration

The law of the instrument, or “hammer effect”, is the tendency to treat every problem with the tool we know best. The philosopher Abraham Kaplan gave the formulation in 1964 in The Conduct of Inquiry: “Give a small boy a hammer, and he will find that everything he encounters needs pounding.” The psychologist Abraham Maslow popularized the version best known today in 1966, in The Psychology of Science: “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”

This is not a general rule that “tools are bad”. A mastered tool is often a good choice. The bias begins when the tool is chosen before looking at the problem, or when the problem is distorted to fit the tool. Nor is it a bias measured in the laboratory like anchoring: it is an old and very widespread observation, more than a precisely quantified effect. This entry says so in order not to make it say more than it does.

The mechanism#

Several drivers combine, all resting on the same idea: what I know how to do is more accessible to me than what I don't know.

• The cost already paid. Learning a tool, a platform, a language or a working framework takes months. Giving it up means losing that investment; using it again seems free, though it is not always (see sunk costs).
• Availability. We think first of what we know. Solutions we have never practiced simply do not come to mind when we formulate the options.
• Silent reformulation. The problem is redefined to match the tool: “we need a data warehouse” becomes “we need one more table”; “we need tracking” becomes “we need a shared workbook”. The need drifts without anyone having decided it.
• Social comfort. In a team, proposing the tool everyone knows is easy to defend. Proposing something else requires justifying, training and taking on the risk.
• Professional identity. Someone who is “the expert in” a given tool has an interest, without malice, in that tool being relevant (see expert bias).

Where it shows up#

In project management#

• The spreadsheet turned database. A shared workbook serves as a reference repository, a tracking tool and a source of reports. It works as long as the volume stays small, then the formulas, versions and permissions become unmanageable.
• The single technology. A team that knows a relational database well stores documents, message queues or time series in it. Conversely, a team enthusiastic about a recent technology applies it to simple needs that do not call for so much.
• The universal method. The same ritual (V-cycle, two-week sprints, Kanban) is applied to maintenance, to an infrastructure project, to a search for a solution, because “that's how we work”.
• The script for everything. The engineer who likes automation writes a script where a standard configuration of the existing tool would suffice, and leaves the team code to maintain.
• The service provider. A service supplier proposes, whatever the need, what it knows how to do and sell: its platform, its method, its profiles.

In management#

• The one-key manager. Coming from a technical background, they settle a team conflict with a process; coming from human resources, they settle a design flaw with a conversation. Each deals with what they know how to do.
• The dashboard for everything. Faced with a difficulty, the answer is one more indicator, whatever the problem (see Goodhart's law).
• Reorganization as a reflex. An executive who succeeded through a reorganization proposes one for every difficulty.
• Training as the answer. A flaw that stems from tooling, scheduling or workload is treated with a course, because training is the tool at hand.

Famous cases#

Warning signs#

• The solution is named before the problem is described: “we'll do that in [tool]”.
• The options presented differ only in how to use the same technology.
• The need is expressed in the tool's vocabulary (“a table”, “a workflow”, “a dashboard”) rather than in that of the use.
• Workarounds pile up: macros, scripts, manual exports to compensate for what the tool does not do.
• “We've always done it this way”, “we already have the license”, “it's what the team knows” are the only justifications.
• Nobody can say in which case the tool would not be the right one.

Avoidance reflexes#

1. Describe the need without naming a tool. Write the problem in terms of use, volume, reliability, lifespan, users. If the tool appears in the sentence, the sentence already describes the solution.
2. Compare at least two options, including an unusual one. Not to choose it at all costs, but to force ourselves to justify the choice with written criteria.
3. Set the criteria before examining the tools. Volume, lead time, available skills, maintenance cost, risk, reversibility. They weigh more than familiarity.
4. Write down what would make us give up. “We will abandon this approach if the volume exceeds X, or if we add more than Y workarounds.” A limit written in advance is easier to apply than one discovered in a crisis.
5. Put a figure on the real cost of the familiar. The license already paid for is not the cost; count the maintenance, the workarounds, the risk of silent error.
6. Bring in an outside perspective. A person who has not invested in the tool naturally asks about the alternative.
7. Keep a limit test. For any tool placed at the center of a chain, add a completeness check (number of items entered against number of items processed).

With AI: detect, remedy, mitigate#

Prompts to build into your routines#

1. Options for a need described without a tool. To use before choosing a tool or technology.

Here is a need described without any mention of a tool or technology.
Propose four families of solutions of different natures (not four variants of the same one).
For each: what it does well, what it does poorly, the volume or context beyond which it no longer fits, and the maintenance cost to expect.
Do not recommend anything: I want to compare. Do not cite a product you are not certain exists.

Need: [description: use, volume, expected reliability, lifespan, users, constraints]

2. Defending the alternative and looking for exit conditions. When the team is about to settle on the tool it knows.

Our team is about to address this need with [usual tool]: [need].
1. Give the best arguments for why a very different approach might be preferable, without caricaturing our choice.
2. List the symptoms that would indicate in six months that [usual tool] was not suitable (volumes, workarounds, silent errors).
3. Propose a simple completeness or consistency check to put in place from the start.
4. Say, in one sentence, in which cases [usual tool] remains the right choice nonetheless.

How to build them in#

• At scoping: run prompt 1 before any discussion of tools, then compare with what the team has in mind.
• Before the decision: prompt 2 feeds the “exit conditions” section of the selection file.
• In architecture review: ask to see the rejected alternative and the reason it was rejected, not only the chosen solution.

Precautions#

• Do not name the tool in your question: you would steer the answer.
• The products, versions and limits cited by AI may be wrong or outdated: check them in the official documentation.
• A list of options is not a decision: it is up to the team, which knows its skills and its context, to decide.
• Do not paste confidential data or architecture plans into an unauthorized tool.

Limits#

• This is a common-sense observation more than a precise experimental result: there is no benchmark quantified effect as there is for anchoring.
• Relying on what we master is often rational: learning cost, support, recruitment and maintenance legitimately favor the familiar. The bias is not choosing the familiar tool, it is not having compared.
• The opposite effect exists: the appeal of novelty, which leads us to ignore the suitable tool because it is old (see pro-innovation bias).
• The two “cases” in this entry illustrate the risk of the single tool; they do not prove that the teams concerned followed this reasoning. Attributing them to a bias remains an interpretation.

Sources and verification#

• Kaplan, A. (1964), The Conduct of Inquiry: Methodology for Behavioral Science, Chandler Publishing — origin of the “law of the instrument” (the formulation about the small boy and the hammer).
• Maslow, A. H. (1966), The Psychology of Science: A Reconnaissance, Harper & Row — the hammer and nail formulation.
• The Register (October 5, 2020), article on the case-counting error by Public Health England — 15,841 cases, .xls format limit.
• The Conversation (2020), “Why you should never use Microsoft Excel to count coronavirus cases”
• Ziemann, Eren & El-Osta (2016), “Gene name errors are widespread in the scientific literature”, Genome Biology — 704 papers out of 3,597.

See also#