An electrical outlet is an example of what engineers call an abstraction. You plug something in and it gets power. You don’t have to think about hydroelectric dams or nuclear power. You don’t have to think about transformers or transmission lines. You don’t even have to look behind the wall. You just plug something in to the interface and it works.

But what happens when it doesn’t work? Things unravel pretty quickly. You may have to learn about fuses and amperage. You may have to learn how wires were run through your house to understand the load on each circuit. An abstraction that usually works for you has leaked and now you have to understand how things really work. Or at least hire someone who does. But of course hiring someone is its own kind of abstraction.

I first learned about leaky abstractions from Joel on Software. He explains that engineers often end up needing to understand how their abstractions work under the surface to deal with inevitable failures. More and more, however, I realize the advice in this article is relevant beyond engineering. The world is full of leaky abstractions.

While I am not writing much code anymore I find I still rely on a huge number of abstractions. I talk to one person as a proxy for an entire team. I communicate a decision and assume everyone will follow it. I sign a contract and expect all parties to fulfill their duties. These things work most of the time which allows us to scale. But each one also fails sometimes.

Avoiding abstractions entirely is impossible. It isn’t possible to build anything great without them. There isn’t enough time in a day to talk to every member of every team. I certainly can’t review the communication between all those people to ensure decisions are being executed appropriately. And I can’t even imagine the mechanism that would allow us to navigate complex topics like the law and finance without trusting third parties.

But just because we can’t avoid abstractions doesn’t mean we have to be victims to them. Whenever you use an abstraction you have to understand the ways that it will fail. I may spend most of my time talking to a team leader but I also periodically check in with individuals directly and the team as a whole. I generally trust people are following decisions but we have periodic reviews to verify.

In my job I am sometimes asked “what keeps you up at night?” People expect me to talk about the competition or perhaps technical risk. But my answer is always the same: I worry that something on my team is going wrong and I don’t know about it.

I see this in other industries as well. People hiring public relations firms to try to tell their story only to find out that firm has its own baggage. Political campaigns that accept contributions they didn’t intend to. Businesses hiring consultants to be more efficient but disenfranchising their own leadership in the process. When politicians ask leaders “how could you not know this was happening?” I just think to myself about leaky abstractions.