Skip the design doc when the solution is obvious

Design docs have a cost. The same article on design docs at Google says they are not worth writing when the solution is not ambiguous, when the doc would only be an implementation manual without trade-offs, or when the overhead gets in the way of rapid prototyping.

A useful rule of thumb for a tech lead:

• Obvious, reversible change: just build it, with a clear pull request description.
• Unclear approach or hard to reverse: short design doc, reviewed before coding.
• Truly unknown: build a quick prototype first, then write the doc with what you learned.

Matching the process to the risk keeps the team moving and keeps design docs meaningful.