Jhon Alejandro Garcia Garcia

Imagina que estás administrando tus finanzas personales. Tienes una tarjeta de crédito, y cada mes miras el porcentaje de tu deuda en relación con tu límite de crédito para saber si estás en una situación saludable o si necesitas tomar medidas. El Índice de Deuda Técnica (TDI, por sus siglas en inglés Technical Debt Index) funciona de manera similar para tu código: te ayuda a entender qué tan "endeudado" está tu proyecto en términos de calidad y mantenibilidad.

¿Qué es exactamente el TDI?​

El TDI es como un termómetro que mide la "fiebre" de tu código. Es un número que va de 0% a 100%, donde un valor más bajo indica un código más saludable. Por ejemplo, si tu proyecto tiene un TDI del 15%, está en buena forma, pero si alcanza el 45%, es momento de preocuparse y tomar acciones.

Esta métrica actúa como un sistema de alerta temprana, permitiéndote identificar cuándo tu base de código comienza a deteriorarse antes de que los problemas se vuelvan críticos. Al igual que un médico monitorea los signos vitales de un paciente, el TDI te ayuda a mantener un ojo constante en la salud de tu proyecto.

Algunos factores que influyen en el TDI incluyen:

• Complejidad ciclomática del código
• Duplicación de código
• Cobertura de pruebas
• Violaciones de estándares de codificación
• Deuda técnica deliberada vs accidental
• Antigüedad del código legacy

Por ejemplo, un proyecto puede tener un TDI bajo del 12% gracias a:

• Revisiones de código regulares
• Refactorización proactiva
• Pruebas automatizadas extensivas
• Documentación actualizada
• Estándares de código consistentes

Mientras que un TDI alto del 60% podría indicar:

• Código duplicado extensivo
• Falta de pruebas unitarias
• Violaciones de principios SOLID
• Dependencias obsoletas
• Documentación desactualizada

El TDI te permite tomar decisiones informadas sobre cuándo y dónde invertir recursos en mejoras técnicas, ayudándote a mantener un equilibrio saludable entre el desarrollo de nuevas características y el mantenimiento del código existente.

Proceso de Estimación de Deuda Técnica en Historias de Usuario​

Para mantener un control efectivo del TDI durante el desarrollo, es importante establecer un proceso claro de estimación. Este proceso se divide en dos pasos principales:

1. Durante la Planificación​

Para cada Historia de Usuario (HU), el equipo necesita realizar dos estimaciones clave:

• Esfuerzo base para desarrollo (EB): El tiempo necesario para implementar la funcionalidad principal
• Esfuerzo para gestión de deuda técnica (EDT): El tiempo adicional requerido para mantener la calidad del código

2. Cálculo del TDI​

Con estas estimaciones, podemos calcular el TDI específico para cada Historia de Usuario:

• Fórmula: TDI_HU = (EDT / (EB + EDT)) × 100

Por ejemplo, si tenemos:

• Esfuerzo base = 8 puntos de historia
• Esfuerzo deuda técnica = 2 puntos de historia
• TDI_HU = (2 / (8 + 2)) × 100 = 20%

Este resultado nos indica que el 20% del esfuerzo total se dedicará a gestionar la deuda técnica.

Rangos aceptados​

Según un estudio realizado por SonarSource en 2023, estos son los rangos generalmente aceptados:

• 0-15%: Excelente salud del código
• 16-30%: Situación manejable
• 31-50%: Requiere atención urgente

• 50%: Situación crítica

🧹 El Caso Netflix​

En 2023, Netflix enfrentó una crisis con un TDI del 40%, lo que afectó severamente sus operaciones. Para solucionarlo, implementaron "Operation Clean Slate", una iniciativa que involucró a 800 ingenieros y estableció días quincenales dedicados a la limpieza de código.

El proyecto se desarrolló en tres fases:

1. Identificación (2 meses): Análisis automatizado que reveló 15,000 problemas técnicos
2. Implementación (3 meses): Priorización y resolución de problemas mediante pair programming
3. Prevención (1 mes): Implementación de gates de calidad y monitoreo continuo

Los resultados después de 6 meses fueron significativos:

• Reducción del TDI del 40% al 15%
• Disminución del 45% en tiempo de resolución de incidentes
• Mejora del 30% en velocidad de desarrollo
• Ahorro proyectado de $50M en dos años

Referencias​

1. SonarSource. (2023). "Managing Technical Debt". SonarSource Documentation.

