Una regla simple que funciona: si pasaste una o dos horas sin ningún progreso, avisá. No «pedí que te lo resuelvan»: avisá, contando qué probaste. Muchas veces el equipo tiene una información que no tenías, y el bloqueo dura lo que dura leer el mensaje.
Idea clave
Trabarse es normal; avisar tarde es lo que cuesta. Dos horas sin progreso y ya conviene escribir: qué pasa, qué probaste, qué necesitás y a qué afecta. Seguí trabajando mientras tanto, y cuando se resuelva, dejá anotado lo que aprendiste.
Objetivo, intento, resultado esperado, resultado real y lo que probaste. Cinco líneas que convierten una pregunta sin respuesta posible en una que se contesta en dos minutos. Y escribirla es, además, la última oportunidad de resolverlo solo: pasa más seguido de lo que parece.
La prueba más rápida para saber si algo merece documentarse: ¿alguien preguntó esto alguna vez? Si la respuesta es sí, escribila. Si es no, probablemente estés escribiendo para un lector imaginario.
Idea clave
Documentá lo que no se deduce del código, cerca de lo que describe, y escribilo justo después de haberlo sufrido. Una guía operativa se juzga por si otra persona la puede seguir sin preguntarte nada; una explicación, por si respondió una pregunta que alguien hizo de verdad.
Tu tarea termina cuando funciona para quien la pidió, y esa persona lo sabe. Revisá tu propio cambio antes que nadie, verificá en producción, mirá los registros unos minutos y avisá. Y si rompiste algo, decilo vos primero: eso es ownership, no la ausencia de errores.
Adaptar no es bajar el nivel: es cambiar el orden. Lo que va primero es lo que esa audiencia necesita para actuar. El detalle técnico no desaparece, pasa a estar disponible para quien lo pida.
Idea clave
Conclusión primero, pedido explícito, impacto en la unidad de quien escucha. El detalle técnico no se esconde: se pone a disposición. Y con una mala noticia, avisá temprano y con opciones: sin opciones estás entregando el problema, no comunicándolo.
Separá siempre dos cosas que se mezclan: el esfuerzo —cuántos días de trabajo lleva— y la fecha —cuándo va a estar—. La fecha depende de reuniones, de otras tareas, de vacaciones y de prioridades ajenas. Confundirlas es lo que convierte «tres días de trabajo» en «el jueves».
Idea clave
Un rango con supuestos vale más que un número con falsa precisión. Separá esfuerzo de fecha, escribí de qué depende que sea el mínimo o el máximo, y ofrecé una exploración acotada cuando la incertidumbre sea demasiado grande. Y avisá el día que cambia, no el día de la entrega.
Llevá opciones, no problemas; recomendá, no decidas por otro; y dejá claro quién decide. El trabajo de comparar se hace antes y con datos, no en vivo y con opiniones. Cuando eligen algo distinto, preguntá qué pesó: ahí está el criterio real de la organización.
Comprometerse no significa fingir que estás de acuerdo. Significa que la ejecución no va a ser peor por tu desacuerdo. Podés decir tranquilamente «yo prefería otra cosa, lo estamos haciendo así y lo voy a hacer bien»: eso es honesto y es compromiso.
Idea clave
Todo el desacuerdo, antes; toda la ejecución, después. Objetá con hechos, con alternativa y diciendo cuánto te importa. Decidido el asunto, que nadie pueda notar por tu trabajo que preferías otra cosa. Y si el problema que anticipaste aparece, la conversación útil es cómo salimos, no quién tenía razón.
La regla que resume todo: el que tiene que terminar sabiendo es el que tiene que tener las manos en el teclado. Si durante el traspaso escribís vos, estás haciendo una demostración, no una transferencia.
Idea clave
El que tiene que aprender es el que ejecuta y el que escribe. Ordená lo que sabés por frecuencia y por daño, transferí lo importante haciéndolo pasar por sus manos, y dejá que la documentación la escriba quien todavía no sabía: va a incluir justo lo que a vos ya se te volvió invisible.
Devolvé el problema con más información, no con la solución. Respondé con el método cuando haya tiempo y con la respuesta cuando haga falta. Asegurá lo primero de todo: algo real entregado la primera semana, un nombre por área y permiso explícito para preguntar.
La traducción no reemplaza el argumento técnico: lo precede. Primero la frase en la unidad que se decide, después el detalle para quien quiera entenderlo. Al revés, la mitad de la sala se desconecta antes de llegar a la parte que importa.
Idea clave
Ingreso, costo, riesgo o tiempo del equipo: elegí una y empezá por ahí. El hecho propio y verificable primero, el costo de la propuesta en la misma unidad después, y el detalle técnico disponible para quien lo pida. Un número modesto y medido vale más que uno grande e indefendible.
Una propuesta técnica existe para que el desacuerdo llegue temprano. Problema con evidencia, criterios explícitos, alternativas reales —incluida no hacer nada—, consecuencias malas escritas y preguntas abiertas. Y si nadie comentó, el documento falló aunque se haya aprobado.
La pregunta que ordena un proyecto ambiguo: ¿qué es lo que, si resulta imposible, tira abajo todo el plan? Eso va primero, aunque no sea lo más grande ni lo más urgente. La respuesta casi siempre es una integración externa, un permiso, una restricción legal o un supuesto sobre datos que nadie verificó.
Idea clave
Atacá primero lo que puede invalidar todo, no lo que sabés hacer. Convertí la ambigüedad en una lista de preguntas con dueño y fecha, hacé que algo atraviese el sistema entero en las primeras semanas, y mantené el estado en un lugar que no seas vos.
Tu trabajo no es decir que no: es hacer visible qué perilla se está moviendo. «Podemos llegar a fin de mes con estas tres funcionalidades de las cinco» o «podemos llegar con las cinco aceptando que las dos últimas salen sin probar en profundidad» son propuestas. «No llegamos» no lo es.
Idea clave
No podés fijar las cuatro perillas: si no elegís, se mueve el riesgo en silencio. Llevá la versión reducida —que es trabajo técnico y nadie más puede hacerla—, decí qué se resigna en cada opción, y dejá la decisión donde corresponde. Salvo en seguridad y datos, donde no hay perilla que mover.
Hecho, impacto, pregunta, acuerdo. Sin adjetivos, sin adivinar intenciones y sin esperar a la evaluación. Y cuando preguntes cómo lo ve, callate de verdad: en esa pausa aparece casi siempre la información que cambia la conversación.
El truco no es agregar actividades de desarrollo encima del trabajo: es hacer que el trabajo que ya existe enseñe. Una revisión de código que explica el criterio vale más que una charla de una hora, y cuesta dos minutos más que un «ok».
Idea clave
Que enseñe el trabajo, no tu agenda. Repartí lo que tiene decisión y visibilidad, convertí las revisiones en el canal donde circula el criterio —incluyendo que se revise hacia arriba—, y sacá de cada incidente una acción escrita con dueño. Eso escala a seis personas; las reuniones uno a uno, no.
Tu ventaja como perfil técnico en esta conversación es única: sos el único que sabe qué es barato y qué es caro. Muchas veces hay una versión que cuesta una décima parte y resuelve el 90 % del problema, y nadie más en la sala puede verla.
Idea clave
Preguntá qué esperamos que pase, antes de construir. Sabé cómo gana plata la empresa, tené tres números en la cabeza, y aportá lo único que nadie más puede aportar: qué es barato, qué es caro y qué versión más chica resuelve casi lo mismo.
Dirección técnica es un puñado de criterios que el equipo puede aplicar sin vos. Se reconoce porque permite decir que no a algo razonable: si todo entra, no hay dirección, hay buenos deseos.
Idea clave
La dirección técnica se mide por las decisiones que el equipo toma sin vos. Salida del negocio, aterrizada en tres criterios aplicables, con lo que se resigna escrito y una forma de darse cuenta si se equivocó. Si todo entra, no hay dirección; si nadie la puede usar para descartar algo, tampoco.
Un roadmap técnico es una secuencia de capacidades que la empresa va a tener, con el costo de no tenerlas. Si una fila no se puede completar con «esto nos permite…» o «si no lo hacemos, pasa…», esa fila todavía no está lista para el documento.
Idea clave
Un roadmap técnico se gana en la traducción, no en la lista. Objetivo del negocio, estado actual con números, tres apuestas con su costo y su verificación, lo que queda afuera, y una fecha para revisarlo. Si una fila no dice qué se vuelve posible o qué pasa si se espera, todavía no está lista.
El objetivo no es eliminar dependencias —eso es imposible—, sino convertir dependencias de trabajo en dependencias de interfaz. Si el equipo A puede avanzar contra algo estable que B publica, dejaron de necesitar coordinarse para cada cambio.
Idea clave
Si dos equipos necesitan hablar todos los días, la frontera está mal. Medí el costo real de cada dependencia, convertí las de trabajo en dependencias de interfaz, y reservá las reuniones para lo que de verdad necesita negociarse. Hacia afuera, la alineación es adelantar la información al momento en que todavía sirve.
Delegá la decisión, no la tarea, y decí en voz alta en qué nivel estamos. Una decisión delegada y razonable se sostiene aunque no sea la tuya; lo que se corrige no es el caso, es el criterio. Y no hay ownership sin las tres patas: decisión, consecuencia y tiempo.
Si una regla se puede verificar con una herramienta, discutirla en una revisión de código es desperdicio. El tiempo de revisión es caro y escaso: hay que gastarlo en lo que sólo puede mirar una persona —si el diseño resuelve el problema, si el caso borde está contemplado, si el nombre dice la verdad— y no en comas.
Idea clave
Lo que se puede verificar con una herramienta no se discute; lo que necesita juicio se escribe con su porqué. Y si algo sólo vive en tu cabeza, no es un estándar del equipo: es una dependencia tuya. La prueba es simple: una semana sin vos, ¿qué se degrada?
Medí el interés, no el capital. Cuánto cuesta por mes, a cuánta gente, si está creciendo y qué bloquea. Con eso la deuda deja de ser una discusión sobre gustos y pasa a ser una fila más que se puede comparar con el resto del plan. Y pagala pegada a algo que la empresa ya quiere: es la forma que menos crédito consume.
Los riesgos organizacionales cuestan cero hasta el día que cuestan todo. Escribilos como hechos futuros con su consecuencia, con dueño y fecha, y revisalos donde se planifica. Y para el más común —el conocimiento concentrado— la mitigación que funciona no es documentar: es que otra persona haga la próxima tarea real.
Una decisión reversible que ya se propagó dejó de ser reversible. Por eso conviene preguntarse no sólo si hoy se puede deshacer, sino en cuánto tiempo deja de poder deshacerse. Ese plazo es la fecha límite real para revisarla.
Idea clave
Preguntá cuánto cuesta deshacerlo antes de preguntar cuál es mejor. Si se deshace barato, que decida quien está más cerca y seguimos; si no, alternativas escritas, consulta y registro. Y acordate de que lo reversible deja de serlo cuando se propaga: ponerle fecha a esa revisión es parte de la decisión.
La prueba práctica: ¿cuándo fue la última vez que alguien del equipo dijo «no entiendo» en una reunión? Si no pasó en meses, no es que todos entiendan todo.
Idea clave
Un equipo seguro no es uno donde nadie se incomoda: es uno donde decir algo incómodo no cuesta caro. Se construye en cinco momentos concretos —el incidente, la contradicción pública, tu propio error, la pregunta básica y la mala noticia hacia arriba— y se mide por cuánto tardás en enterarte de los problemas.
Crecer es hacerse cargo de una incomodidad nueva con una red puesta. Sin incomodidad no hay aprendizaje; sin red, hay una mala experiencia que enseña a no meterse ahí otra vez.
Idea clave
El plan de carrera real de tu equipo es cómo repartís el trabajo cada semana. Dale a cada uno algo que todavía no sabe hacer del todo, con red, y liberá el espacio vos. Las conversaciones sirven para acordar hacia dónde; el reparto es lo que efectivamente lleva.
Medí el sistema, no a las personas, y mirá las métricas de a grupos que se tensionen entre sí. Antes de empezar a medir algo, preguntate qué va a hacer la gente cuando sepa que lo mirás: esa respuesta predice mejor el resultado que cualquier discusión sobre si la métrica es buena.
atlas.matiascaliz.com.ar/materias/comunicacion-y-liderazgo-tecnico — si algo de acá no se entiende solo, el post completo lo explica.