Nunca necesitaste una moda para invertir en tu gente

14 min de lectura

Permiso concedido por presentación de diapositivas

El patrón es siempre el mismo. Una consultora publica un informe. Un competidor anuncia algo. Un miembro de la junta asiste a una conferencia y regresa alarmado. De repente aparece un presupuesto. De repente el cambio es urgente. De repente las personas merecen apoyo.

Nadie lo pidió antes de ese momento. No porque fuera innecesario. Sino porque la organización pasó años eliminando el espíritu emprendedor de su propia gente. La iniciativa es castigada, ignorada o absorbida silenciosamente por el crédito de otro. Después de suficientes repeticiones, incluso los desarrolladores fuertes dejan de proponer cosas. Hacen el ticket. Se van a casa. La cultura quiere cumplimiento salarial y lo obtiene, luego se pregunta por qué nada mejora sin intervención externa.

El vocabulario por lo general ya está en la sala. Los desarrolladores han oído hablar de TDD. Saben que existe la integración continua. Saben que la programación en pareja es real. Simplemente nunca practicaron nada de eso porque nadie creó las condiciones, estableció la expectativa o señaló que la propiedad era bienvenida. Ya sea que la empresa emplee a cinco mil desarrolladores o a cinco, el patrón es idéntico. El desarrollador senior que podría decir “deberíamos estar haciendo X” aprendió hace mucho tiempo que decirlo no cambia nada excepto su propia reputación de ser difícil.

Luego llega alguien externo — un coach, un consultor, un evangelista de marcos de trabajo — y en cuestión de semanas las mismas personas están escribiendo pruebas, ejecutando pipelines y entregando con fluidez. El conocimiento no vino de afuera. El permiso sí.

Eso es lo que hace que la dependencia de las modas sea tan reveladora. Las personas siempre fueron capaces. El liderazgo simplemente nunca hizo el espacio. Luego, una marca comercial otorga cobertura política y todos fingen que la necesidad es nueva.

El ciclo de dependencia de las modas

Funciona así. Un movimiento de la industria gana fuerza. Los proveedores y consultoras detectan la ola. Producen certificaciones, modelos de madurez e informes de referencia. Esos informes crean el miedo suficiente para mover a los comités de presupuesto. De repente la organización puede invertir en cosas como mentoría, herramientas, experiencia de desarrollador o prácticas de colaboración, pero solo bajo el estandarte del nuevo marco.

En el momento en que la moda se desvanece, el apoyo se evapora. Nada acerca de la necesidad subyacente ha cambiado. Los desarrolladores todavía necesitan tiempo de aprendizaje, mejores herramientas, tamaños de equipo razonables y autoridad técnica. Pero la cobertura política ha desaparecido, por lo que la inversión muere.

Esto no es accidental. Revela cómo muchas organizaciones se relacionan con su propia fuerza laboral técnica. No invierten porque sea obviamente necesario. Invierten porque una autoridad externa hizo que fuera socialmente seguro invertir. Eso es un fracaso de gobernanza vestido de paciencia estratégica.

Y entre modas, el liderazgo tampoco busca ayuda activamente. No abren LinkedIn para leer lo que los profesionales escriben sobre el desarrollo moderno. No asisten a reuniones donde los verdaderos desarrolladores hablan sobre lo que funciona. No investigan cómo otras organizaciones resolvieron problemas similares. No llaman a especialistas experimentados para hacer preguntas. No hacen ninguna de las tareas que un propietario responsable haría antes de tomar una decisión operativa significativa.

Lo que hacen en su lugar es delegieren. Le dicen a RRHH que contrate a alguien para X. Emiten una RFP. Le preguntan a Gartner qué dice el Cuadrante Mágico. Esperan a que un proveedor les haga una presentación. Asisten a una conferencia ejecutiva y esperan que una ponencia les diga qué hacer a continuación. El patrón es siempre la recepción pasiva de respuestas empaquetadas en lugar de la investigación activa de su propia situación.

Esa pasividad es la forma en que el filtro de contratación hace su daño. El liderazgo no entiende cómo se ve el buen trabajo, por lo que no puede describirlo. RRHH recibe un informe vago lleno de palabras clave, construye un filtro que recompensa la simetría de palabras clave y excluye exactamente a las personas que podrían haber ayudado. La escasez de talento que sigue es en realidad una falla del filtro, pero el liderazgo nunca lo ve porque nunca participó en la búsqueda con el entendimiento suficiente para notar lo que faltaba.

