A head of design who only approves ends up as a status manager. One who still designs, prototypes and joins the form critique gains real authority over the quality of the work, and takes on risks worth knowing in advance.
Why it makes a difference
Shared vocabulary is the most immediate gain. Vague feedback like "it doesn't feel on brand" teaches nothing. Someone who still edits tokens and touches components can point to which form decision broke the thesis, beyond saying something is wrong.
Structural problems also show up earlier. Looking only at finished deliverables, a head sees symptoms. Taking part in the build, they see the cause before it becomes a pattern: a badly defined shape token, about to repeat across a hundred components, only shows up for whoever was inside the file, not for whoever reviewed the screenshot at the end of the sprint.
Credibility moves too. Authority and accountability need to sit with the same person, and when the head also executes, defending a technical criterion in front of stakeholders comes from someone who knows the real cost of the change.
Then there's calibration. To demand senior-level work, you need to know in practice how much effort a good result takes. Without that, a head accepts mediocre work thinking it's the team's ceiling, or demands a ceiling they can't reach themselves.
Where it becomes a trap
The most common risk is becoming an approval bottleneck. Hands-on without structural delegation turns the head into the reviewer of everything, and the team stops deciding on its own because they know the leader will redo it anyway.
Micromanagement usually arrives calling itself rigor. Pointing out that the spacing token broke the grid is one thing. Rewriting the designer's solution pixel by pixel is another, and it teaches the team to stop proposing.
There's also strategic absence. Every hour inside Figma is an hour away from conversations about roadmap, budget and territory with the other leaders. A head who only executes loses the seat where business decisions happen, and design goes back to being treated as a service.
The last risk is ego wearing the badge of quality standards. When technical defense becomes an excuse to impose personal taste, being hands-on stops being a leadership tool and becomes control. The yardstick has to be the brand thesis and the validated ICP, never the preference of whoever is in charge.
Where the balance is
Hours in the tool measure nothing. The useful question is whether that hands-on work generates context no report can give you, or whether it's distrust that the team won't do it right.
For you, founder: when evaluating a head of design, genuine hands-on work is a sign of technical credibility, not micromanagement. The risk shows up when it becomes an approval bottleneck or disappears from business conversations.
For you, designer: a leader's hands-on work should teach vocabulary and point to causes, without rewriting the solution pixel by pixel. If proposals stopped coming because everything comes back redone, it's worth bringing that up: it's a sign the balance broke.
For you, tech: the same dilemma exists for tech leads. Still coding gives vocabulary and fast diagnosis, and it can also turn into a review bottleneck and absence from architecture conversations with other leaders.
