Salud, código y resiliencia en tech

Hace poco, el autor de burntsushi.net contó que fue diagnosticado con anti-NMDA receptor encephalitis. El post original es personal, sí, pero no se queda en el testimonio médico. También deja una pregunta muy útil para cualquiera que trabaje en software: ¿qué pasa cuando la salud interrumpe la rutina, la productividad y la identidad profesional al mismo tiempo?

Si trabajas en tech, probablemente ya viste alguna versión de esa escena. Alguien desaparece de Slack por semanas, vuelve con energía irregular, pide menos reuniones o directamente se ausenta sin dar demasiadas explicaciones. En muchos equipos se habla de deadlines, pero no de licencias médicas. Se mide throughput, pero no se diseña para la fragilidad humana. Y cuando aparece una enfermedad neurológica seria, como la encefalitis anti-NMDA, esa tensión se vuelve imposible de ignorar.

Qué es la encefalitis anti-NMDA y por qué importa en esta conversación

La encefalitis anti-NMDA es una enfermedad autoinmune en la que el sistema inmune ataca receptores NMDA en el cerebro. Eso puede afectar memoria, lenguaje, comportamiento, movimiento, sueño y, en algunos casos, provocar convulsiones o periodos de confusión intensa. La National Institute of Neurological Disorders and Stroke explica que la encefalitis, en general, puede ser causada por infecciones o por una respuesta autoinmune; la variante anti-NMDA es una de las más estudiadas dentro de ese grupo.

No necesitas ser médico para entender el impacto práctico. Si una persona no puede sostener atención por 20 minutos, si leer código le exige más energía de la normal, o si la memoria de trabajo falla, entonces el problema ya no es solo clínico. También es laboral, social y logístico. En tech solemos fingir que la mente es una pieza estable, pero no lo es.

Lo que cambia en la vida diaria

La diferencia entre “estoy cansado” y “estoy atravesando una enfermedad neurológica” es enorme. Cansancio es dormir bien y seguir. Una encefalitis puede alterar la capacidad de hablar, procesar instrucciones o reconocer el ritmo de una conversación. Eso afecta tareas simples como responder un correo, revisar un pull request o decidir si vale la pena asistir a una reunión.

En la práctica, esto obliga a repensar el trabajo con más precisión. No sirve decir “descansa” si la persona sigue recibiendo mensajes urgentes cada 15 minutos. Tampoco sirve romantizar la resiliencia si no hay cobertura del equipo. La recuperación no ocurre en el vacío.

Por qué el caso toca a la comunidad tech

La comunidad tech suele hablar de salud cuando ya hay burnout, ansiedad o dolor físico acumulado. Pero las enfermedades severas también forman parte de la conversación, aunque incomoden. Si trabajas en una startup, en una consultora o en un equipo remoto distribuido por Latinoamérica, tarde o temprano vas a tocar este tema: alguien se enferma, alguien cuida a otra persona, alguien vuelve distinto.

Y ahí aparece una oportunidad concreta. En vez de ver la salud como una interrupción, puedes verla como parte del sistema. Igual que diseñamos para caídas de servicio, también deberíamos diseñar para caídas humanas.

Salud y productividad no son enemigos

Hay una idea muy instalada en tech: producir mucho equivale a estar bien. En realidad, muchas veces solo equivale a estar empujando el cuerpo y la cabeza más allá de lo razonable. Eso funciona un tiempo, hasta que deja de funcionar. Una enfermedad neurológica como la encefalitis anti-NMDA hace visible algo que ya era cierto antes: la productividad no puede ser el único criterio para medir valor.

Si tu equipo solo sabe operar en modo “si no entregas, fallas”, entonces no tiene resiliencia, tiene fragilidad maquillada. Y eso se nota más en contextos de salud. Una ausencia de dos semanas puede desordenar un sprint. Una ausencia de dos meses puede desarmar una relación laboral si no hay procesos mínimos.

Señales de que tu cultura laboral está mal preparada

Mira estas señales concretas:

1. Nadie sabe quién cubre a quién cuando alguien se enferma.
2. Las decisiones importantes dependen de una sola persona.
3. Las reuniones no tienen notas ni resumen escrito.
4. Se espera respuesta inmediata fuera de horario.
5. La licencia médica se trata como favor y no como derecho o necesidad.

Si reconoces dos o más, ya tienes un problema estructural. No hace falta esperar una crisis para corregirlo.

Qué sí ayuda en un entorno real

No necesitas una política de 40 páginas para empezar. Necesitas hábitos operativos sencillos y consistentes. Por ejemplo: documentación mínima, handoffs claros, prioridades visibles y una cultura donde decir “hoy no puedo” no se lea como falta de compromiso.

También ayuda separar urgencia de ansiedad. Que un ticket esté rojo no significa que tu compañero deba responder a medianoche. Que una persona esté recuperándose no significa que deba seguir “pendiente” del equipo. La recuperación necesita bordes claros.

Cómo hablar mejor de enfermedad en equipos de software

En tech solemos ser buenos para nombrar bugs y malos para nombrar estados humanos. Decimos “está out”, “anda medio mal”, “tiene temas personales”. Esas frases sirven para esquivar el problema, pero no para resolverlo. Hablar mejor de enfermedad no significa invadir la privacidad de nadie. Significa crear un lenguaje útil, respetuoso y operativo.

La clave es simple: no obligues a la persona a convertir su diagnóstico en una presentación. Si quiere contar más, lo hará. Si no, basta con saber qué necesita para trabajar o para no trabajar.

Un marco útil para conversaciones difíciles

