re: On Making Tech Decisions VIEW POST


When people ask me to make decisions, they're usually looking for a simple response. Something on the order of a basic "yes/no" or "which of these X things would you pick". For better or worse, that's not my style. Never has been. So, whenever people ask me for a decision, what they usually get back is something on the order of:

  • here's what I considered
  • here's what I saw the strengths/weaknesses of doing/choosing 'X'
  • here's what I saw as the risks/rewards of doing/choosing 'X'
  • here's the weights I put on the above

...and then finally "here's what I chose based on the above". I prefer that people understand why I made a given decision. That way, they have not just the decision/recommendation but its basis. Provides more background on whether the decision/recommendation is valid for why they were asking.

Plus, it provides a measure of CYA. Months down the road you can dig up that email/Slack/etc. conversation to answer the "why the hell did we do this" question if something went wrong or went a different direction than some thought it would. =)


This is a really good point, we usually maintain Architecture Decision Records, usually in markdowns or adoc in a documentation git repo and share that in a mail.

code of conduct - report abuse