Engineering and leadership run on the same discipline: define the output before you start, or you're not delegating, you're wishing.
Every task I hand off has one owner, one output, and one deadline before it's assigned — no vague scope, no “help out with X.” When two developers joined for an active feature trial, they got the same standard I hold myself to: what done looks like in one sentence, a hard date, and a stuck-protocol — come to me after a set number of hours blocked, not before, not after three days of silence.
I apply the same rule to the team itself, not just its tasks. A role only stays a role if there's a live task attached to it — not a title that sounded good when it was assigned. When people's real hours were going elsewhere, I resized the org chart to match reality instead of inflating it to look better on paper. It's a smaller decision than it sounds, but it's the one that makes a team easier to actually lead.
I still write code deliberately, not by default — architecture decisions, hard technical calls, and anything blocking the whole team stay mine. Everything else belongs to whoever's positioned to own it. Staying in the code isn't nostalgia; it's how I stay sharp enough to know when a shortcut is being taken, or when something's harder than it's being described as.
Outside engineering, I designed and run a lean operating system for the studio's public presence — a weekly loop that turns raw build notes into scheduled, platform-specific content, at near-zero cost, with no marketing hire. Same instinct as the delegation framework: build the system once, let it run, don't manufacture busywork to fill the gaps.