Books › Support Engineer roadmap
Best books for Support Engineers
A troubleshooting-first list. It begins with systematic debugging, the Linux shell, SQL for looking up customer data and writing that engineers can act on. It then goes deeper into the operating system, network behaviour, observability, customer effort and difficult conversations. The last set is for senior support engineers who help run incidents, understand failure modes and move toward leading a queue or team.
12 books in 3 stages, about 3,960 pages (at least 99 hours of reading). The notes are ours, with no ratings or sales claims.
How to choose your books
A short method, so you read the right book for where you are instead of the longest list.
Find your stage
Getting started · 4 books
Reproducing and explaining problems: debugging rules, the command line, SQL and clear written replies and bug reports.
Jump to this stage ↓Doing the job · 5 books
Reading what is underneath the product: operating system behaviour, network failures, logs and traces, plus the customer-facing side of escalations.
Jump to this stage ↓Senior and leading · 3 books
Incidents, failure patterns and leadership: sharing ownership of outages with engineering and stepping up to lead.
Jump to this stage ↓
If you are unsure, start one stage lower than you think. Books in a later stage assume the working knowledge the earlier ones give you.
Begin with one book
Our starting pick
Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems
by David J. Agans · 2002
Every ticket is a bug you must reproduce before you can explain it. Its nine rules are easy to start using in your first week.
See the book ↓Then pick by your situation
Choose the next book by the problem in front of you, not by its place in the list.
If you cannot yet read logs or run commands on a customer's machine comfortably
read The Linux Command Line (getting started)
If aPI calls fail only from some networks
read High Performance Browser Networking (doing the job)
If escalations stall between you and engineering
read Crucial Conversations (doing the job)
Check it against what Support Engineer postings ask for
These skills come from our analysis of live Support Engineer job postings. If one is new to you, its book list sits one click away.
Each step on the scale reflects how often live job postings name the skill, tool or credential, based on our analysis of those postings.
Set a time budget
| Stage | Books | Pages | Reading | At 3 hrs a week |
|---|---|---|---|---|
| Getting started | 4 | ≥ 1,070 | ≥ 27 hrs | ≥ 9 wks |
| Doing the job | 5 | 1,750 | 44 hrs | 15 wks |
| Senior and leading | 3 | 1,140 | 29 hrs | 10 wks |
| All 3 stages | 12 | ≥ 3,960 | ≥ 99 hrs | ≥ 33 wks |
Treat this as a ceiling, not a target. Read one book at a time, apply it, then move on; read reference-style books in sections. Totals are approximate.
Judge any book before you buy it
Age
This list runs from 2001 (Crucial Conversations) to 2022 (Observability Engineering). Older books earn their place by teaching principles that do not change. For tools and platforms, buy the latest edition.
Level
Check the stage before the title. A book from a later stage will make sense only once you have faced the problems it solves.
Format
The longest book here, Site Reliability Engineering, runs about 520 pages. Read very long books as references: pick the chapter that matches the problem you have.
Fit
Ask what you will do differently the week after you finish. If you cannot answer, the book is for a different moment. Come back to it when the situation arrives.
Getting started
Reproducing and explaining problems: debugging rules, the command line, SQL and clear written replies and bug reports.
Start hereDebugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems
by David J. Agans · 2002
~190 pages~5 hrs to read
Nine plain rules for finding faults: understand the system, make it fail, quit thinking and look, change one thing at a time. A good first-month read when every ticket is a bug you have to reproduce before you can explain it.
View book →
The Linux Command Line
by William E. Shotts · 2011
~500 pages~13 hrs to read
A tour of the shell, files, permissions, processes, text processing and basic scripting. Read it early so reading logs, grepping and running commands on a customer's box stops being slow.
View book →
Learning SQL
by Alan Beaulieu · 2005
~380 pages~10 hrs to read
Covers querying, filtering, joins, grouping and subqueries, with exercises. Useful when you start looking up a customer's records yourself instead of waiting on an engineer to run the query.
View book →
Docs for Developers: An Engineer's Field Guide to Technical Writing
by Jared Bhatti, Heidi Waterhouse · 2021
Covers planning, writing and maintaining documentation for developer audiences, including tutorials, reference and troubleshooting pages. Helpful once you are writing replies, help-center articles and bug reports other engineers have to act on.
View book →
Doing the job
Reading what is underneath the product: operating system behaviour, network failures, logs and traces, plus the customer-facing side of escalations.

