Momentum Is a System

Execution is often framed as willpower. In practice it is a system of activation costs, energy, attention, and feedback. Small changes to that system compound into very different output.

Activation Energy

Getting started is the hardest part. Once moving, momentum takes over.

Principle

Every change requires an initial burst of effort to overcome inertia. This upfront cost is temporary, not permanent. The trick is to lower the activation energy — make the first step so small it's impossible to say no. Start with one push-up, not fifty.

When it applies

Starting a new habit or routine
Kicking off a dreaded task
Initiating a difficult conversation

Example

You've been putting off refactoring that module for weeks. Instead of planning the whole refactor, just open the file and rename one poorly-named variable. That tiny action breaks the inertia. Suddenly you're in the code and the rest flows.

Source and further reading: Mental Models: The Best Way to Make Intelligent Decisions (~100 Models Explained) by Shane Parrish.

Bias to Action

You can just do things. Don't wait for permission.

Principle

At OpenAI, 3-4 Codex prototypes existed before anyone decided to launch one. Small groups of individuals started efforts without asking permission. Teams formed around ideas that showed promise. The best orgs let people run experiments and then rally behind what works.

When it applies

When you're waiting for approval to try something small
When you see a problem nobody owns
When you have a prototype idea but "it's not on the roadmap"

Example

Instead of writing a proposal doc for a new internal tool, build a rough prototype over a weekend. If it's useful, people will gravitate to it. If not, you lost a weekend but learned something. Code wins over committees.

Source and further reading: Reflections on OpenAI by Calvin French-Owen.

Energy Compounds

Mental energy is not a tank that depletes — spending it on productive things generates more.

Principle

Physical energy depletes with use, but mental energy works differently: doing something productive creates a positive feedback loop that gives you more energy. Conversely, procrastinating and scrolling drains energy in a negative spiral. The first action of the day sets the direction. Most people fail from many days of zero output, not from failing to maximize any single day.

When it applies

Stuck in a low-energy rut or procrastination spiral
Planning your morning routine
Deciding whether to "rest" or push through

Example

You don't feel like working, so you check Twitter, which makes you feel worse, so you lie down, which makes it worse. Instead: empty the dishwasher. That tiny win sparks enough energy to write one paragraph. That sparks the next thing. Spiral reversed.

Source and further reading: Advice That Actually Worked For Me by Nabeel S. Qureshi.

Follow Up Relentlessly

People drop off even when the call went great. It's usually because they're busy, not because they hate you.

Principle

Always follow up same-day — no excuses. Then follow up every 3 days until you get a clear yes, no, or timeline. Many big deals close after 15+ follow-ups. Lags are the death of sales. Being "polite" by not following up is actually abandoning the relationship. The goal is a definitive answer, not comfortable silence.

When it applies

After any sales call, meeting, or important conversation
Waiting on a decision from a stakeholder
Networking or partnership discussions that go quiet

Example

A great sales call ends with "we'll get back to you." You follow up that evening with a short, gracious email and a clear next step. They go quiet. You follow up 3 days later. And again. On follow-up #12, they finally loop in their boss and the deal closes.

Source and further reading: How To Sell by Nabeel S. Qureshi.

Go Closer

"If your pictures aren't good enough, you're not close enough." — Robert Capa

Principle

Understanding has layers of depth — it's not binary. The student who writes about "the United States" has nothing to say; the one who starts with "the upper left-hand brick" of one building produces 5,000 words. Narrowing down destroys blockage because it forces original, direct seeing. Get first-hand data. Reason up from specifics. Popular science and news articles fill your mind with cached narratives, not your own synthesis.

When it applies

Writer's block or analysis paralysis on a broad topic
Trying to understand a complex system or domain
Evaluating second-hand information vs. primary sources

Example

Instead of reading an Atlantic article about COVID, Nabeel analyzed the SARS-CoV-2 genome directly in a Jupyter notebook. The first-hand data gave him a foundation that no summary could provide.

Source and further reading: How To Understand Things by Nabeel S. Qureshi.

Parkinson's Law

Work expands to fill the time available for its completion.

Principle

Give a task an hour, it takes an hour. Give the same task a week, somehow it takes a week — not because it was actually harder, but because the available time gets absorbed by extra deliberation, polish, procedural overhead, and low-value activity that expands to fit the slack. This applies to individuals (a report due tomorrow gets written in an evening; the same report due in a month gets written the night before the deadline anyway, after a month of vague anxiety) and to organizations (committees add members and meetings not because the work grew, but because time and budget were available to absorb).

The corollary that matters more in practice: deadlines aren't just external pressure, they're a tool for preventing work from expanding to fill unnecessary time. Cutting the time allotted for a task often doesn't reduce quality proportionally — it mostly cuts the padding.

When it applies

Setting deadlines or timeboxes for your own work — shorter, firm deadlines often produce equivalent output with less wasted deliberation
Diagnosing why a team with more headcount or more time isn't shipping proportionally faster
Budget cycles and committee structures — headcount and process tend to grow to fill whatever budget exists, independent of actual need
Evaluating "we need more time" requests — check whether more time will produce more value or just more elapsed calendar time

Example

A team is given three weeks to finish a feature that objectively requires about four days of focused work. The three weeks get consumed anyway — extra design reviews get added, more edge cases get "discovered" and debated, the deadline creeps until the last few days force the same rushed execution that would have happened if the deadline had been one week to begin with.