La gobernanza significa ser dueño de las condiciones que permiten el buen trabajo Publishes on July 6, 2026. Come back then. , no esperar a que una consultora explique cómo se ve el buen trabajo.

Los impulsores son políticos, no racionales

La dependencia de las modas no es causada solo por la ignorancia. Es sostenida por la política organizacional.

En la mayoría de las empresas, las personas que construyen software se sientan en una caja etiquetada como TI. Esa etiqueta no es neutral. Significa función de soporte. Significa centro de costos. Significa que las personas en esa caja no marcan la dirección: reciben tickets. Su juicio no se consulta cuando se forma la estrategia. Sus objeciones no se registran cuando la promesa de un proveedor contradice la realidad. Sus advertencias no llegan a la sala donde ocurre la decisión presupuestaria.

Ese arreglo es político. Alguien decidió, probablemente hace décadas, que el software es infraestructura en lugar de producto. Que es mantenimiento en lugar de creación. Que las personas que lo hacen son proveedores de servicios intercambiables en lugar de especialistas cuyo conocimiento da forma a lo que la empresa puede siquiera intentar.

Una vez que esa clasificación política está en su lugar, todo lo demás sigue. Los desarrolladores no pueden obtener presupuesto sin un marco de trabajo porque su dominio no se reconoce como estratégico. No pueden rechazar plazos poco realistas porque las funciones de soporte no pueden desafiar al negocio. No pueden rechazar decisiones de arquitectura dañinas porque los centros de costo no tienen autoridad. Solo pueden recibir instrucciones y ser culpados cuando el resultado es deficiente.

La moda cambia eso temporalmente, no porque arregle la estructura política, sino porque eleva brevemente la conversación a un nivel donde los comités de presupuesto prestan atención. Luego la moda pasa. La clasificación política se reafirma. Los desarrolladores vuelven a ser TI.

El mito de la prima donna y lo que oculta

Hay una palabra que surge de manera confiable cuando la alta dirección habla sobre los desarrolladores de software que se oponen, hacen preguntas o se niegan a fingir que un mal plan funcionará. Prima donnas. Difíciles. Que no trabajan en equipo.

Esta etiqueta realiza un trabajo político útil. Replantéa la objeción profesional legítima como una deficiencia personal. El desarrollador que dice que este plazo es poco realista se convierte en alguien con un problema de actitud. El arquitecto que dice que este producto del proveedor no puede hacer lo que prometió ventas se vuelve difícil de tratar. El especialista experimentado que dice que el equipo necesita tres meses de refactorización enfocada antes de que cualquier característica nueva se entregue de manera segura se convierte en alguien que no entiende el negocio.

Ninguna de estas objeciones es comportamiento de prima donna. Son el resultado normal de profesionales competentes que entienden el material con el que trabajan. Un ingeniero estructural que dice que los cimientos no pueden soportar otro piso no es una prima donna. Un cirujano que dice que el paciente necesita un procedimiento diferente no está siendo difícil. Pero los desarrolladores de software que ejercen el mismo juicio profesional obtienen una etiqueta diferente, porque la organización ya ha decidido que su dominio es una función de soporte y las funciones de soporte no tienen derecho a decir no.

La ironía más profunda es que los desarrolladores experimentados generalmente saben más sobre el dominio del negocio de lo que los tomadores de decisiones se permiten creer. Ven cómo se ejecutan realmente las reglas. Ven dónde los datos contradicen la narrativa. Ven qué flujos de trabajo del cliente realmente ocurren versus cuáles imaginó el gerente de producto. Ven dónde los propios procesos de la organización colapsan todos los días porque son ellos cuyo código tiene que manejar las excepciones.

Ese conocimiento rara vez viaja hacia arriba. No porque los desarrolladores no puedan comunicarlo. Sino porque nadie en una posición de autoridad pregunta. La estructura política dice: ustedes son TI. Ustedes implementan. Ustedes no analizan, asesoran o desafían.

Extraños no pueden crear tu innovación

