All the planning, learning, and preparation in the world isn't doing the work. Doing it badly, doing it scared, doing a tiny piece of it - that's the only thing that counts as doing it.
The entire culture of productivity advice has created an elaborate system for not doing work while feeling productive. You can spend infinite time planning the perfect system, buying the right tools, consuming content about how others succeeded, and telling yourself you're making progress. None of that is the work. The work is the work.
This cuts through every rationalization engineers use to avoid starting. Waiting until you understand the entire codebase before making a change? Not doing it. Reading five more architecture documents before proposing a solution? Not doing it. Debating the perfect tech stack in Slack for three days? Not doing it. The only thing that moves the needle is writing code, shipping features, or fixing bugs - even if it's messy, even if you're uncertain, even if it breaks.
The piece draws a sharp line that most productivity content blurs: failing while attempting the work IS doing the work. Doing it badly is doing it. Doing it timidly counts. Those are all forward motion. What doesn't count is the elaborate theater of preparation that feels like progress but produces nothing. You can't learn your way into doing something - you learn by doing it poorly first, then iterating. The discomfort of starting before you feel ready is the actual work, not a barrier to overcome before the real work begins.
Check out the full stdlib collection for more frameworks, templates, and guides to accelerate your technical leadership journey.