El primer error es seguir programando lo importante. Es lo que sabes hacer y lo que te da satisfacción, pero mientras tú te quedas con la tarea crítica, tu equipo aprende que las decisiones difíciles siempre las resuelve alguien más.
El segundo es revisar el código como si fuera tuyo. Hay una diferencia enorme entre “esto está mal” y “esto no es como yo lo habría escrito”. Si corriges lo segundo, la gente deja de proponer.
El tercero, y el que más caro me ha salido, es no traducir. El equipo necesita saber por qué esta tarea importa para el negocio, y la dirección necesita saber por qué la deuda técnica les va a costar dinero en seis meses. Esa traducción no la va a hacer nadie más.
Escalar no es dejar de ser técnico. Es usar lo técnico para decidir y para explicar, en lugar de acaparar el trabajo divertido.