A short story about expertise

A large ship’s engine failed. The shipping company brought in expert after expert, but none could fix it. Finally, they called in an old engineer who had spent decades working on these engines. He arrived with a small bag of tools, walked around the engine silently for some time, listened carefully at various points, and then reached into his bag and pulled out a small hammer. He tapped a single spot on the engine casing. The engine started.

When the bill arrived—ten thousand dollars—the company’s owners were outraged. The engineer had spent twenty minutes on site. They demanded an itemized invoice. He sent one: “Tapping with a hammer: $2.00. Knowing where to tap: $9,998.00.”

This parable has been circulating for decades for good reason. It captures something that most organizations struggle to price and most individuals struggle to articulate: the value of knowing exactly where to apply effort is almost entirely disconnected from the visible cost of applying it.

In software, this shows up constantly. A senior engineer who has seen a class of problem before can diagnose it in an hour. A junior engineer unfamiliar with the failure mode might spend days investigating the wrong things. The value delivered by the first engineer is not captured by measuring time on task. The diagnosis took an hour, but it drew on years of accumulated pattern recognition—systems encountered, failures studied, root causes traced. That knowledge has no visible price tag, and it rarely appears in a job title or a certification.

The uncomfortable implication is that effort is a poor proxy for value. We have strong intuitions that hard work should be rewarded and easy work should not—that twenty minutes of tapping deserves less than twenty hours of investigation. But the engineer who can solve the problem in twenty minutes has, in a meaningful sense, more expertise than the one who spends twenty hours not solving it. What we are paying for is not the time. We are paying for the knowing.

This is why investing in expertise—through mentorship, through time to read and learn, through exposure to problems outside the immediate work—compounds in ways that are hard to see in the short term and impossible to ignore in the long term. The engineer who knows where to tap did not acquire that knowledge cheaply or quickly. It arrived through years of careful attention. The question for any organization building on technical expertise is whether they are creating the conditions for that kind of knowledge to develop, or consuming it faster than it can be replenished.