The trap of rushing

I asked my co-worker Blake recently about his feedback on an escalation path I had written for reporting issues with Tesla’s in-car entertainment system. He was very good at thinking in terms of frameworks (“Is this supposed to be an algorithm that customer service follows to a T or rather guiding principles?”), alternative solutions (“diagrams are more consumable than lists”), and edge cases. I told him he thinks surprisingly long-term for someone at Tesla, or in any fast-paced startup environment where the default is to rush urgently to solve a problem, and then sprint to the next fire. He said for him it’s important to take things slowly, because he can think through why it happened and make sure it doesn’t happen again. I realized in this way, he develops a repository of repeatable approaches to solving any kind of problem. My boss does this too. People say she’s going to run the entire org very soon. I notice she thinks carefully about everything — whether she’s negotiating a business deal with Spotify, or phrasing the wording of an email with a random startup who wants to partner with us. This allows her learnings from each situation to compound, so that whenever she runs into a problem, for her it’s always: “just another one of those x issues.”

This reminds me of one my favorite quotes, “Even though your work seems very trivial and contemptible, make sure you regard it as great and precious, not on account of your worthiness, but because it has its place within that.