Performance concerns often exist in tension with product requirements - what do you do when they conflict?

1. Make requirements less dumb - particularly if a smart person gave it to you. Requirements must be owned by specific people, not departments.

2. Delete the part or process - you can make an "in-case" argument for anything.

3. Simplify or optimize - do not optimize a thing that should not exist (convergent thinking).

4. Accelerate cycle time - move faster.

5. Automation - allow technology and/or machines to do the work.
    

Elon's broader point was that it's trouble if you go through these steps out of order. He shared a number of stories about times he had done that at SpaceX and Tesla.

I was struck by a few of these points, but it made me think in particular about the first 2.

There is a good instinct in engineers to, when confronted by a problem, run through steps 1 and 2. However, this is often done quite lazily, without considering the actual requirement. I call this StackOverflow Syndrome.

"How do I do X?"
"X is outdated and bad practice. Try Y, it's more modern. Have you considered Z?"
"Y doesn't do what X does and Z isn't even close..."
Silence.

StackOverflow syndrome is caused by laziness: you're too lazy to understand why we think X is necessary, and instead, you just suggest a bunch of other solutions (or suggest just doing nothing at all).

Changing requirements and deleting unnecessary ones is excellent and necessary, but it has to be done from a place of understanding, not from a place of laziness or defensiveness. If we don't understand the importance of the requirement and how important it is to the customer, deleting it makes our product worse for no good reason.

When we reach beyond the feature in question and start asking about what the feature is trying to accomplish, then we can really understand if the feature is good and necessary. Engineers often have a far better understanding of the costs of features (time to develop, performance impact, etc), which leads to adversarial conversations with Product that end in deadlocks and distrust.

Consider this real-world example from my open-source work: webfonts were causing a massive slowdown on Rubygems.org. Changing how they were used and removing a few of them kept 90% of the designer's intentions but also sped up the site by 10x. That fix could have been done by just deleting webfonts entirely, but instead I was able to find a compromise that kept the designer's requirement to give the site a distinct visual look while not impacting perf.

What's required is for Engineering to deeply understand and have empathy for the "why" behind each requirement and feature by actually talking to the physical person that wanted it to be there. Conversely, Product has to be aware of all the costs behind implementing the requirement as written: development time and opportunity cost, and  performance and reliability impact.

Each side can't do this on their own. It requires empathy and a willingness for Product and Engineering to "speak each other's language". But it's absolutely necessary for a functioning software development pipeline.

Until next time,

-Nate