David Epstein's Range: why generalists suit forward deployed engineering

In its review of 14 February 2019, Publishers Weekly wrote that anyone without 10,000 hours to devote to a single skill still has reason for hope. Many FDEs need to hear that. They know enough about data, APIs, infrastructure and talking to customers, but in none of those areas do they go as deep as someone who does only that one thing.

The book is Range: Why Generalists Triumph in a Specialized World by David Epstein, published by Riverhead Books. The hardcover, ebook and audiobook came out on 28 May 2019; the paperback followed on 27 April 2021.

It was not written for FDEs. But it gives you a vocabulary for explaining why breadth is a real capability, and for choosing what to practise next.

What does the book actually argue?

Penguin Random House sums up the central claim in one sentence: among top performers, early specialisation is the exception, not the rule. On his own site, Epstein writes that generalists often find their path late, juggle many interests at once, and are the ones who hold the advantage in complex, unpredictable fields.

The image running through the book is the pairing of Tiger Woods and Roger Federer. Federer played many sports before concentrating on tennis, and according to Wikipedia’s summary, Epstein found that the stories of successful people tend to contain more “Rogers” than “Tigers”.

Publishers Weekly also notes that the book does not entirely dismiss the value of specialisation. So read Range as a lens on your work, not as a call to abandon depth.

Idea one: deployment is a “wicked” environment

Yevgeniy Brikman, an engineer who reviewed the book, concluded that most of the things we want to be good at sit in “wicked” learning environments. There, deliberate practice alone is not enough; you need breadth.

Picture two tasks in the same week. The first is writing a data transformation function that already has a test suite. You run the tests and see red or green at once; the rules are clear.

The second starts with a customer saying they need their dashboard to run faster. Three weeks later you discover the real problem lies in the data-entry process of a department nobody invited to the meetings.

The first thing to do on site is separate these two kinds of work. Follow the playbook for the rule-bound parts and automate them. For the wicked parts, resist the urge to believe you understand the requirement; design a small experiment to test it.

Idea two: what you carry to a new customer is a way of thinking, not knowledge

If the generalist’s advantage lies in unpredictable fields, the practical question for an FDE is what that advantage looks like on the job. The most plausible answer: the ability to carry a lesson from one customer to the next.

Imagine the same lesson travelling through two engagements. At a hospital, the data specification says the “discharge date” field is always populated. When you trial the pipeline, you find many records left blank, because nurses only enter the date at the end of their shift.

That is a raw observation, and it holds only for that hospital. The next step is to distil it into a sentence with no proper nouns: “a data specification describes intent, not reality; to learn the reality, ask who enters the field and when.”

Six months later you move to a bank. Different table names, different systems, but in the first week you profile the fields the specification calls mandatory, before writing a single line of transformation, and you ask exactly those two questions. A problem that took a full week to surface at the hospital is now one item on a day-one checklist.

Breadth is valuable only when you can distil it into sentences like that. Take two FDEs who have each worked with five customers: the one who records patterns brings five lessons to the sixth customer; the other has only five stories.

Idea three: try the FDE role the way you would try a relationship

The book’s argument about changing careers rests on “match quality”, which economists define as the degree of fit between a job and the person doing it.

Commoncog stresses that exploration is one of the main benefits of learning, not a side dish for fun. With few chances to sample, many students rush down a narrow path before knowing whether it suits them.

Shelf Awareness observes that this search for fit is precisely what late bloomers who succeed have in common. Brikman puts the advice more practically: treat university and your first jobs like dating, test and learn rather than plan and execute.

Suppose you are a backend engineer weighing the FDE role. Instead of analysing it, you run a four-week experiment. In week one, sit in on a technical meeting with a customer; in week two, build a demo for someone who cannot code; in week three, take an escalation ticket from a customer; in week four, shadow a colleague through an onboarding session.

After each task, write exactly three lines: whether you felt energised or drained when it was done, whether the ambiguity made you curious or frustrated, and whether you wanted to solve that particular customer’s problem or go back to building something shared. Those three lines are a way to measure your own match quality, in exactly the sense of “degree of fit” defined above.

At the end of the month, reread the twelve lines. If most lean towards energy and curiosity, ask your manager about an internal move or start applying. If most say drained, that is also a good result: you have avoided a narrow path before going too far down it.

When you write your CV, present range as evidence, not a list of keywords. A line such as “worked in three different data contexts and derived one shared process for checking source data” is more persuasive than ten technologies lined up side by side. When reading job descriptions, words like “ambiguous” or “customer-facing” signal that the work belongs to a wicked environment.

Who should read it, and in what order?

The book suits engineers with two to eight years of experience who are torn between going deeper in one area and moving into a hybrid role such as FDE. It also suits working FDEs who need language to explain their value to managers.

Read according to what you need to do. If you want the general argument, start with the Tiger and Roger example; if you are about to plan an engagement, the idea of wicked environments is immediately useful; the idea of match quality is worth saving for when you are considering a change of role.

If you are short of time, read the Commoncog summary and Brikman’s review first, then decide whether to read the whole book.

Three common mistakes when bringing Range to work

The first mistake is treating the book as a licence not to go deep in anything. The hospital and bank example above works only because you were deep enough to profile the data and write the transformations; breadth stands on a solid technical foundation, it does not replace it.

The second is treating everything as wicked. Bringing experiments and open questions to parts that already have a test suite only slows the engagement down. The third is moving through many customers without distilling a single abstract statement, so that in the end you only have more stories.

Range will not teach you to deploy any system. But once you have read it, you will find it hard to see the ambiguous weeks on a customer site as failure, because those are the weeks that build your range.