Execution Speed Is a Multiplier, Not a Trade-Off

Discussions about personal productivity often split along a strange fault line. Among engineers who actively track their own bottlenecks, velocity is treated as a first-class variable. In broader social circles, the opposite view is common: speed doesn’t matter, or is even morally suspect. The most frequent objections fall into three buckets: working on the right problem matters more than working fast; time spent on any specific task is too small to bother optimizing; and thinking about productivity at all is corrosive to a well-lived life.

The first objection—that problem selection dominates execution—contains a false dichotomy. Both are multipliers. A faster feedback loop doesn’t prevent you from picking good problems; it makes you better at picking them, because you can test more hypotheses before committing. Conversely, picking the right problem gives you more leverage on every unit of execution speed you have. Tactical speed is easier to improve than strategic insight, and improving it also feeds the strategic side: rapid experimentation builds the intuition that makes you better at choosing what to work on next.

Iteration Speed Determines Whether Problems Get Solved

A concrete case in point: a project to quantify machine health across a large fleet. The effort uncovered serious and widespread issues—hosts corrupting data, performance problems that would raise tail latency by more than two orders of magnitude, often both. The findings were serious enough to justify creating a new team. But the path to that result was not linear. The first approaches were dead ends, and several weeks were spent discarding ideas that couldn’t work. The crucial variable was that each dead end could be tested and rejected quickly. At a slower pace, the problem would likely have been abandoned after a quarter or two of fruitless effort. That it remained an open problem for years suggests the dead ends weren’t obviously bad; they just required many iterations to rule out.

This is an argument for treating execution speed as a way to simulate having better ideas. Someone with superior instincts would skip the dead ends. Someone without those instincts—but with fast iteration—can cover the same search space through volume. The latter is easier to acquire, and it also compounds: faster feedback on experiments is how you build better intuition in the first place.

That same dynamic applies to written work. A small fraction of documents produce outsized impact. If a given high-risk proposal has, say, a 5% chance of success, then in expectation it takes roughly twenty attempts for one to land. If each document takes a day to write, that’s feasible. If each took ten days, the proposition becomes untenable for most positions. Velocity here is not about typing faster in isolation; it’s about making the whole loop cheap enough that long-shot ideas are worth proposing at all. A leadership team member can’t credibly advocate for a “turn off 10% of each rack to increase capacity” idea if the write-up for such an outlandish proposal costs weeks.

Where the Time Actually Goes

A second common objection is that speed on any particular task doesn’t matter, because that task is a small fraction of total time. The rebuttal is twofold. First, if several tasks each consume meaningful time, the solution is to improve each of them—not to declare improvement pointless. Second, and more importantly, people are demonstrably bad at estimating their own time allocation. As Fabian Giesen puts it, we accept that you can’t know where a program spends its time without profiling, but we don’t extend that same skepticism to ourselves. For cognitive work, the issue is acute: when you’re busy and concentrating, your own pauses don’t feel like pauses. They only become visible when you record yourself.

Take typing speed, the canonical example of something “not worth optimizing.” Tracking actual time spent reveals that typing is not a trivial share of the workday for someone who writes design docs, proposals, code, and comments. In one analysis, typing accounted for roughly half of writing time. At 110 WPM instead of a 40 WPM median, that difference alone is a nearly 1.9x slowdown on the typing portion—about 1.875x overall on writing tasks. Count the non-typing parts of the workflow, and the cumulative effect of not optimizing can be a ~10x gap on a given document. At that rate, long-shot proposals and deep technical write-ups simply don’t get produced.

Speed Changes the Character of Work

The impact of iteration speed is not linear. Crossing certain thresholds changes the mode of work altogether. When an experiment runs in a fraction of a second, you just try things—no filter, no planning overhead. When a single iteration takes seconds, you start thinking before you run, because wasting a run costs time. At minutes or hours per iteration, you plan extensively, take notes, and context-switch while waiting; mistakes become both more expensive and more likely because your attention is divided. At even larger scales, experiments require budget approval and meetings. Speed isn’t just doing the same thing faster; it’s making different kinds of work possible at all.

An example from practice: a metrics analytics project that had seen multiple proposals but no action. Everyone agreed the problem mattered, but the proposed solutions all required a dedicated team and multiple roadmap cycles. Such commitments require organizational buy-in from directors and VPs. Properly scoped, however, the project turned out to be something a single engineer could prototype in a day. That requires no committees—just one person who thinks the problem is worth a day of their time. Speed collapsed an organizational problem into a personal one, and the project got built.

Objecting to Productivity Itself

The third class of objection assigns moral weight to productivity. Working on velocity is framed as unnatural, or as a betrayal of leisure and family time. This seems backwards. Time with friends and family is easier to come by when work is done efficiently. The gains from improving velocity can be taken as leisure rather than as extra work. One senior engineer notes deliberately avoiding long hours, suspecting they work no more than the median at their company. Promotions—which velocity can help earn—mean higher pay, which buys more freedom to choose how to spend time. For people who simply find the pursuit of improvement unappealing, that’s a preference. For those who value what they do outside work, the most effective way to protect that time is to reduce the time work consumes.

A related strain of advice suggests that optimizing your own work is self-defeating because the environment controls outcomes anyway. This is more plausible the less control you have. Engineers at major tech companies have unusual latitude over their environment and their time. That’s precisely why the “antiwork” stance, sympathetic as it may be to the distribution of value created by labor, is a poor fit for people in that position. If the goal is to move the needle on something eventually, habits of deliberate avoidance formed early are hard to break later.

A Framework for Choosing What to Improve

Much of the debate about productivity suffers from a single-granularity bias. One side says “thinking is the important part, so ignore typing speed.” The more useful view is that efficiency exists on every level, from year-level strategy down to keystroke-level mechanics. Gains at the large scale are likely higher-impact, but it’s not obvious where the ROI drops off as you go finer:

  1. Thinking vs. typing: Programming isn’t just thinking—it’s thinking plus editing. Faster editing frees time for thought.
  2. Editing vs. keystrokes: Editing speed is a function of editor commands, not just typing speed. A good editor amplifies your effective speed even at the same WPM.
  3. Keystroke patterns: Not all keystrokes are equal. At high speeds, hand alternation matters—at 140 WPM, each finger has ~70 ms per keystroke, so alternating hands gives the next finger time to get into position.

Realistically, levels one through three have clear ROI. Level four is a rabbit hole where people naturally find adequate solutions. The key point is to avoid dismissing faster mechanics because “thinking is what matters,” when in practice the two are deeply coupled—editing speed and short-term memory interact, and slower editing effectively weakens your ability to hold a mental model of the code.

Why Improve at All

There are also non-pragmatic reasons to work on velocity. Mastery is intrinsically satisfying to many people. Developing skills in one domain—even one where speed seems irrelevant—gives you leverage when you move to work that matters more to you. And the process of getting better at something, whether it’s a board game, a sport with no utility, or programming, has its own value. A productivity practice built on measurement—not just aspiration—is also the only kind that works, since time perception is unreliable. The point isn’t to glorify speed or to moralize about leisure. It’s that execution speed is a lever under your control, it compounds, and it changes what kinds of work are possible to attempt.