Existe una fantasía recurrente en las organizaciones que luchan con la entrega de software. Dice así: reuniremos un nuevo equipo de especialistas externos, les daremos los requisitos y construirán algo extraordinario.

Casi nunca funciona de esa manera.

Construir un producto que importe requiere contexto acumulado. Requiere comprender lo que se ha intentado antes. Requiere saber dónde están las minas políticas, qué segmentos de clientes realmente pagan, qué decisiones técnicas se tomaron bajo presión y deberían revisarse, y cuáles se tomaron cuidadosamente y deberían preservarse.

Un grupo de extraños no tiene ese contexto. No pueden desarrollarlo en una inducción de dos semanas. Y la organización, por lo general, ni siquiera sabe cómo transferir ese contexto porque vive en las cabezas de las personas que han estado allí: las mismas personas cuyas opiniones nunca se elevaron a las conversaciones de estrategia.

Esto es lo que hace que la fantasía sea especialmente cara. Las personas que ya están dentro de la empresa —los desarrolladores descartados como TI, los que mantuvieron los sistemas existentes— a menudo poseen más conocimiento del dominio operativo que cualquier otra persona en el edificio. Saben qué reglas comerciales son reales y cuáles son folklore. Saben qué integraciones funcionan realmente y cuáles fallan en silencio. Saben qué segmentos de clientes generan casos extremos que ninguna especificación capturó jamás. Pero la organización los trató como implementadores, por lo que a nadie se le ocurrió incluirlos en la estrategia del producto. En cambio, el liderazgo contrata a extraños y se pregunta por qué el avance nunca llega.

Lo que realmente necesitas es un entorno donde las personas capacitadas que entienden el dominio puedan realizar un trabajo sostenido y enfocado con autoridad real sobre las decisiones técnicas. Eso no tiene nada que ver con un marco de trabajo. Tiene todo que ver con tratar a los desarrolladores con respeto y darles espacio para ejercer su juicio.

La ilusión del diploma

Existe una confusión persistente entre la educación y la capacidad en el software. Alguien termina una carrera en ciencias de la computación y la organización asume que puede construir productos. No pueden. Aún no. No sin años de práctica guiada por mentores, dolorosos fracasos, incidentes en producción, pesadillas de implementación y la lenta acumulación de un sentido de los sistemas.

Un título enseña teoría. Parte de esa teoría es genuinamente útil. Gran parte tiene poca relación con el trabajo diario de construir, operar y evolucionar sistemas de producción de los que dependen personas reales.

La brecha entre la graduación y la competencia es enorme. Y sin embargo, muchas organizaciones estructuran su contratación como si el título fuera la credencial calificadora en lugar de la línea de salida. Contratan a recién graduados, no les dan mentoría digna de ese nombre, los rodean de otras personas que tampoco tienen experiencia en producción y luego actúan sorprendidos cuando el software resultante es frágil, costoso y perpetuamente tardío.

Las personas que podrían ser sus mentores —desarrolladores con quince, veinte, treinta años de experiencia en la construcción de sistemas reales— a menudo no están cerca. No porque no existan. Porque el filtro de contratación los descartó antes de que ocurriera cualquier conversación humana.

El filtro de contratación descarta la maestría

Esta es la parte que más debería alarmar a los ejecutivos. Las empresas se quejan de la escasez de talento mientras filtran activamente a los candidatos más fuertes disponibles.

Un desarrollador con veinticinco años de experiencia construyendo sistemas de producción en múltiples industrias, múltiples pilas tecnológicas y múltiples contextos organizacionales no se ve como la coincidencia limpia de palabras clave que desea su Sistema de Seguimiento de Candidatos (ATS). No han pasado cinco años consecutivos en su marco exacto porque estaban ocupados resolviendo problemas más difíciles en diferentes entornos. Su currículum muestra movimiento porque a los expertos se les llama cuando algo está roto, no cuando todo es cómodo.

Tu filtro lee eso como inestabilidad. El mercado lo lee como una trayectoria.

El aumento de personal pierde a las mismas personas por la misma razón estructural. El modelo de adquisiciones recompensa la igualdad, la superposición de palabras clave y la inserción sin fricciones. Castiga la profundidad, el rango y el tipo de juicio que solo se desarrolla a través de prácticas variadas.

