> It's very strange that the authors talk about how "making a bad hire is terribly expensive" but then call out "travel time and costs". Well, if B < A for each role filled, is it really so bad?

The cost of a bad hire they're referring to includes things like opportunity cost of not having a good hire in that position, damage they've done to the product (codebase, design, etc.), and second-order effects like demoralizing the rest of the team.

The actual hiring costs of a bad hire are a rounding error compared to the damage they can do.

Have you ever been on a team that was great until they hired one wrong person who made every work week a miserable slog? Attrition goes up as the good employees start to leave. The codebase starts accumulating a lot of tech debt. Even after they're gone it can take a long time to recover.

This is why it's so important to be able to fire fast, but that's another topic rife with difficulties.

But that's the point.

If the cost of a bad hire is huge (which I agree it is), why is the hiring process optimized, in part, around reducing the travel costs? It would seem that these costs are modest in comparison.