The Effective Engineer: one division that helps FDEs choose when the client's list is too long

The Goodreads description of the book makes a bold promise: the best engineers can produce 10 times the impact of others without working 10 times the hours. If you have 12 client requests this week and time for only 4, the most valuable question is what creates that gap.

Edmond Lau’s answer in The Effective Engineer, published in March 2015, comes down to one word: leverage. The book’s official site defines it as the value created per unit of time invested, and the book, about 250 pages long, is built around that framework.

It is written for software engineers in general, so you have to translate it to FDE work yourself. Try placing it in a week at a client site: the person sending the requests sits right next to you, everyone says their task is urgent, and the decision about what comes first is yours.

Why is one division worth a whole book?

Lau is very consistent on this idea. In a 2015 interview with Glitch, he advised prioritising work that creates a large impact relative to the time spent. Two years later, on Intercom’s podcast, he still defined leverage the same way: how much impact you create with the time you put in.

Imagine you are in week 3 of a 12-week engagement, deploying a records-processing system for a client. Each day brings 300 records, and 30% need manual correction, which makes 90 records. Three tasks are waiting, and the figures below are hypothetical estimates in a single unit: hours saved by the end of the engagement.

Task	Hours invested	Hours saved	Leverage
A. Change the report format for the department head	3	0	0
B. Script to check for the input files that break every week	8	4 hours × 9 weeks = 36	4.5
C. Fix the bug behind half of the manually corrected records	16	3 hours × 45 days = 135	about 8.4

Row C assumes 45 fewer records a day, at 4 minutes each. Both B and C are calculated as if the fix took effect from the day work starts. The task that takes the most hours has the highest leverage, while the one most likely to earn a thank-you comes last.

The figures need not be precise, because they serve only to set the order. But try making them wrong: if C’s hours saved are only half the estimate, its leverage falls to about 4.2, below B’s 4.5. A stays last however you estimate the hours invested, because it saves no hours at all.

The order of B and C therefore depends on the assumption of 45 records and 4 minutes. Before committing 16 hours, count how many of today’s 90 manually corrected records were caused by that exact bug, and time a few of them.

Leverage at a client site has an expiry date

Apply Lau’s division to an engagement with an end date and you see something more. Take the same task B: started in week 11, it has only 1 week left to pay back, with 4 hours saved for 8 hours invested, and its leverage drops to 0.5.

Task C also falls to about 0.9: 3 hours × 5 days = 15 hours saved for 16 hours invested. In practice it is lower still, because the 8 to 16 hours of building eat into that same final week. Late in an engagement, the task worth doing may no longer be a fix but handover documentation that lets the client’s team handle the problem themselves.

In the other direction, if script B can be reused at the next client, the denominator stays the same while the numerator grows. So before you write anything, ask how long it will live after the day you leave.

Three ideas worth keeping

The first idea is to look for points of amplification rather than to do more. Lau describes effective engineers as people who seek out the points that can amplify the effort they put in. At a client site, before accepting a request, ask whether there is a way to reach the same result with a fraction of the hours.

The second idea is a shared metric for saying “not yet”. On Intercom’s podcast, Lau advises tying priorities to the team’s mission and a shared metric, so that everyone aims at the same number, whatever their speciality.

In the example above, the metric could be the share of records needing no manual correction: task C moves it from 70% to 85%, while task A does not move it at all.

Settle this metric with the client in the first week, because then saying no is no longer just your personal opinion. Even so, do not apply it mechanically: if that department head has a say on go-live day, 3 hours on task A are still worth spending. Treat them as the cost of keeping the relationship, cap them at exactly 3 hours, and do not mistake them for high-leverage work.

The third idea is to put hard work in your best hours. Lau advises reserving your highest-energy hours for the high-leverage tasks you tend to put off.

Task C is exactly that kind: 16 hours of focus with no immediate thanks from anyone, so meetings and messages can easily swallow it. Keep your mornings for it and push client meetings to the afternoon.

Who should read it, and in what order?

The book suits best the person who is busy all day yet by evening cannot say what they changed. Engineers about to move from SWE to FDE should also read it, to practise organising their own work before their first day at a client site.

The official site calls it required reading for many teams and promises to accelerate your career, but the more reliable test lies in your own task list.

According to one reader’s summary, the first part of the book covers how to prioritise work and projects: read that part first, score your open requests, and only then move on.

Each chapter ends with a summary of habits you can adopt straight away. Use those pages as a checklist at the start of each engagement, and pick just one habit at a time.

Nor should you expect the division to do all the work. It can rank the tasks you already know about, but identifying the client’s real problem still has to come from discovery.

Turn it into a story for job applications

A book title on a CV does not show that you know how to choose work; a decision backed by numbers does. So leave the title off your CV and write one line with all three parts: the task you chose to do, the task you set aside, and the metric that changed.

When reading a job description, look out for phrases such as “ambiguous priorities” or “multiple stakeholders”, then prepare exactly one example structured like the table above. If you are not yet an FDE, you can practise right now on your current team’s backlog.

The next time someone at the client messages you with “this one’s quick”, you will have a better question than “when do you need it?”: what does it create, in the weeks that remain?