Puedes usar este esquema cuando alguien del equipo atraviesa una enfermedad seria:

• Qué necesita hoy, no qué podrá hacer en tres meses.
• Qué puede compartir y qué prefiere mantener privado.
• Qué tareas quedan pausadas y quién las toma.
• Qué canal se usa para urgencias reales.
• Qué seguimiento es humano y cuál es solo ruido.

Ese marco evita dos extremos: la sobreexposición y el silencio total. Ambos suelen hacer daño.

Lo que no deberías decir

Hay frases que parecen amables, pero no ayudan:

• “Avísanos cuando vuelvas al 100%”. Nadie controla ese calendario.
• “Seguro con descanso se te pasa”. No siempre.
• “Si necesitas algo, avisa”. Mejor ofrece opciones concretas.
• “No te preocupes por el trabajo”. Si vas a decirlo, acompáñalo con cobertura real.

En vez de eso, prueba con algo más útil: “Hoy cubrimos tus tareas X e Y. No necesitas responder mensajes después de las 6 p. m. y yo me encargo de actualizar al resto del equipo”.

Qué puede hacer un equipo cuando alguien se enferma

La resiliencia no se improvisa el día del diagnóstico. Se construye antes, con procesos simples y decisiones repetibles. En equipos de software, eso se traduce en menos dependencia individual y más claridad operativa.

Una buena pregunta no es “¿quién es indispensable?”. La mejor pregunta es “¿qué pasaría si esta persona no está disponible por 30 días?”. Si la respuesta es caos, tienes una deuda organizacional.

Medidas concretas que sí puedes aplicar

1. Documenta decisiones en texto, no solo en reuniones.
2. Mantén una lista visible de responsables secundarios.
3. Reduce el número de personas que aprueban cada cosa.
4. Usa tareas pequeñas con definición clara de terminado.
5. Evita que una sola persona concentre conocimiento crítico.
6. Define horarios de respuesta realistas, especialmente en remoto.

No hace falta aplicar todo a la vez. Pero sí hace falta empezar por algo que reduzca el costo de una ausencia inesperada.

Tabla práctica para equipos

La tabla parece simple, pero resuelve varios problemas a la vez. Reduce malentendidos, baja la presión social y evita que la persona enferma tenga que repetir lo mismo en cinco chats distintos.

Resiliencia sin romanticismo

La palabra resiliencia se usa tanto que ya perdió filo. A veces se emplea para pedir aguante infinito. Eso no sirve. Resiliencia útil no significa soportar más carga sin quejarte. Significa recuperarte con menos daño y con mejores apoyos.

En el post original, el valor no está en convertir la enfermedad en una metáfora bonita. Está en mostrar que una vida profesional puede verse interrumpida de forma abrupta, y que aun así se puede reconstruir una rutina. Eso no pasa por voluntad pura. Pasa por tratamiento, tiempo, apoyo y ajustes concretos.

Recuperarse también es trabajo

Cuando una persona sale de una enfermedad seria, suele enfrentar una secuencia rara: el cuerpo sigue lento, la cabeza quiere correr y el entorno espera normalidad. Ese choque desgasta. Si trabajas en tech, vale la pena recordar que volver no es lo mismo que estar listo para el mismo ritmo de antes.

Por eso conviene negociar el retorno como si fuera un despliegue gradual. Menos tareas, menos reuniones, más margen para errores pequeños y más comunicación escrita. Igual que en un rollout, el objetivo no es impresionar. Es evitar incidentes.

Lo que la comunidad puede aprender

La comunidad tech puede hablar mejor de enfermedad si deja de tratarla como anécdota excepcional. Hay muchas personas que viven con condiciones crónicas, recuperaciones largas o secuelas cognitivas. No todas van a escribir un post público. No todas quieren hacerlo. Pero casi todas se benefician de equipos que saben escuchar, documentar y redistribuir trabajo.

También conviene dejar de usar la productividad como sustituto de empatía. Una persona puede seguir entregando mientras está mal, y eso no significa que esté bien. A veces solo significa que está sosteniendo demasiado con demasiado poco apoyo.

Salud, trabajo y comunidad: una conversación que sí vale la pena

Si algo deja claro este caso es que salud y trabajo no son compartimentos separados. En tech, donde muchos equipos operan distribuidos, con deadlines cortos y herramientas asíncronas, esa intersección aparece todo el tiempo. Lo que cambia es la escala del problema: desde un resfriado mal atendido hasta una encefalitis que obliga a replantear meses de vida.

La conversación útil no es “cómo seguir rindiendo pase lo que pase”. La conversación útil es “cómo diseñar equipos que no se rompan cuando una persona deja de estar disponible”. Eso sirve para enfermedad, maternidad, duelo, cuidado de familiares y cualquier otra situación que no cabe en un sprint planificado al milímetro.

Un estándar más humano para equipos tech

Si tú lideras un equipo, puedes empezar por tres preguntas:

• ¿Tenemos documentación suficiente para que otra persona retome una tarea hoy?
• ¿Sabemos cómo redistribuir trabajo sin castigar a quien se ausenta?
• ¿Tratamos la salud como una excepción o como parte normal del diseño organizacional?

Si trabajas como contributor individual, también puedes mover la aguja. Documenta mejor, deja contexto en texto, evita depender de una sola conversación y pregunta por la capacidad real antes de asumir que todo sigue igual.

La tecnología no elimina la vulnerabilidad humana. Solo la hace más visible cuando algo falla. Y quizá esa visibilidad sea útil, si la usamos para construir mejores hábitos en vez de pedirle más sacrificio a la misma gente de siempre.

Tabla resumen