Mientras tanto, la organización contrata a alguien que pasa el filtro ATS, marca todas las casillas del framework y nunca ha tenido que arreglar un sistema que no construyó, recuperarse de una implementación fallida o decirle a un gerente de producto que el requisito contradice la realidad. Esa persona pasa por adquisiciones. No pasa a producción.

La IA no es el problema. Es el amplificador.

El reflejo actual es culpar a la IA de hacer que los desarrolladores sean innecesarios. Esa narrativa es cómoda para los ejecutivos que de todos modos querían que el desarrollo fuera más barato. También es incorrecta.

La IA hace peligrosos a los grandes desarrolladores, en el mejor sentido. Un desarrollador con profundo entendimiento de sistemas, décadas de reconocimiento de patrones y verdadera maestría artesanal puede ahora moverse a una velocidad que antes requería un equipo pequeño. La IA maneja el código repetitivo, la búsqueda de sintaxis, el andamiaje, la refactorización del primer borrador. Lo que queda es el trabajo de juicio. Y ahí es exactamente donde sobresalen los desarrolladores experimentados.

Para alguien sin esa profundidad, la IA es igualmente aceleradora, directamente hacia un desastre más sofisticado. La herramienta no distingue entre una buena decisión arquitectónica y una terrible. Felizmente generará miles de líneas de código erróneo con confianza si nadie con comprensión real está dirigiendo.

Esto significa que la brecha entre un desarrollador fuerte con IA y un desarrollador débil con IA no se está reduciendo. Está creciendo. Explosivamente. El maestro del oficio que tu filtro rechazó hace tres meses ahora entregaría más valor que todo el equipo de coincidencias de palabras clave aprobadas por ATS que contrataste en su lugar.

Y la tragedia es visible desde fuera. Las empresas que necesitan desesperadamente exactamente ese tipo de juicio experimentado miran hacia otro lado porque la conversación gerencial ha sido capturada por dos falsas narrativas simultáneamente: la historia de la escasez de talento que excusa el filtro roto, y la historia de que la IA reemplaza a los desarrolladores que excusa no invertir en absoluto en experiencia humana.

La verdadera pregunta para el liderazgo

Si tu organización solo puede invertir en la experiencia de los desarrolladores cuando un marco lo pone de moda, ya has respondido a la pregunta sobre si valoras a tu gente. No lo haces. Valoras el cumplimiento de lo que exija la narrativa actual de la industria.

La verdadera inversión se ve diferente. Se ve así:

• Financiar el tiempo de aprendizaje sin requerir un programa de marca para justificarlo.
• Permitir que desarrolladores experimentados sean mentores de júniors sin fingir que eso es un desperdicio.
• Contratar por juicio y rango en lugar de por simetría de palabras clave.
• Darle autoridad sobre las decisiones técnicas al personal técnico sin requerir una iniciativa de transformación que la otorgue.
• Mantener a los equipos estables el tiempo suficiente para construir contexto en lugar de rotar contratistas cada seis meses.
• Reconocer que la conversación sobre la IA no se trata de reemplazar desarrolladores, sino de darles mayor ventaja a los más fuertes.
• Abandonar la etiqueta de prima donna y escuchar cuando el personal técnico explica por qué algo no funcionará.
• Detener la pretensión de que el software es una función de soporte cuando es aquello a través de lo cual tu empresa realmente vende, opera o compite.

Nada de eso requiere un framework. Nada de eso requiere una certificación. Nada de eso requiere un modelo de madurez, un compromiso de consultoría o una ponencia de conferencia para legitimarlo.

Requiere un liderazgo que crea que su propia gente merece inversión como condición predeterminada de empleo, no como recompensa por sobrevivir al último ciclo de moda organizacional. Requiere admitir que la clasificación política del software como soporte de TI siempre fue una ficción conveniente que permitió a los tomadores de decisiones evitar aprender de qué depende realmente la empresa.

Los maestros del oficio están ahí fuera. Algunos de ellos ya están dentro de su organización, subutilizados, sin ser escuchados y calificados en silencio como difíciles porque siguen diciendo cosas que no quieres saber. Algunos de ellos se postularon el mes pasado y tu ATS los rechazó. Algunos de ellos dejaron de postularse a empresas como la tuya porque el filtro dejó claro que no eran deseados.

La IA no creó este problema. Lo hizo más costoso de ignorar.