¿Hasta qué punto sigues metido en lo técnico como manager?

Mantente lo bastante técnico como para tomar buenas decisiones y revisar diseños con credibilidad, sin ponerte en la ruta crítica. En la práctica eso significa leer pull requests, participar en las revisiones de diseño, coger de vez en cuando trabajo pequeño y no urgente, y sumarte a los incidentes como coordinador y no como héroe. El tamaño del equipo marca el nivel: con cinco personas puedes programar un poco, con quince no deberías.

Mi regla es mantenerme lo bastante técnico como para tener opinión y no coger nunca trabajo que bloquee a nadie. Así que leo pull requests casi a diario, estoy activo en las revisiones de diseño y cojo cosas que de verdad no son urgentes: herramientas internas, un test inestable, documentación, trabajo que puede esperar una semana cuando mi calendario explota. Lo que no hago es coger una funcionalidad en la ruta crítica, porque la semana que se tuerce siempre es la semana en la que tengo tres entrevistas y una conversación de reorganización, y entonces soy el cuello de botella y además le he enseñado a mi equipo a no fiarse de mis compromisos. Con seis personas probablemente escribo código unas pocas horas a la semana. Cuando llevaba un grupo de dieciséis repartido en dos equipos no escribía casi nada y me mantenía afilado con documentos de diseño y revisiones de incidentes. Durante los incidentes me sumo como coordinador y escudo, no como quien teclea, porque esa es la forma más rápida de hacer que los expertos de verdad me esperen a mí.