I use the word "mechanism" a lot. In newsletters about action items, hiring pipelines, ticketing systems1 , first-90-day transitions1. Readers have started asking: what exactly do you mean by that?
Fair question. I've been using it as if the definition were obvious. It isn't.
The word comes from my time at Amazon, where "build a mechanism" is the response to almost every recurring problem. Not "try harder." Not "send a reminder." Build a mechanism.
It took me a while to understand what that actually meant. Once I did, I started spotting incomplete mechanisms everywhere. Including my own.
1 upcoming newsletters
The Sentence That Changed How I Think About Systems
At Amazon, every time something went wrong, the response was the same. Not from one leader. From every leader, in every room. "Build a mechanism to ensure we're never here again."
Not "be more careful." Not "pay more attention." Build a mechanism.
It wasn't a management technique. It was muscle memory. The culture had internalized it so deeply that asking for good intentions instead of a mechanism would have felt like asking someone to clap with one hand. You'd get a strange look.
The implication: if you're relying on people remembering, caring, or trying harder, you don't have a solution. You have a hope. And hope is not a strategy.
Jeff Bezos has a line that's become an adage across Amazon:
"Good intentions don't work. Mechanisms do."
When you ask for good intentions, you're not asking for change. People already had good intentions. The good intentions were there when the problem happened.
What a Mechanism Is Not
A mechanism is not a tool. This is where most people stop.
A spreadsheet tracker is a tool. A weekly review meeting is a tool. A checklist is a tool. A Slack channel is a tool. A dashboard is a tool.
Tools are necessary. But a tool sitting in a Google Drive folder, used by some people sometimes, inspected by nobody — that's not a mechanism. That's furniture.
I've built dozens of tools in my career that died within weeks. Beautiful templates. Elegant dashboards. They all had the same problem: I designed the artifact and assumed the behavior would follow. It didn't.
The action item tracker I wrote about in a previous newsletter? The spreadsheet was the easy part. What made it work was everything around the spreadsheet: the rule that you enter it during the meeting (not after), the rule that owners update before the review (not during), the fact that the meeting starts with the tracker (so skipping it means everyone notices), and the visible strikethrough history that makes date-slipping impossible to hide.
The spreadsheet was the tool. The rest was the mechanism.
The Four Components
A mechanism has four parts. If any one is missing, it degrades.
1. The Tool
This is the thing itself. The tracker, the template, the meeting format, the classification system. It transforms inputs into outputs. It needs to be specific enough that someone can use it without asking questions, and simple enough that compliance isn't a burden.
The test: Can someone new use this tool correctly on their first attempt, with minimal instruction?
If the tool requires perfection from humans, it will fail. Design for the realistic human — the one who's busy, distracted, and juggling six other priorities.
