Um head de design que só aprova acaba virando gerente de status. Quando ainda desenha, prototipa e entra na crítica de forma, ganha autoridade real sobre a qualidade do trabalho, e passa a correr riscos que valem ser conhecidos antes.
Por que faz diferença
Vocabulário compartilhado é o ganho mais imediato. Feedback vago como "não está com a cara da marca" não ensina nada. Quem ainda edita token e mexe em componente consegue apontar qual decisão de forma quebrou a tese, além de dizer que algo está errado.
Problema estrutural também aparece mais cedo. Olhando só o entregável pronto, o head vê sintoma. Participando da construção, vê a causa antes de virar padrão: um token de forma mal definido, que vai se repetir em cem componentes, só aparece pra quem esteve dentro do arquivo, e não pra quem revisou o print no fim do sprint.
A credibilidade muda de lugar. Autoridade e accountability precisam estar na mesma pessoa, e quando o head executa, a defesa de um critério técnico diante de stakeholder vem de quem conhece o custo real da mudança.
E tem a calibração. Pra exigir nível sênior, é preciso saber na prática quanto esforço um resultado bom custa. Sem isso, o head aceita entrega mediana achando que é o teto do time, ou cobra um teto que nem ele alcança.
Onde vira armadilha
O risco mais comum é virar gargalo de aprovação. Hands on sem delegação estrutural transforma o head em revisor de tudo, e o time para de decidir sozinho porque sabe que o líder vai refazer de qualquer forma.
Microgerenciamento costuma chegar com nome de rigor. Apontar que o token de espaçamento quebrou a grade é uma coisa. Reescrever a solução do designer pixel a pixel é outra, e ensina o time a parar de propor.
Tem ainda a ausência estratégica. Cada hora dentro do Figma é uma hora fora da conversa de roadmap, orçamento e território com as outras lideranças. O head que só executa perde a cadeira onde a decisão de negócio acontece, e o design volta a ser tratado como serviço.
O último risco é o ego com crachá de padrão de qualidade. Quando a defesa técnica vira desculpa pra impor gosto pessoal, hands on deixa de ser ferramenta de liderança e vira controle. A régua precisa ser a tese de marca e o ICP validado, nunca a preferência de quem está no comando.
Onde fica o equilíbrio
Horas na ferramenta não medem nada. A pergunta que ajuda é se aquele hands on está gerando um contexto que relatório nenhum entrega, ou se é desconfiança de que o time não vai fazer do jeito certo.
Pra você, founder: ao avaliar um head de design, hands on genuíno é sinal de credibilidade técnica, e não de microgerenciamento. O risco aparece quando ele vira gargalo de aprovação ou some das conversas de negócio.
Pra você, designer: hands on de quem lidera devia ensinar vocabulário e apontar causa, sem reescrever a solução pixel a pixel. Se as propostas pararam de surgir porque tudo volta refeito, vale levar isso pra conversa: é sinal de que o equilíbrio quebrou.
Pra você, tech: o mesmo dilema existe pro tech lead. Continuar codando dá vocabulário e diagnóstico rápido, e também pode virar gargalo de review e ausência na conversa de arquitetura com outras lideranças.
