Something I keep thinking about: I watched a video of Elon (I know, I know) recently where he was talking about something like his five step process for efficient engineering. One thing he said that really stuck with me was asking ourselves if we’re optimizing something that shouldn’t exist. It’s an easy trap to fall into, because optimization of something feels good, and it’s easy to point to things like “I made step XYZ 22% faster.” But, if step XYZ itself is unnecessary (ultimately), that was a waste of effort, and we should just put in the work to eliminate it.
This video in general really resonated with me. Elon is um… incredibly problematic, yes, but the thought process he lays out jives really well with my experience of what’s most impactful/effective, especially in startup engineering orgs. You encounter lots of engineers out there, even in startups, who live in this mindset of doing just the work that’s teed up for them, without scrutinizing whether it’s actually useful work. Their assumption is that if it’s been prioritized for me, it must still be important. That’s true a lot of the time, but not always — especially in startup environments, where the churn in actual priorities since the last formal prioritization exercise can be significant.
I just went and re-watched the video — here is the entire process:
make your requirements less dumb (and don’t take initial requirements as gospel)
try very hard to delete the part/process (this is basically the “YAGNI” principle) — you should have to occasionally add something back in; to this end, any requirement or constraint must have a name, not a department, attached — a person must take responsibility for the requirement
simplify or optimize (this is step 4, not earlier, in order to avoiding optimizing something that should not exist)
accelerate cycle time — now go faster, but don’t go faster until you’ve worked on the other things first
automate
This is starting to feel a lot like a thinkpiece, so I’m going to stop here.