Operating Principles
Why Long-Term Thinking Builds Better Businesses
Short-term decisions rarely announce their cost at the moment they are made. The bill arrives later, in a different form and usually on someone else's desk. This is how we think about the difference, and where speed is still the right answer.
Short-term decisions hide their cost
The difficulty with short-term decisions is not that they look wrong. Most of them are locally reasonable. The deadline is real, the shortcut works, and the thing ships. The cost shows up later and in a different form: a workaround someone has to remember, a page nobody can safely edit, a process that only functions when one particular person is available.
Because that cost is separated in time from the decision that created it, it is almost never attributed correctly. Whoever took the shortcut looked fast. Whoever pays for it eight months later looks slow. Nothing in the ordinary accounting of work connects the two, which is exactly why the pattern repeats.
The first discipline of long-term thinking is not refusing shortcuts. It is naming them. When a decision defers work, write down what is being deferred and what resolving it will require. A recorded shortcut is a debt with a known balance. An unrecorded one is a future surprise, and surprises are what actually damage small companies.
Systems instead of repeated fixes
A useful signal is repetition. The first time a problem appears, fix the instance. The second time, note it. The third time, the instance is no longer the problem. Something upstream is producing it, and fixing the output again is a decision to keep paying that cost indefinitely.
A concrete example from our own work: internal links that break when a page is renamed. Correcting them one at a time is quick and feels productive. It also guarantees the same afternoon will recur every time a page moves. The systemic fix is duller. Establish where links are allowed to point, keep a single list of page addresses, and check the whole site before publishing rather than after a reader complains. The first approach is faster this week. The second one ends the category of problem.
Systems have a real cost, which is why this is a judgment call rather than a rule. Building one takes time that produces nothing visible, and a system built for a problem that occurs twice a year is waste. The question is whether the problem is recurring and whether the fix is genuinely reusable, not whether building systems feels like the sophisticated choice.
Urgency and durability are not opposites
Long-term thinking is often misread as slowness, and that reading gives it a bad name it partly deserves. Plenty of deliberation is procrastination wearing better clothes. The useful distinction is not fast against slow but reversible against irreversible.
Reversible decisions should be made quickly. Wording on a page, the order of sections, which of two similar approaches to try first: these can be changed cheaply if they turn out badly, and deliberating over them wastes the time that should be spent on decisions that matter.
Irreversible or expensive-to-reverse decisions deserve the extra week. The platform an initiative depends on, a public commitment to customers, the structure of a content archive, a brand name, anything involving personal data. These are cheap to decide and expensive to undo, which inverts the usual arithmetic of speed. Sorting decisions into those two buckets before deciding how much time to spend is the single most practical habit in this article.
Institutional knowledge leaks quietly
Every project accumulates knowledge that never gets written down: why a particular approach was rejected, which supplier turned out to be unreliable, what the odd exception in the process is protecting against. This knowledge is genuinely valuable and it degrades on its own. Six months is usually enough for the reasoning behind a decision to become unrecoverable, even to the person who made it.
The result is a specific and avoidable form of waste: rediscovering things the company already knew. A rejected approach gets tried again. A solved problem gets solved differently, creating two solutions where one would do. Someone removes the odd exception because it looks like a mistake, and learns what it was protecting against the hard way.
The fix is unglamorous. Record decisions with their reasoning while the reasoning is fresh, in whatever form will actually get read. A short note explaining why an approach was rejected is worth more than a long document nobody opens. The test is not whether documentation exists but whether a competent stranger could resume the work from it.
Measuring progress beyond immediate revenue
Revenue is the eventual measure, but it is a lagging one, and steering by it alone means learning about problems long after they could have been corrected cheaply. It also rewards the wrong behavior in the short run, because the fastest way to improve this month's number is usually to defer work that protects next year's.
More useful indicators tend to describe how the operation is behaving rather than what it produced. How long does it take to publish something correctly from a standing start. How many manual interventions does a normal week require. How much of the current system could be handed to someone else. How often do we correct published work, and how quickly. Is the list of known problems growing or shrinking.
None of these are difficult to observe, and together they answer a question revenue cannot: is this becoming more capable of running without heroics, or less?
When speed is the right answer
Sometimes the fast, imperfect version is clearly correct. When the purpose is to learn whether an idea has any merit, a rough test answers the question at a fraction of the cost of a polished one, and building the polished version first is the actual waste. When a genuine deadline exists, such as a legal requirement or a fixed external date, meeting it imperfectly usually beats missing it well. When something is broken in production, the immediate fix comes first and the systemic one comes after.
Speed becomes dangerous when the thing being rushed is hard to undo, when the shortcut is invisible to everyone except the person who took it, or when the rush is habitual rather than exceptional. A company that is always urgent has stopped making a choice and started operating in a mode. That mode reliably produces the compounding problems described above.
A practical test
The question we find most useful is this: if a competent stranger inherited this work in a year, would they be able to understand it, maintain it, and trust what it claims? If yes, the pace is probably fine, however fast it felt. If no, the speed is being borrowed from the future.
Long-term thinking, in the end, is not patience. It is refusing to treat the cost of a decision as zero simply because it will be paid later. That is a habit rather than a strategy, and habits are what actually determine how a company behaves when a deadline is close.