Pay Yourself First

If you always put meaningful work last, you'll never get to it.

Principle

There will always be more emails, meetings, and updates. You can fill an entire week with reactive work. To stay sharp, do the work that matters to you first — programming for the love of it, experimenting, researching. Solving your own problems is where motivation and competency compound into privilege.

When it applies

When your calendar is 100% reactive work
When you haven't written code / created something in weeks
When you feel your skills stagnating

Example

Block the first 2 hours of your day for deep work on something you care about — before opening Slack or email. The reactive stuff will still be there. Your creative energy won't.

Source and further reading: Pay yourself first.

Perspiration Over Inspiration

Genius is 1% inspiration, 99% perspiration. Ideas are cheap; execution is rare.

Principle

Edison's line reframes achievement as mostly grind, not gift. The spark of an idea (1%) is common — lots of people have clever insights. What's rare is the relentless, unglamorous work (99%) of iterating, failing, and refining until the idea becomes real. The romantic myth of the lone genius struck by brilliance is mostly survivorship-flavored fiction; persistence is what actually compounds into results.

When it applies

When waiting for the "perfect idea" before starting
When overvaluing your own ideas and undervaluing the slog of shipping
When comparing your messy middle to someone else's finished output

Example

Edison tested thousands of filament materials before the light bulb worked — "I have not failed, I've just found 10,000 ways that won't work." The insight (electric light) was the easy part; the 10,000 iterations were the genius. In your own work: the architecture diagram is the 1%; getting it through edge cases, reviews, and production is the 99% that decides whether it ships.

Schlep Blindness

Your unconscious mind won't even let you see ideas that require doing something tedious — the avoidance happens before you're aware you're avoiding anything.

Principle

A "schlep" is a tedious, unpleasant, unglamorous task — dealing with banks, regulators, fraud, other people's broken systems. Most people don't consciously weigh the schlep against the opportunity and rationally decide to pass; their unconscious mind filters the idea out before it's even considered, the same way most people don't consciously decide to skip becoming an Olympic athlete — the work involved is just never seriously entertained. This means the biggest opportunities often sit in plain sight for years, visible to everyone who has the problem, ignored by everyone who could fix it, simply because the fix would require enduring something unpleasant.

The corollary: ambitious ideas that involve obvious schleps are undervalued precisely because the schlep scares off competition. If you're willing to do the unpleasant part, you get less competition for the exact same reason most people won't try.

When it applies

Evaluating why an obviously valuable problem has gone unsolved for years — check whether the barrier is technical difficulty or just unpleasantness
Noticing your own instinctive flinch away from certain categories of work (compliance, sales, negotiation, cleanup) and asking whether that flinch is calibrated to real difficulty or just distaste
Idea generation — instead of "what should I build," ask "what do I wish someone else would fix for me," which surfaces schleps you've been unconsciously filtering out
Prioritization — the task everyone is avoiding is often the one with the least competition once someone actually does it

Example

Every hacker who processed payments online for a decade before Stripe knew exactly how painful it was — dealing with banks, fraud, compliance. Thousands of people had the problem and the technical skill to fix it, and instead built recipe sites and event aggregators, because the payments problem, while important, was wrapped in enough schlep that it was never even seriously considered as an option.

Source and further reading: Schlep Blindness by Paul Graham.

Shiny Object Syndrome

The new thing is exciting precisely because you haven't hit its problems yet.

Principle

The instinct to chase the newest tool, framework, library, methodology, side project, or business idea — at the cost of finishing the current one. Novelty feels like progress because it resets the difficulty curve to zero. The current project is 70% done and grinding through the hard, unglamorous 30%. The new idea is 0% done and still in its honeymoon phase where every problem is abstract and every outcome is possible.

The trap has a specific shape:

Current work hits the boring middle (integration, edge cases, polish, distribution).
A new idea appears, offering the dopamine of a blank page.
You context-switch, feeling energized.
The new thing eventually hits its own boring middle.
Repeat. Nothing ever reaches the compounding phase.

The value in almost any project lives in the last 20% — the part you only see if you push through the middle. Shiny object syndrome is the reliable way to never collect that value, on any project.

The counter isn't "never start new things." It's:

Notice the pattern in yourself (you start many, finish few).
Distinguish a genuinely better option from a more novel one — they feel similar from inside.
Finish-bias: default to completing the current thing unless the new one survives a week of consideration.
Write down new ideas in a parking lot instead of acting on them immediately. Most lose their shine within days.

When it applies

Mid-project, when the work gets grindy and a new framework/library looks appealing
Career decisions framed as "pivots" every 6–12 months
Side projects that never ship
Tech stack churn on teams
Business strategy that changes with every conference talk

Example

An engineer is 8 weeks into rewriting a service in Go. It's 80% done, ugly in places, boring to finish. They discover Rust and become convinced this is the right tool. The rewrite-of-the-rewrite begins, hits its own boring middle in week 10. Zig appears. The original service, still in its old language, still works — and is now 18 months un-replaced.

The same pattern plays out at company scale: every reorg, every pivot, every "let's rebuild on the new platform" that abandons a system still two quarters from paying off.

The honest question to ask when a shiny object appears: is the current thing actually failing, or am I just bored of it?

Closing principle

Protect the conditions that make starting easy and finishing normal. Consistency is usually an environment you build, not a mood you wait for.