How Linux Works: What Every Superuser Should Know
by Brian Ward · 2004
~390 pages~10 hrs to read
Explains how a Linux system boots, manages devices, runs services and handles networking and storage. Read it when tickets start to hinge on what the operating system is doing underneath the product.
View book →
High Performance Browser Networking
by Ilya Grigorik · 2013
~400 pages~10 hrs to read
Covers TCP, TLS, HTTP/1.1, HTTP/2, WebSockets and the behaviour of mobile and wireless networks. Helps you explain latency, timeouts and dropped connections when a customer's API calls fail only from some networks.
View book →
Observability Engineering
by Charity Majors, Liz Fong-Jones, George Miranda · 2022
~400 pages~10 hrs to read
Describes structured events, tracing and how to ask new questions of production systems when something breaks. Worth reading once you work from your company's logs and traces and want to give engineering sharper escalations.
View book →The Effortless Experience: Conquering the New Battleground for Customer Loyalty
by Matthew Dixon, Nick Toman, Rick DeLisi · 2013
~260 pages~7 hrs to read
Argues for lowering customer effort in service interactions and draws on a large service-contact study. A practical lens for deciding how to answer, when to hand off, and what to fix at the source.
View book →
Crucial Conversations: Tools for Talking When Stakes Are High
by Kerry Patterson, Joseph Grenny, Ron McMillan · 2001
~300 pages~8 hrs to read
Techniques for staying level and getting to the real issue when a conversation turns tense. Useful for angry customers, disputed root causes, and pushing back on engineering or product when an escalation is stalled.
View book →
Senior and leading
Incidents, failure patterns and leadership: sharing ownership of outages with engineering and stepping up to lead.

Site Reliability Engineering: How Google Runs Production Systems
by Betsy Beyer, Chris Jones, Jennifer Petoff · 2016
~520 pages~13 hrs to read
Essays on monitoring, incident response, postmortems, on-call and service-level objectives. Read it when you help run incidents or shape how support and engineering share ownership of outages.
View book →
Release It!: Design and Deploy Production-Ready Software
by Michael T. Nygard · 2007
~380 pages~10 hrs to read
Case studies of how production systems fail, with patterns such as timeouts, circuit breakers and bulkheads. Gives senior support engineers a vocabulary for recurring failure modes and for pressing engineers on fixes.
View book →
The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change
by Camille Fournier · 2017
~240 pages~6 hrs to read
Walks through each step from mentoring to tech lead to managing managers. Read it when you start mentoring newer engineers, leading a queue or team, or weighing a move into management.
View book →
Book links go to Amazon and are affiliate links. As an Amazon Associate I earn from qualifying purchases.
Frequently asked questions
Which book should a Support Engineer read first?
Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems by David J. Agans. Every ticket is a bug you must reproduce before you can explain it. Its nine rules are easy to start using in your first week.
Do I need to read all 12 books?
No. The list is a menu, not a syllabus. Find your stage (getting started: 4, doing the job: 5, senior and leading: 3), begin with one book (we suggest Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems), then pick the next book by the problem you are facing at work. Come back to the others when the situation they cover arrives.
How long does it take to read these books?
The 11 books with a known page count add up to about 3,960 pages, roughly 99 hours at 1.5 minutes a page. At three hours a week that is about 33 weeks; at six hours a week, about 17. The list is meant to be read over time, one book at a time, not in one run.
Are these books up to date?
They range from 2001 (Crucial Conversations) to 2022 (Observability Engineering). Older titles are included because they teach principles that have not changed; for tools and platforms, we favour recent editions. Check the edition before you buy.
Related reading
Some links are affiliate links: we earn a small commission if you buy, at no cost to you. It does not change what we list.