We put that proverb on the wall early at Anthroware because we kept seeing the same thing: smart people doing work they couldn't explain. Not because they were bad at their jobs — because nobody had asked them to think it through before they started.
A meeting would get scheduled. Nobody knew why. A design direction would get picked. Nobody had written down the reasoning. A technology decision would be made. Months later, nobody could remember the context. The institutional knowledge just — evaporated.
"Have a reason for doing everything. I mean everything."
The proverb applies at every level of work. Have a reason to organize a meeting. Have a reason to attend one. Have a documented reason for a design direction, a system architecture decision, a pricing change, a hiring freeze. When someone asks you why you're doing a thing — and in this work, someone always will — you should be able to answer quickly and with conviction.
Why this is harder than it sounds
Most organizations move on momentum. Things happen because they happened before. Meetings recur because they were scheduled last quarter. Features get built because someone important asked for them once. Processes persist because nobody has stopped to ask whether they still serve a purpose.
Momentum is useful. It's also how organizations accumulate work that isn't connected to anything. When you start asking "why are we doing this?" and the answer is "we've always done it" — that's the smell of institutional debt you didn't know you were carrying.
The discipline of having a reason isn't about bureaucracy. It's not about creating approval processes or slowing things down with documentation. It's about anchoring work to intent. What are we trying to accomplish, and does this thing we're about to do actually help us get there?
What it looks like in practice
At Anthroware, we applied this proverb to meetings first — because meetings are where the disease is most visible. Before you schedule a meeting, ask: what does this meeting need to produce? If you can't answer that in one sentence, the meeting probably shouldn't happen, or you're not ready for it yet.
We applied it to design decisions. Before we locked a direction, we wrote down why. Not a dissertation — a sentence or two. "We chose this navigation pattern because our research showed users were spending too much time hunting for secondary actions." Months later, when a new designer joined and asked why the product worked the way it did, we had answers. The team could defend it, extend it, and know when to deviate from it.
We applied it to hiring. Have a reason to open this role. Have a reason to pass on that candidate. When you can articulate the reasoning, you make better decisions and you can learn from them afterward.
The test
Here's how I use it now, both at Vircho and in advisory conversations with founders: when someone on the team is about to do a thing, ask them to explain why in thirty seconds or less. Not to put them on the spot — to surface whether the work is anchored to anything real.
If they can answer quickly and cleanly, confidence increases. If they can't, it usually means one of two things: either the work isn't thought through, or it's the right work but nobody has made the case for it clearly enough. Both are solvable. You just need to know which one you're dealing with.
The absence of a reason isn't neutral. It's a signal that the work isn't anchored to anything — and work that isn't anchored tends to drift.
