DEEP READING · READ 921
The Effective Engineer · Edmond Lau · 2015
What actually separates engineers is not who codes faster or who stays latest, but how much leverage the hour was spent on — and leverage is something you can deliberately choose, amplify, and compound day after day. The book treats one disease: working hard on things that do not matter, and mistaking exhaustion for contribution.
Edmond Lau is a Stanford CS graduate who worked on search quality at Google, then at Ooyala, then as an engineering lead at Quora, then at Quip. This self-published 2015 book combines his own mistakes with a large set of interviews with engineers and engineering leaders at Facebook, Google, Dropbox, Etsy, Instagram and Twitter. Intellectually it is Andy Grove's High Output Management rewritten for the individual contributor — Grove asked how a manager raises the output of an entire organisation; Lau asks how an engineer with no reports raises the output of a single hour, and he inherits Grove's central tool, leverage, more or less intact. It is not a book about engineering. It is a book about where to point your engineering.
Start with the word. A lever is a crowbar: pick the fulcrum well and the same effort moves a rock fifty times heavier; pick it badly and you can break your fingers without shifting anything. Lau writes it as a ratio: leverage equals the impact something produces divided by the time you put into it. Note that the denominator is time — not difficulty, not lines of code, not how tired you are. That single choice sets the book's entire posture: effort is not the numerator. Effort is the denominator.
Once you have the ratio there are exactly three ways to raise it, and no fourth:
Why it matters: it dismantles the engineer's favourite consolation. "I had an incredibly busy week" is, in this equation, a pure statement about the denominator and carries no information at all. Lau's observation is that most people are not insufficiently diligent; they are diligent on a curve that stopped paying years ago — running the same deploy by hand every day, fixing an edge-case bug nobody reported, polishing details on a project that may well be cancelled.
| Low leverage (looks busy) | High leverage (looks idle today) | |
|---|---|---|
| Typical act | running the release by hand; fixing bugs nobody filed; fully implementing a feature nobody has committed to | scripting the release; cutting the build from 10 minutes to 1; shipping the smallest thing that tests the premise |
| Shape of the payoff | one-off; ends when you stop | collected daily, and scales with team size |
| Visibility to others | high (there are PRs and hours) | low (saved time appears in no report) |
| Cost of failing | a few days wasted | a few days wasted, plus a definite answer that this was the wrong direction |
Whether the same hour lands in the left column or the right one is the only question this book cares about.
How it changes your seeing: you stop being impressed by busyness and start being sensitive to whether finishing this thing makes tomorrow cheaper. Which carries an uncomfortable corollary: when something's leverage is durably zero, doing it beautifully only makes the loss more elegant.
Lau's second move pulls the lens back from this week to this decade: early in a career the highest-leverage output is not code, it is an increase in how fast you learn — the one quantity that compounds. Compounding here is concrete: what you learn today makes every task tomorrow slightly faster, and the time that frees up can go back into learning. What grows is the slope, not this period's number.
From this he derives a counter-intuitive and very usable criterion: when choosing where to work, don't ask what you can produce there; ask what the learning rate is. His dimensions run roughly: is the company growing fast (growth creates new roles and new problems, and pushes people upward); are there people around who are better than you; are the codebase and documentation open enough to read; how fast does it ship (fast release cadence means more feedback means faster learning); how much autonomy will you have; is there any real onboarding or training. Note that none of these is compensation, and none of them is title.
He is equally concrete about mechanism: schedule learning formally (the Google-style twenty-percent time, where the point is not the percentage but that it must be fixed and immune to being eaten by the ticket queue), read the source of the core abstractions your team relies on, write more code, attend internal tech talks, get your designs reviewed by people who will push back. Underneath sits Carol Dweck's growth mindset — the belief that ability is trainable rather than fixed, which makes failure read as "haven't learned this yet" rather than "am not able." (That construct has run into serious replication problems, dealt with honestly below.)
How it changes your seeing: it swaps the question "is this job worth taking" from "what does it pay" to "what will I be capable of in a year." For an early-career engineer that is close to a change of valuation model — you start running yourself as an appreciating asset rather than as labour rented by the hour.
Here Lau borrows Stephen Covey's grid, which sorts work along urgent/not-urgent and important/not-important. Everything of interest sits in the second quadrant: important but not urgent. Tests, refactors, docs, automation, hiring. Its defining property: skip it today and nothing happens; skip it for a year and everything happens. Urgent work arrives with an alarm attached; important work does not — so anyone without a defence loses the whole year to the alarms.
His handles are almost suspiciously plain, but each maps to a real mechanism:
How it changes your seeing: you realise prioritising is not a list you settle once, but an action you repeat. Lau's version is to make re-prioritising itself routine, because the environment moves every week and last week's top item is usually no longer it.
This is the most operationally useful chapter in the book. Iteration speed is how long the loop takes from an idea to feedback on that idea. Lau's claim is that it is not one optimisation among many but a meta-lever, because everything you do afterwards has to pass through that loop.
The arithmetic makes it obvious. If validating a change takes ten minutes — build, deploy, click through by hand — you get twenty or thirty attempts in a day. Compress it to thirty seconds and you get hundreds. Twenty times faster is not just time saved; it changes how you work, because once trying things is cheap you switch from "think it through, then act" to "act in order to think it through," and the second is almost always faster when the requirements are uncertain. The reverse also holds: when every validation is expensive, people instinctively try less, batch up changes, and ship one enormous commit — which raises the odds of breaking something and the cost of finding out, a feedback loop where slower makes you more cautious and more caution makes you slower.
The corresponding investments: continuous deployment (Etsy became famous for deploying dozens of times a day, and Facebook built a culture on very high release frequency), building internal tools that save time, shortening the debug-and-verify loop (can you run only the relevant tests? can you reproduce production data locally?), and genuine fluency in your own environment — editor, keybindings, shell, debugger. That last one is easy to dismiss as trivia, but the sums are blunt: an operation you perform hundreds of times a day, made one second faster, is tens of hours a year. Lau also flags a bottleneck engineers habitually ignore: the delay is often not technical at all but waiting on approvals, designs, or another team's endpoint — non-engineering bottlenecks that eat iteration speed with nobody assigned to fix them.
How it changes your seeing: the next time you complain that a process is slow, first count how many times you will run it this year. If the answer has three digits, fixing the process is not a distraction — it is the job.
The book's third part handles how you know that what you are building is right, using two handles: measurement and early validation.
The first lesson about measurement is not "instrument more," it is pick the right single metric. Lau's test is whether the metric drives the behaviour you want. Take the standard contrast: measure registered users and the team will optimise the signup funnel, even if those people leave the next morning; measure weekly active hours and the same team turns toward retention and actual product value. A metric is not a thermometer, it is a steering wheel: what you measure is where the team drives.
The necessary other half is Goodhart's law: when a measure becomes a target, it ceases to be a good measure. The mechanism is that people optimise the number rather than the thing it stood for — evaluate by lines of code and you get verbose code; evaluate by tickets closed and you get tickets sliced thinner. So Lau also insists on scepticism about the data itself: verify the instrumentation, the definition and the sampling before trusting any conclusion. And he recommends internalising a handful of magnitudes — what a memory reference, a disk seek, a cross-datacentre round trip each cost — so you can rule a design out at the whiteboard instead of discovering after implementation that it is three orders of magnitude too slow.
The validation half is harsher: anything you can test with a day's work should not be built for a month first. Minimum versions, prototypes, A/B experiments, staged rollouts, doing it manually before automating it. What all of these fight is the engineer's signature failure mode — treating "we have already put in three months" as a reason to continue (sunk cost), rather than treating "three months and nobody uses it" as a reason to stop.
How it changes your seeing: you split "done" from "right," assume by default that your first version is wrong, and go shopping for the cheapest possible correction.
Software projects overrun almost universally, and Lau refuses to leave it at "people are optimistic." His decomposition:
The point worth nailing down is the ninety-percent-done fallacy: a project that reports ninety percent complete will typically consume roughly as much time again. The mechanism is no mystery — the first ninety percent is the known coding, and the remainder is integration, edge cases, migration, performance, rollout and rollback plans, plus everything discoverable only in production. Which is precisely the unestimatable part. So "we're ninety percent done" actually means: the known part is finished and the unknown part has not started.
The last part deals with the longest timescale, and the one most often skipped.
Quality, held pragmatically. Lau argues neither for perfect code nor for shipping whatever runs. He treats technical debt as actual debt: borrowing is legitimate — cutting corners to hit a window is often correct — but you have to know the interest rate (the extra time every future change costs) and set a repayment schedule. Debt you don't repay does not disappear; it becomes a tax levied on every change you make from then on. The quality practices that scale go with it: code review (whose main value is circulating knowledge and standards, not only catching bugs), automated tests (moving "don't break things" off people and onto a system), and genuinely good abstractions — the value of something like MapReduce for distributed computation is that nobody after you has to solve that problem again.
Minimise operational burden. The principles are do the simple thing first, fail fast, and automate rather than relying on discipline. Failing fast deserves spelling out: make errors blow up loudly, early, and as close to their source as possible, instead of being swallowed so that bad data flows downstream — a system that crashes ten minutes early is a hundred times cheaper than one that shows symptoms three days later. Instagram famously supported enormous user growth with a tiny engineering team by deliberately keeping the stack boring: every component you add is a permanent on-call rota you are scheduling for your future self.
Investing in your team is the highest-leverage thing an individual can do. Hiring the right person; compressing onboarding from a month to a week (Facebook's Bootcamp, and the practice of having new engineers ship to production in their first week, are both this idea); writing the doc that stops the question being asked again; turning an incident into a blameless postmortem — where blamelessness is the load-bearing design choice, because only when telling the truth is safe do you get the real causal chain and any chance of fixing the systemic cause. These carry the highest leverage in the book, because the numerator is no longer your output but everyone's output from now on.
The book is one chain in three segments:
What it establishes: the variance in engineers' output is driven less by technical skill than by choice. On what evidence? Honestly — a clear analytic frame plus a large body of industry cases and interviews, not controlled studies. The book's value is not that it discovered anything, but that it compresses a judgement usually transmitted by osmosis from senior engineers, and usually bought with five years of mistakes, into a ratio you can carry in your pocket.
Misreading one: high leverage means less work, or shortcuts. The opposite. Nearly everything the book calls high leverage — building tools, fixing process, mentoring, running postmortems — is extra work that produces nothing today and is hard for anyone to see. Leverage is about moving the fulcrum under the same effort, not about spending less effort.
Misreading two: this is a productivity-tips collection. The tips are packaging. The core is an ordering of values: ask whether it is worth doing before asking how to do it fast. Read it as a keyboard-shortcut manual and you skip the only chapter that matters.
Objection one: leverage cannot actually be computed. This is the real methodological weakness. Impact is not quantifiable in advance, only in hindsight, so the formula degrades easily into post-hoc rationalisation: what worked was high leverage, what failed was a misjudgement. In practice it functions as a question to ask, not a criterion to calculate. Used as a formula it disappoints; used as an interrogation it pays.
Objection two: heavy Silicon Valley specificity and survivorship bias. The sample is fast-growing Bay Area companies between roughly 2010 and 2015. Advice like "optimise for learning rate" and "move to a faster-growing company" presumes abundant funding, open headcount and a fluid job market. In an organisation that is not growing, or a market where jobs are scarce, your leverage ceiling is set by the org chart rather than by your judgement. The book barely engages with this.
Objection three: strongly individualist, and silent on power. "Re-prioritise regularly" assumes you decide what you work on. In reality a great deal of low-leverage work is assigned; and how to influence that assignment — managing upward, arguing for resources, moving cross-team work without authority — is exactly the territory of The Staff Engineer's Path and Staff Engineer, and exactly this book's blind spot. It teaches you to choose well within a given set of options; it does not teach you to enlarge the set.
Objection four: the growth mindset it leans on has replication problems, and this should be said plainly. Dweck's construct has been through hard scrutiny over the past decade: large meta-analyses find only weak correlations between mindset and academic achievement, and intervention effects far smaller than the popular telling implies. A subsequent very large national trial did detect real effects, but small ones, concentrated among lower-achieving students. The defensible conclusion is that it is a mild and useful adjustment of attitude, not an engine that returns large gains. The book's use of it is casual borrowing from pop psychology, and worth discounting as you read.
Objection five: highly derivative, thin on original contribution. Leverage comes from Grove's High Output Management, the quadrants from Covey, minimum viable versions and validation from the lean-startup lineage, and the estimation problems were settled in The Mythical Man-Month. Its contribution is compression and translation — taking material scattered across management, psychology and startup methodology and rendering it in language an individual contributor can use on a Tuesday. That value is real, but the reader should know they are reading an excellent synthesis, not original research.
Objection six: parts of it have dated. Written in 2015, before a decade in which tooling, deployment and collaboration all shifted substantially, and before large language models entered daily development. The equation and the mindsets still hold; you will need to supply newer examples yourself.
1. Leverage = impact produced ÷ time invested. The denominator is time, so "I worked really hard" can only make the ratio smaller.
2. There are exactly three ways to raise it: do the same thing faster, produce more value in the same hours, or switch to something more worth doing. The third is the strongest and the least used, because it requires admitting the current task isn't worth it.
3. Efficiency is doing things fast; effectiveness is doing the right things. An exquisitely engineered feature nobody uses scores full marks on the first and zero on the second.
4. Early in a career the highest-leverage output is not code but an increase in your rate of learning — the only quantity that compounds, and it grows the slope, not this quarter's number.
5. Nobody schedules the important-but-not-urgent quadrant for you: urgent work arrives with an alarm, important work doesn't. Ignore it for a year and it comes back with interest.
6. Iteration speed is the meta-lever. Getting validation from ten minutes down to thirty seconds doesn't just save time; it moves you from "think it through, then act" to "act in order to think it through."
7. What you measure is where the team drives — a metric is a steering wheel, not a thermometer; and remember Goodhart's law: once a measure becomes a target it stops being a good measure.
8. "Ninety percent done" really means: the known part is finished, and the unknown part hasn't started. The remaining tenth is integration, edge cases, migration and rollout — precisely the unestimatable part.
9. Technical debt is real debt. Borrow if you like, but know the interest rate and schedule repayment; debt you never repay becomes a tax on every future change.
10. Personal leverage has a ceiling, so the endgame is putting leverage where it survives you: automated systems, written-down knowledge, blameless postmortems, and a team stronger than the one you joined.