El verdadero desafío no era entender los sistemas — era entender a las personas que dependían de ellos, y a las que los mantenían funcionando.

El error más común: confundir urgencia con importancia

En soporte, todo parece urgente. El usuario que llama desesperado, el ticket que lleva horas abierto, el sistema que "dejó de funcionar" diez minutos antes de una reunión crítica.

Uno de los primeros cambios que implementé fue una matriz de prioridades clara. No para ignorar solicitudes, sino para responderlas mejor. Cuando el equipo sabe exactamente qué atender primero y por qué, la presión baja, el enfoque mejora y los clientes perciben la diferencia.

La urgencia la define el usuario. La importancia la define el impacto real en el negocio. Aprender a distinguirlas fue un punto de inflexión.

Automatizar no es reemplazar personas — es liberarlas

Una de las decisiones que más impacto tuvo fue mapear los procesos repetitivos del equipo y automatizarlos con Power Automate y SharePoint.

Creación de tickets, asignación automática según categoría, notificaciones a usuarios, reportes semanales — todo eso consumía horas que el equipo podría invertir en problemas que realmente necesitan criterio humano.

El resultado no fue reducir personal. Fue que el equipo empezó a tener tiempo para pensar, para mejorar procesos, para aprender. Y eso se nota en la calidad del servicio.

La métrica que más importa no está en el dashboard

Puedes medir tiempo de respuesta, tickets cerrados, satisfacción del cliente. Son importantes. Pero hay una métrica que rara vez aparece en los reportes: ¿el equipo entiende por qué hace lo que hace?

Un equipo que conoce el impacto de su trabajo en el negocio toma mejores decisiones, escala los problemas correctos y trata a los usuarios con más empatía. Invertir tiempo en esa comprensión es invertir en calidad sostenible.

Lo que cambiaría si empezara de nuevo

Documentar desde el primer día. No solo los procesos técnicos, sino las decisiones, los aprendizajes, los errores. El conocimiento que vive solo en la cabeza de una persona es un riesgo para el equipo.

Y escuchar más antes de proponer soluciones. Los equipos de soporte tienen una visión del negocio que muy pocos roles tienen — están en contacto directo con los puntos de dolor reales. Esa perspectiva vale oro si sabes cómo canalizarla.

Para cerrar

Coordinar soporte no es glamoroso. No tiene el brillo de lanzar un producto nuevo o construir una feature. Pero cuando funciona bien, todo lo demás también funciona bien. Es el sistema inmune de la operación.

Y eso, para mí, vale más que cualquier título en la puerta.

Decidí volver. Y esto es lo que encontré en el camino.

El síndrome del "ya no sé nada"

Lo primero que me golpeó fue la cantidad de cosas nuevas. Frameworks que no existían, patrones que habían cambiado, herramientas que reemplazaron a otras que yo conocía bien.

La trampa es creer que tienes que aprenderlo todo antes de hacer algo. Eso paraliza.

Lo que funcionó para mí fue lo opuesto: empezar a construir algo pequeño con lo que ya sabía, e ir incorporando lo nuevo cuando el proyecto lo pedía. No aprender en el vacío — aprender con un propósito concreto.

Lo que no se oxida

Años sin escribir código, pero la lógica de resolución de problemas seguía intacta. La capacidad de descomponer un problema complejo en partes manejables, de leer un error y entender qué está pasando, de pensar en el usuario antes que en la solución técnica.

Eso no desaparece. Y es más valioso de lo que uno cree cuando está empezando.

La experiencia en soporte y coordinación me dio algo que no hubiera tenido si hubiera seguido programando todo el tiempo: entender cómo los sistemas fallan en la práctica, cómo los usuarios reales interactúan con la tecnología, y qué significa que algo "funcione bien" más allá del código.

React después de un tiempo fuera

Había trabajado con React antes de pausar. Volver fue más fluido de lo esperado, pero el ecosistema alrededor había crecido enormemente. Next.js, Tailwind, nuevos patrones de estado, Server Components.

Mi estrategia fue sencilla: un proyecto real, aunque fuera pequeño. Este portafolio es parte de ese proceso. Cada componente que construyo, cada problema que resuelvo, es una forma de reconectar con algo que genuinamente disfruto.

El momento en que algo vuelve a hacer clic

Hay un punto en el proceso de retomar algo donde deja de sentirse como esfuerzo y empieza a sentirse como flujo. Para mí fue cuando dejé de intentar recordar cómo se hacían las cosas y empecé a simplemente hacerlas.

No sé exactamente cuándo pasó. Pero un día estaba depurando un componente y me di cuenta de que no había consultado documentación en un buen rato. Pequeña victoria. Gran señal.

Lo que le diría a alguien en la misma situación

No esperes a "estar listo". Esa sensación no llega antes de empezar — llega después.

Tus años fuera no son tiempo perdido. Son perspectiva acumulada. Y la perspectiva, bien aplicada, produce mejor software que la técnica sola.

Empieza con algo pequeño. Compártelo aunque no sea perfecto. Y sigue construyendo.

Eso es exactamente lo que estoy haciendo.