2. Netflix Technology Blog. (2023). "Fixing Performance Regressions Before they Happen". Netflix TechBlog.

3. Martin, Robert C. (2008). "Clean Code: A Handbook of Agile Software Craftsmanship".

4. IEEE Software. (2023). "Technical Debt: From Metaphor to Theory and Practice". IEEE Software Journal, 40(2), 8-17.

¿Alguna vez has mirado tu código y pensado que, aunque funcional, podría parecer más profesional? Lo que diferencia a un desarrollador senior no es solo la lógica, sino también la claridad y la estructura en cada línea.

Escribe código legible para humanos, no sólo para máquinas.

¿Sabías que los desarrolladores pasan alrededor del 50% de su tiempo leyendo código escrito por otros? La legibilidad ya no es opcional, es una necesidad. La claridad del código es una de las claves para reducir la deuda técnica, ya que muchas veces es algo que dejamos pasar con el tiempo. Es importante tener en cuenta una serie de parámetros para que nuestro código se vea más profesional.

Evita las iteraciones anidadas

Como líder técnico, algo que veo con frecuencia es el uso de iteraciones anidadas, las cuales hacen muy tediosa la lectura del código. Aunque esto puede deberse a una estructura de datos mal planteada, muchas veces es más sencillo disminuir la complejidad del algoritmo desde cómo procesamos la información.

Aquí dejo un ejemplo que nos ayuda a entender esto:

 const data = [ 
        { category: 'A', values: [1, 2, 3] }, 
        { category: 'B', values: [4, 5] }, 
      ]; 
      
      data.forEach(item => {
        item.values.forEach(value => {
          console.log(`${item.category}: ${value}`);
        });
      });

A continuación, un ejemplo de cómo manejarlo correctamente:

const data = [ 
  { category: 'A', values: [1, 2, 3] }, 
  { category: 'B', values: [4, 5] }, 
];

function logValues(category, values) {
  values.forEach(value => {
    console.log(`${category}: ${value}`);
  });
}

data.forEach(item => logValues(item.category, item.values)); 

Válida siempre tus arreglos antes de operar con ellos

Otra práctica que veo comúnmente es el uso de métodos propios de los arreglos sin validar previamente que la variable sea efectivamente un arreglo. En JavaScript, los datos no son tipados, lo que permite que su tipo cambie, o que variables solo estén inicializadas sin tener un valor asignado.

Aquí dejo un ejemplo que nos ayuda a entender esto:

const items = undefined;
const filteredItems = items.filter(item => item > 2);

Y a continuación, un ejemplo del manejo correcto:

const items = undefined;

if (Array.isArray(items)) {
  const filteredItems = items.filter(item => item > 2);
}

Evita las funciones ternarias anidadas

Un tema que para mí también es de gran importancia es el uso de funciones ternarias anidadas. Aunque las funciones ternarias son útiles para escribir código más limpio, pueden convertirse en un dolor de cabeza cuando se anidan.

Aquí un ejemplo que nos ayuda a entender esto:

const getStatus = (status) => {
  return status === 'success' ? 'Operación exitosa' :
         status === 'error' ? 'Hubo un error' :
         status === 'loading' ? 'Cargando...' :
         'Estado desconocido';
};

Y este es un ejemplo de cómo manejarlo correctamente:

