I enjoyed Karl Yang’s essay on illegible work and wanted to riff on it a little, specifically from the lens of software engineering at larger technical companies. [^1]
There are two failure modes that I’ve seen most often:
I think the latter of these two cases is a much more solved problem through a combination of tooling and brag docs, which I’ll be sure to write about later.
The former is trickier, and one I can empathize with: the most rewarding (both personally and financially) projects I’ve had in my career involved doing work that was mostly unrelated to my team’s success criteria.
I’d recommend two principles when setting out on this kind of work:
If you can neither coherently state the rationale & expected return on your work’s investment nor find people who believe in it, something is Wrong. It’s hard to say what that Wrong is without context — it might be that your workstream really isn’t the right area of investment, it might be that your organization is overly risk averse — and I hesitate to prescribe in broad strokes.
[^1]: Why larger technical companies in particular? Because legibility as a concept doesn’t really come into play until you’re in the thousands of employees range. [^2]: Can’t be understated how much time is a key role here — being in an organization long enough to amass deep knowledge not just of the system at hand but of your fellow inhabitants is the single easiest lever you have (though it requires patience.)