I’m currently working on a project that’s closely adjacent to Tesla so it’s not surprising to see some of Elon’s Musk’isms creeping into and often solidifying in my brain as practical approaches to problem-solving. In this case - specifically - automation.
Automation, as we all know, is an up and coming aspect of many Airtable solutions. However, if you have the urgency or need to automate quickly, you probably have the cart in front of the horse; perhaps way out in front of the horse.
Recap
Do not change the order of these stages. As the GhostBusters famously said - “doing that would be bad”.
Make requirements less dumb
Delete parts and processes
Optimize
Go faster
Automate
My observations are that Airtable enthusiasts typically automate first or in the vast majority of projects, too early. But worse than tackling these stages out of order is skipping a few of them. Notably, requirements development is not in the list. But Elon assumes his teams are generating requirements in earlier unstated stages; it’s a foregone conclusion. In Airtable, this is not the case. Almost every attempt to engage me has lacked requirements without which you cannot begin to make them less dumb. :winking_face:
Are you optimizing poorly-design processes or to satisfy dumb requirements?
Transcript
First, your requirements are definitely dumb. It does not matter who gave them to you and it’s particularly dangerous if a smart person gave you the requirements because you might not question them enough. Everyone’s wrong, no matter who you are, everyone’s wrong some of the time. Whatever requirement or constraint you have, it must come with a name — not a department — because you can’t ask the department about requirements; you have to ask a person and that person who’s putting for the requirement or constraint must agree that they must take responsibility for that requirement. Otherwise you can have a requirement that basically an intern two years ago, randomly came up with off the cuff and they don’t even have the company anymore.
Try very hard to delete the part or process. This is actually very important. If you are not occasionally adding things back in, you are not deleting parts or processes enough. The bias tends to be very strongly towards adding this part of the process in case we need it. But you can basically make in case for so many things that are ultimately unnecessary.
The third step is similar to the second step; possibly the most common error of a smart engineer is to optimize the thing that should not exist.
Step four, accelerate cycle time. You’re moving too slowly go faster. But do not go faster until you worked on the first three steps. First, I’ll give you pain. If you’re being and you know, your grade, don’t take it faster, stop picking your grade. Uh, So, Uh, but it’s, you can always make me go faster. Um, and then
The final step is automate. I have personally made the mistake of going backwards on all five steps multiple times. Don’t do that.