What a top poker player teaches FDEs about 'will it work?'

A player who spent two decades among the world’s best at poker wrote a book about making decisions. The most memorable line in the publisher’s description is not a secret to winning but an admission: even the best decision does not always produce the best outcome.

For a Forward Deployed Engineer, that line is close to a job description.

You sit at the client’s site with incomplete data and a legacy system nobody has ever diagrammed, and the client still asks “when will it be done, and will it work?” Thinking in Bets is not a technical book, but it trains a skill few engineers are ever taught: being honest about uncertainty while keeping the client’s trust.

Who wrote it, and what does the book bet on?

The full title is Thinking in Bets: Making Smarter Decisions When You Don’t Have All the Facts, published by Portfolio, an imprint of Penguin Random House. The hardcover and ebook came out on 6 February 2018, the paperback on 7 May 2019. It is written for a general readership and was a national bestseller in the United States.

Annie Duke is more than a poker player. She was awarded a National Science Foundation fellowship to study cognitive psychology at the University of Pennsylvania, and in 2014 she co-founded the Alliance for Decision Education. The book therefore draws on both experience at the table and a grounding in psychology.

The core argument is compact. Every decision is subject to two sources of uncertainty: luck, which you cannot control, and information that is hidden from view. Duke argues that each time we decide, we are betting something we value, not only money. For an FDE, the stakes are the client’s time, your credibility and their trust in the product.

Idea one: a good outcome proves nothing

Duke names a mistake “resulting”: the tendency to equate the quality of a decision with the quality of its outcome. A good outcome may simply be luck, and then you learn nothing from it.

Picture a team that pushes a pipeline into a client’s environment without testing it on real data, and the demo still goes smoothly. The team concludes that its process works. In Duke’s terms, that is resulting: next time the data will be messier, and the process will collapse.

The reverse case is just as likely to teach the wrong lesson. Suppose the team tested thoroughly on real data and had a rollback plan ready, and then a third-party API went down on go-live day. The decision was still sound given what the team knew at the time; what failed was the part of luck outside its control.

Do not throw out an entire process because of one bad outcome.

At your next retro, draw two columns: what the team knew when it decided, and what was down to luck. Only the first column holds lessons.

Idea two: speak in probabilities, don’t promise

Duke points out that very few things have a 0% or 100% chance of happening. She treats expressing the true level of your knowledge as part of good decision-making. That level is often “not sure”, and there is nothing shameful in saying so.

A little arithmetic shows why this way of speaking helps. Instead of promising “the agent will cut ticket handling time by 30%”, write “70% chance of a 30% reduction within six weeks”.

If you make 10 estimates like that, about 7 should come true. If all 10 do, you are being too cautious. If only 4 do, you are overconfident.

The client also gets something to plan with. Knowing there is a 30% chance of a miss, they know to prepare a fallback rather than be caught off guard in week six. A log of your estimates across projects will gradually show how far your numbers can be trusted.

Idea three: find someone to challenge you before you meet the client

Duke recommends forming a “decision group”, a small group that helps make the beliefs behind a decision explicit to every member. FDEs often work alone at the client’s site, so it is easy to carry an assumption nobody has tested into the meeting room.

The method is simple: before each weekly report, ask another FDE or someone from the product team to ask you “why 70 and not 50?” If you cannot answer, the number is not ready to hand to the client.

Who should read it, and how?

The book suits FDEs who have to write progress reports for clients, and software engineers who want to move into FDE work, because this is a gap that software engineering rarely forces you to fill. Do not look here for eval recipes or statistical techniques; its value for FDEs lies in the mindset that lets you use those tools honestly.

Read it before your next project. After each idea, apply it straight away to a real decision that week. For your career: when an interviewer asks about a project that failed, separate the decision clearly from the luck.

That kind of answer shows the interviewer you know where to draw the lesson, rather than shifting blame or praising yourself. On a CV, a line such as “produced probabilistic forecasts for deployment timelines and tracked their accuracy across projects” carries more weight if you state the actual number of projects you tracked.

Clients do not pay you to be right every time. They pay you to say clearly what you are betting on, and what the odds of winning are.