const getStatus = (status) => {
const getStatus = (status) => {
  const statusMessages = {
    success: 'Operación exitosa',
    error: 'Hubo un error',
    loading: 'Cargando...',
  };

  return statusMessages?.[status] || 'Estado desconocido';
};

No permitas que la deuda técnica se acumule

Podría enumerar muchos otros problemas que surgen, en su mayoría, por el afán y que permiten que la deuda técnica se acumule. Mi invitación a los equipos de desarrollo es a que presten atención a este tipo de prácticas y no dejen pasar por alto este tipo de código. Esto habla mucho de la calidad del trabajo que realizan y, aunque pueda parecer algo básico, démosle la importancia que merece.

¡Bienvenidos a Prompt.org.es, tu plataforma definitiva para dominar el arte de la ingeniería de prompts en español! Estamos emocionados de comenzar este viaje juntos hacia el dominio de la comunicación efectiva con sistemas de inteligencia artificial.

Desde mi experiencia personal, las personas que tenemos grandes ambiciones no creemos en el balance vida-trabajo. El burnout es un término hoy en día muy utilizado para describir el cansancio extremo relacionado con el trabajo, pero es un concepto curioso que, tras el inmenso cambio generacional vivido, especialmente en América Latina, no encaja del todo en nuestro contexto.

"Lo que importa más no es la cantidad de horas que trabajas, sino la pasión y la perseverancia con la que te enfrentas a cada desafío. Grit no es equilibrio, es compromiso total." - Duckworth, A. (2016). Grit: The Power of Passion and Perseverance. Scribner.

🌎 El Enfoque en Latinoamérica​

Gran parte de las discusiones acerca de burnout y reducir carga laboral como de cuidar la salud mental de los empleados, vienen dados con un enfoque que no es latinoamericano. En Latinoamérica, no se trata del burnout o del cansancio, la situación es algo más compleja que eso. En algunas partes de Latinoamérica no fuimos criados para buscar un balance vida-trabajo, nosotros históricamente hemos estado más enfocados y ansiosos por aprovechar cada oportunidad que tenemos que en optimizar el tiempo en un equilibrio vida-trabajo.

Agradezco profundamente los avances en el aspecto humano del trabajo en mi país, así como la creciente preocupación de las empresas por la salud mental de sus empleados. Sin embargo, no siempre este enfoque es el adecuado, y definitivamente no aplica para todo el mundo.

💡 La Mentalidad "Crear o Morir"​

Para algunos, el término burnout se ha convertido en una herramienta para justificar la reducción de la carga laboral, extender plazos y "bajarle dos cambios". Sin embargo, esta mentalidad no resuena con todos, especialmente en América Latina, donde el contexto ha sido históricamente muy diferente. Para muchos de nosotros, la filosofía de "crear o morir" sigue siendo más relevante que nunca, sobre todo ahora que el acceso a la educación se ha democratizado de manera sin precedentes. Hoy en día, estamos a solo un par de clics de acceder a foros, conferencias y clases que antes solo estaban disponibles para quienes podían pagar miles de dólares al año en universidades como Harvard o Stanford.

📢 El Llamado a las Empresas​

El llamado es para las empresas: alimenten estas ganas que tenemos los latinoamericanos de romper el ciclo. No es momento de bajar el ritmo, sino de brindar las herramientas que faciliten este crecimiento. Quiero dejar algo claro: debemos dejar de vincularnos tan directamente con los problemas del "primer mundo". Somos latinos, y debemos nombrar nuestros problemas desde nuestro propio contexto. El llamado a las empresas es claro: busquemos los recursos que necesitamos para seguir creciendo, superar las barreras y romper el círculo que nos ha limitado durante tanto tiempo.

📚 Referencias Adicionales​

• Gladwell, M. (2008). Outliers: The Story of Success. Little, Brown and Company.
• Toffler, A. (1980). La Tercera Ola. Bantam Books.
• Naím, M. (2013). El Fin del Poder. Debate.

"Un equipo no es un grupo de personas que trabajan juntas. Es un grupo de personas que confían entre sí." - Simon Sinek

La confianza es uno de los factores clave tanto para el crecimiento de los equipos de desarrollo como para el crecimiento personal. Además, es fundamental para evaluar el rendimiento de tu equipo. Confiar en el desarrollo de tu equipo y asignarles cargas complejas te ayuda a comprender hasta dónde puede llegar cada miembro. En esta entrada de blog, voy a hablar sobre cómo la confianza me ha ayudado a crecer personalmente y a medir el rendimiento de mi equipo, desde mi experiencia como desarrollador hasta mi rol liderando equipos.

El Poder de la Confianza en el Desarrollo Personal​

La confianza es una herramienta clave tanto para los equipos de desarrollo como para las personas que hacen parte de los mismos. Recuerdo con cariño que mis primeros grandes pasos en el desarrollo fueron porque tanto la empresa como mi líder en ese entonces decidieron confiar en mí, darme la carga y apoyarme cuando lo necesitara. Es algo por lo que siempre estaré agradecido, es como cuando te tiran al agua para que aprendas a nadar; es una de las situaciones donde realmente tuve un crecimiento personal enorme, donde me puse a prueba. No podía fallar a esa confianza que me entregaron. Después de que se solucionaran las cosas de una muy buena forma, me sentí más afianzado en el equipo que nunca.

"Las grandes ideas y soluciones no surgen del control, sino de la libertad que ofrece la confianza." - Ed Catmull, Creativity, Inc.

Los Peligros de la Desconfianza en el Equipo​

La falta de confianza es uno de los temas que más puede generar fallas de agilidad en un equipo y que puede frenar el crecimiento personal de cada uno de los integrantes del mismo. Esto puede ser generado por muchos factores, pero no es relevante en esta entrada escribir al respecto. Como desarrollador, viví muchas faltas de confianza que señalaban red flags de equipos a los que no quería pertenecer. Cuando creas una solución y esta se pone bajo tela de juicio desde una situación más personal, te hace sentir inmediatamente que no perteneces a ese equipo o que no se está teniendo un trabajo en equipo; más bien parece una pelea de egos, lo que puede llevar a situaciones de discusiones graves.

La Importancia de la Confianza en Equipos Remotos​

Me parece supremamente importante, sobre todo en el mundo del desarrollo, donde existen equipos de trabajo remoto que se deben afianzar desde la confianza, tanto en las entregas como en los desarrollos. Aunque la anterior anécdota es bastante positiva, también he vivido la situación opuesta: el micromanagement en su esplendor 😢. Estar cerca de una entrega y no sentir que confiaban en mí, estar más de dos horas contestando mensajes de ¿Cómo va la entrega?, o llenar bitácoras con las horas de ejecución diaria de mis tareas, destruyó por completo mi relación con el equipo al que pertenecía en ese entonces. Personas como yo, que estamos más centradas en la resolución de problemáticas de la forma más rápida, que hemos demostrado lo que valores, detestamos por completo que se nos ponga en tela de juicio.

"El micromanagement es una señal clara de falta de confianza en el equipo. Cuando los líderes no confían, los empleados sienten que cada paso que dan está bajo vigilancia, lo que sofoca la creatividad y el compromiso." - Liz Wiseman, Multipliers

Liderazgo y Confianza: Una Relación Simbiótica​

Como líder técnico, he notado el reflejo, casi como un espejo, de lo que viví siendo un desarrollador. Definitivamente, la confianza es uno de los factores clave en la formación de equipos sólidos de desarrollo, y también deja anécdotas muy interesantes. Seguramente no todos los desarrolladores van a poder responder a la confianza de la forma que lo esperas como líder. Sin embargo, con la correcta guía y el feedback adecuado, lo más seguro es que se sientan cada vez más consolidados en el equipo y puedan tener una respuesta cada vez más acertada a la confianza que se les entrega.

Hace poco vi un video donde Mark Zuckerberg y un miembro de su equipo hablaban de cómo se construyó el buscador de personas de Facebook. Este miembro del equipo contaba cómo, cuando llegó, Mark le asignó la tarea diciendo: "Si yo pude construir Facebook, tú puedes construir un buscador." Eso resume lo que es la confianza en el liderazgo: no solo hacia el equipo, sino también cómo se construye esta confianza con base en las habilidades que un líder puede demostrar.

Este punto también me parece bastante interesante y es que para consolidarse como un líder no solo hace falta tener el nombre; es importante demostrar que eres capaz de rendir al nivel que esperas que rinda tu equipo. Puedo asegurar que si no demuestras constantemente lo que eres capaz de hacer, se puede poner en tela de juicio tu rol como líder y perderás la confianza de tu equipo. El liderazgo no es una tarea sencilla y trae consigo muchas implicaciones.

"El liderazgo se basa en la credibilidad. Si tus acciones no están alineadas con lo que esperas de los demás, perderás la confianza de tu equipo rápidamente." - James Kouzes y Barry Posner, The Leadership Challenge

Conclusión​

La invitación de esta entrada es a que confíen en sus equipos y se ganen la confianza de los mismos. Esto no se gana con el puesto o con el nombre, se gana demostrando los conocimientos y las habilidades, además de un acompañamiento juicioso ante los llamados de auxilio de los integrantes del equipo.

"El liderazgo no se trata de tener todas las respuestas, se trata de confiar en tu equipo para que las encuentre contigo." - General Stanley McChrystal, Leaders: Myth and Reality

El Impacto Real en los Proyectos​

Traigamos a la realidad el tema de la deuda técnica, que muchas veces parece un fantasma en el camino de las empresas. Para entenderlo mejor, hagamos un ejercicio mental: imaginemos que estamos en medio de un parque industrial donde los cables eléctricos no están bien señalizados, y el orden de estos elementos básicos es inadecuado para el contexto. Estos errores en la infraestructura pueden causar accidentes o retrasos en el mantenimiento y la elaboración de funcionalidades.

De la misma manera, la deuda técnica impacta el desarrollo: como cables tirados sin señalización, que cualquiera podría pisar. Un cable o código mal gestionado, o sin documentar, puede generar problemas que dificulten la integración de nuevas funcionalidades y aumenten los tiempos de entrega.

El Peligro de Ignorar la Base: ¿Estás Preparado para Escalar?​

Pasar por alto la necesidad y prioridad de los diferentes elementos es, muchas veces, lo que nos lleva a cuestionarnos si lo que estamos experimentando es realmente tangible. En numerosas ocasiones, la entrega de funcionalidades en una etapa temprana puede dar la impresión de que estamos superando las expectativas en el desarrollo del producto. Sin embargo, no siempre somos conscientes del costo oculto de cada una de estas funcionalidades.

"La única manera de ir rápido es yendo bien." — Kent Beck, Extreme Programming Explained

Si priorizamos funcionalidades que se escriben sobre módulos que no tienen un funcionamiento del todo acertado, ¿cómo esperamos que se comporten estas funcionalidades? Si visualmente agregamos características sobre algo que no se ve bien, ¿cómo esperamos que se vea esta nueva funcionalidad que estamos agregando? Aquí surge una cuestión importante: ¿cómo debemos priorizar las nuevas tareas para que todo vaya sobre ruedas?

El Costo del Crecimiento Desordenado​

Si no se examinan con detalle, de la mano de un experto, estas funcionalidades podrían "esconder bajo la alfombra" problemas que, a medida que nuestro producto crezca, nos harán cuestionar si realmente es funcional. El crecimiento de un producto puede verse afectado no sólo en términos de tiempos de desarrollo, sino también por el aumento de fallos y errores en las diferentes etapas, lo que genera graves retrasos.

Sumemos a esto el constante cambio que los productos de hoy en día demandan. Los usuarios están acostumbrados a la novedad constante; los productos no pueden detenerse, y hacerlo podría tener costos altísimos, no sólo en términos de reputación, sino también en retrasos. Mientras la tecnología avanza a un ritmo acelerado, si el crecimiento del producto no lo hace, quedará rezagado en la obsolescencia.

Llamado a la Acción​

A los lectores de estas entradas, los invito a que aceleremos los productos desde la priorización, saldemos la deuda técnica y avancemos para que las ideas se conviertan en realidades.

"El código desordenado es un lastre que ralentiza el desarrollo futuro y dificulta la incorporación de nuevas funcionalidades." — Robert C. Martin, Clean Code

La Deuda Técnica: El Enemigo Silencioso​

Imaginemos trabajar en un sistema donde cada cambio o mejora puede generar una cascada de fallos y errores significativos, impidiendo que continuemos con el desarrollo normal del proyecto. Esto es lo que ocurre cuando no prestamos la atención necesaria a la deuda técnica, la cual genera un costo que "cobra su cheque" cuando intentamos implementar nuevas funcionalidades.

El Desafío del Código Legacy​

Ejemplos de esto abundan en el mundo de la tecnología. Podemos hablar del código legacy: quienes tenemos experiencia en este campo hemos desarrollado una habilidad que, en un mundo ideal, no deberíamos necesitar, y es la capacidad de interpretar funcionalidades tipo spaghetti, donde las mismas están entreveradas y son difíciles de seguir. Tras horas de interpretación, apenas logramos unos minutos de ejecución efectiva.

Mantenimiento y Actualización​

En este punto, es importante mencionar no solo el mantenimiento, sino también la actualización de la infraestructura. Desde el liderazgo técnico de una empresa, no solo se debe buscar generar valor a través del producto, sino también estar al día con las actualizaciones tecnológicas. Aunque el ritmo de una empresa puede empujarnos a mantener la estabilidad en los stacks y tecnologías actuales, no debemos olvidar que estamos en un mundo tecnológico en constante actualización. Ignorar estas novedades podría llevarnos a quedar rezagados frente a la competencia.

Conclusiones y Recomendaciones​

La deuda técnica nos permite avanzar rápidamente, como una deuda crediticia, pero es esencial tomar pausas para solventar estos vacíos antes de que se acumulen. Aunque lo ideal sería no tener ninguna deuda técnica, quienes trabajamos en esta industria sabemos que es un tema complejo que no podemos ignorar.

Preguntas para Reflexionar​

• ¿Es el gap de cada funcionalidad el necesario para evitar generar deuda técnica?
• ¿El equipo se toma el tiempo necesario para evaluar si existe deuda técnica?
• Si ya tienes deuda técnica, ¿está el producto pasando por la pausa necesaria para poder limpiarla?

La invitación es a dejar de tratar este tema como un fantasma: ¡es una realidad! Y los principales afectados no son los desarrolladores, sino el producto.

"Ignorar la deuda técnica es posponer lo inevitable: en algún momento tendrás que pagar el precio de un código mal diseñado." — James Shore, The Art of Agile Development

🙏 Agradecimiento​

Antes de iniciar con esta entrada, quiero dar un agradecimiento a este gran camino que ha significado convertirme en un TL, un puesto soñado por muchos y que otras personas detestan. Es un rol complejo desde su base técnica y que tiene un importante componente humano de cercanía, difícil de ejecutar pero extremadamente gratificante. Gracias a la vida por ponerme en este hermoso camino, desde el cual puedo ayudar y construir en la profesión que amo.

📝 Introducción​

Hoy me di este momento para escribir una entrada de blog. No quiero que se confunda esta entrada, pensando que basta con el aspecto humano para ser un líder técnico. Hay que tener unas bases muy sólidas en el aspecto técnico para liderar un equipo, dado que para ser un líder no basta con tener el cargo; se debe ganar el respeto del equipo. Como todos los líderes sabemos, el respeto de un equipo técnico se gana demostrando que se tiene la habilidad de diseñar e implementar soluciones complejas, y de destrabar desde lo técnico cualquier requerimiento, por muy complejo que sea.

Sin embargo, siento que el camino de un TL no es para nada lineal y está lleno de momentos. Esta reflexión no debería ser tomada como la generalidad del liderazgo; es una visión planteada desde mi experiencia personal, seguramente sujeta a mucha reflexión. Liderar un equipo es un viaje diario lleno de complejidades, y para el que siento que no todos estamos preparados.

💪 Retos diarios de un TL​

Lo increíble de ser TL es que cada día encuentras una nueva pregunta y un reto diferente en muchos ámbitos, tanto técnicos como personales. Sin embargo, los más complejos son los inherentes al liderazgo de un equipo humano, como muestra:

¿Cómo llevar tranquilidad a un equipo que siente que no es suficiente? ¿Cómo liderar desarrolladores que tienen un talento innato que muchas veces percibes como un potencial gigante para llevarlos a su cumbre? ¿Cómo aumentas el rendimiento del equipo sin sacrificar la estabilidad del mismo?

Estos retos y preguntas son un ejemplo de lo que conlleva el diario vivir de mi trayectoria como líder.

🤔 No hay respuestas​

No hay respuesta para estas preguntas. No hay un solo camino para ejercer el liderazgo, no es tan simple como eso; ojalá lo fuera. En lo que más he encontrado respuestas es, definitivamente, en el ámbito humano. Tengo la certeza, y en mi trayectoria como líder he comprobado, que las personas, sobre todo aquellas con gran potencial, no se bloquean por el ámbito técnico; se bloquean como respuesta a factores de su vida, a sentirse inconformes con el trabajo que hacen, a no estar cumpliendo sus sueños, a sentirse estancados. Definitivamente, el factor técnico, aunque importante, puede entrar en segundo plano.

Como desarrollador, siento que tengo la habilidad técnica para solventar los problemas que se presenten. Sin embargo, como líder, siento que la tarea más compleja es llegar a la parte humana de los equipos para poder transformarlos desde el fondo.

Desde mi experiencia, hablar con el equipo un momento sobre cómo estuvo su día, cómo van las cosas con la familia, cómo está todo en su vida, cómo se siente con el trabajo que está haciendo, cómo se siente desenvolviéndose en el proyecto, hace que el aspecto técnico empiece a fluir de una manera increíble. Sin embargo, esto no es una fórmula mágica.

🌟 El liderazgo no tiene fórmulas mágicas​

Estoy seguro de que el liderazgo no tiene una fórmula mágica, ni tiene estándares en su forma. Es una tarea, no solo del líder, sino de todos los miembros del equipo. Sin embargo, mantener esa cohesión en un equipo es una gran responsabilidad que debe asumir un líder en su labor. Desde mi posición como líder, los invito a que construyan sus equipos desde lo humano.

Les deseo que, si son líderes, los retos y preguntas que trae este viaje diario sean resueltos día con día y paso a paso.

💡 Nota: Las reflexiones compartidas en este artículo están basadas en experiencias personales y pueden variar según el contexto y equipo específico.