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.

See the full Support Engineer roadmap →

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.

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

StageBooksPagesReadingAt 3 hrs a week
Getting started4≥ 1,070≥ 27 hrs≥ 9 wks
Doing the job51,75044 hrs15 wks
Senior and leading31,14029 hrs10 wks
All 3 stages12≥ 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.

  • Cover of Debugging
    Start here

    Debugging: 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 →
  • Cover of The Linux Command Line

    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 →
  • Cover of Learning SQL

    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 →
  • Cover of Docs for Developers

    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.

  • Cover of How Linux Works

    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 →
  • Cover of High Performance Browser Networking

    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 →
  • Cover of Observability Engineering

    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 →
  • Cover of Crucial Conversations

    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.

  • Cover of Site Reliability Engineering

    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 →
  • Cover of Release It!

    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 →
  • Cover of The Manager's Path

    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.

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.