Lo que solía significar el coaching técnico

Entrevistador

Usted fue presentado en Whitaker Payroll como —y cito textualmente un expediente judicial— «un tipo que es bueno para escribir código». ¿Cómo llegó exactamente allí?

Ethan Carter

Preston Hale hizo la presentación. Él es un autor de temas de gestión: tres bestsellers, conferencias magistrales, todo ese circuito. Preston y Graham Whitaker se conocían de comités de recaudación de fondos. Graham había heredado la empresa tras la muerte de sus padres y nunca llegó a comprender la parte técnica. Nathan Cole, el desarrollador principal, sostenía todo el sistema prácticamente solo y llevaba años pidiendo ayuda. Preston nos puso en contacto.

Envié los documentos de contratación que describían el rol, el enfoque y el alcance de mi trabajo. Quedaron sin leer. Graham se limitó a decir «trabaja con Nathan» y regresó a sus galerías de arte. No lo conocí en persona sino hasta el día en que me despidieron por segunda vez.

Eso suena como un pequeño detalle, pero es toda la historia. Si el dueño te define únicamente como mano de obra ejecutable, cualquier muestra de criterio propio se convierte en una intrusión. Eres bienvenido para teclear, pero no estás invitado a pensar.

Entrevistador

¿Qué fue lo que hizo allí concretamente?

Ethan Carter

Introduje el desarrollo guiado por pruebas (TDD) y la integración continua (CI) en un sistema que dependía de lotes nocturnos de COBOL y clientes de escritorio en VB6. Nathan y yo construimos un arnés de pruebas (test harness), luego utilizamos extracción asistida por un modelo de IA para extraer las reglas de negocio del COBOL y convertirlas en miles de pruebas ejecutables en C#. Por primera vez en décadas, alguien podía demostrar con hechos lo que los lotes realmente estaban haciendo, en comparación con lo que la gente asumía que hacían.

Las discrepancias eran enormes. Lógicas de retención de impuestos que llevaban años arrojando cifras incorrectas en múltiples estados y localidades. No hablo de teorías, sino de ejecuciones reales comparadas contra los datos históricos de salida. Todo plenamente verificable.

Y ahí fue donde empezaron los problemas. Porque demostrar que el sistema fallaba significaba demostrar que las personas cuya identidad dependía de que el sistema fuera infalible también estaban equivocadas. Y ese no era en absoluto un problema técnico.

Entrevistador

Usted insiste mucho en el concepto de «coaching técnico». La mayoría de la gente escucha la palabra «coach» y piensa en alguien que facilita reuniones diarias (stand-ups) y retrospectivas. ¿Qué solía significar realmente ese rol?

Ethan Carter

Significaba ayudar a un equipo a construir mejor software mediante un feedback más rápido, hábitos técnicos más sólidos y una conexión mucho más firme entre el criterio y la ejecución técnica. Programación en pareja (pairing), pruebas primero, integración continua y refactorización. Trabajar en pasos tan pequeños que cualquier malentendido se hiciera evidente un martes por la mañana, en lugar de revelarse en producción seis semanas después.

El centro de gravedad absoluto era la calidad: ¿puede el equipo saber a ciencia cierta si el sistema sigue funcionando?, ¿pueden modificarlo de manera segura?, ¿pueden obtener evidencias empíricas antes de que los fallos se acumulen de forma catastrófica?

A mediados de la década de 2000, muchas corporaciones descubrieron que se podía vender «coaching» sin necesidad de tocar una sola línea de código. Scrum Alliance comenzó a certificar Scrum Masters en 2002: un curso de dos días sin un solo requisito técnico de ingeniería. En pocos años, el mercado se inundó. Le quitaron la columna vertebral técnica a la agilidad. Lo que quedó fue moderación de procesos, amortiguación del impacto emocional urbano y tranquilidad gerencial a precio de descuento. Para 2009, profesionales como Robert Martin estaban tan alarmados que redactaron un manifiesto independiente —el Manifiesto por el Artesanato de Software— intentando devolver las prácticas de ingeniería al debate central. Esa versión vacía de ingeniería es mucho más fácil de comprar por las empresas porque nunca obliga a los líderes a financiar las partes incómodas y costosas: pruebas automatizadas, integración continua, refactorización, trabajo en parejas o el costo político de otorgar verdadera autoridad de decisión a los desarrolladores.

Entrevistador

Hay un conjunto de valores fundacionales a los que siempre apelan los profesionales de su sector. Individuos e interacciones sobre procesos. Software funcional sobre documentación. ¿Qué se rompió entre esos principios y lo que realmente ocurrió en Whitaker?

Ethan Carter

El manifiesto declaraba: si tu proceso empieza a obstaculizar la entrega de software funcional, ese proceso ya no es el adulto responsable en la sala. La gente escucha la palabra «sobre» y entiende «en lugar de». Esa lectura es completamente errónea. Es una declaración de prioridades, no un rechazo a la disciplina de trabajo.

Lo que hicieron Graham y Derek después de despedirme fue exactamente lo contrario. Impusieron un flujo de trabajo meramente burocrático: las expertas definen requisitos en Word, los desarrolladores pican código alineados con esos documentos, y la validación se certifica mediante firmas secuenciales de conformidad. Cinco cajitas limpias en un diagrama de flujo. Flechas perfectas. Ni una gota de sangre sobre el papel. Parecía un proceso maduro y profesional. Pero en realidad, era parálisis corporativa con modales más elegantes.

Porque las reglas verdaderas del sistema no estaban guardadas en la cabeza de nadie esperando el momento de ser redactadas. Existían puramente como décadas de comportamiento acumulado dentro del código en ejecución. Solo podías descubrirlas interactuando con el código vivo, volviendo a ejecutar las salidas y comparando. Eso era exactamente lo que hacía el arnés de pruebas de regresión. El proceso burocrático sustituyó ese ciclo continuo de feedback por papeleo estéril y lo denominó pomposamente gobernanza.

Entrevistador

¿Dónde encaja la Programación Extrema (XP)? Me refiero a las prácticas de ingeniería que ustedes aplicaban propiamente en Whitaker.

Ethan Carter

XP fue la respuesta contundente de la ingeniería. El manifiesto dio los valores y principios; XP aportó la mecánica de ejecución. Escribe la prueba primero. Integra constantemente tu código. Trabaja en parejas. Refactoriza mientras las pruebas permanezcan en verde. Realiza despliegues pequeños y continuos. Mantén los bucles de feedback lo suficientemente rápidos como para que la fantasía teórica nunca pueda superar la realidad del código en ejecución.

A todos los ejecutivos les fascina la idea abstracta de la adaptabilidad, hasta que les muestras cuánto cuesta verdaderamente implementarla. La adaptabilidad no es un cartel motivacional de mentalidad en la pared. Es una base de código estructurada capaz de aceptar cambios sin mentirle al equipo, sumada a unos profesionales a los que se les permite aprender y explorar abiertamente en público. Eso era exactamente lo que estaba construyendo junto a Nathan en Whitaker. Y funcionó de maravilla. Las pruebas estaban en verde, los pipelines de integración continua corrían sin fallos y la metodología de extracción automática escalaba. El inconveniente estructural nunca residió en la ingeniería en sí. El verdadero problema fue que un entorno de ingeniería transparente evidenció de golpe las flaquezas de la jerarquía.

Entrevistador

Todavía se habla mucho del histórico proyecto de nómina de Chrysler como prueba definitiva de que estas prácticas no son sostenibles en entornos corporativos reales. Usted llevó prácticas de tipo XP a otra compañía de nóminas y el resultado final también fue desastroso. ¿Hay un patrón subyacente?

Ethan Carter

El caso C3 en Chrysler es una de las historias peor tergiversadas de la informática. Kent Beck y Ron Jeffries colaboraron para introducir las técnicas fundamentales que luego se acuñaron como XP. El sistema operó en producción real para una plantilla concreta de empleados; pagó salarios de verdad. El problema real fue que la figura clave del cliente de negocio sufrió un desgaste insostenible (burnout), la posterior fusión con Daimler truncó el patrocinio directivo y las prioridades de la dirección cambiaron de rumbo. El proyecto se canceló. A partir de ahí, el folklore corporativo repitió que «XP había fracasado», simplemente porque esa deformación del relato preserva y protege la cultura de gestión mucho mejor que contar la incómoda realidad.

La realidad es mucho más cruda. La disciplina rigurosa de ingeniería fue lo único capaz de llevar a producción con éxito un proyecto de nómina que venía desahuciado por el desorden técnico previo, y aun así la empresa optó por un destino meramente político y de complacencia interna. Eso fue exactamente lo que ocurrió también en Whitaker. La ingeniería funcionó perfectamente y las pruebas acumulaban evidencias indiscutibles de su éxito. Graham se sentó frente a mí y vio con sus propios ojos las ramas del repositorio que corregían errores históricos de retenciones impositivas equivocadas. Vio la evidencia. Y luego decidió conscientemente que era más prioritario proteger la reputación y confort de las personas cuyas jerarquías laborales dependían de mantener la farsa de que los números anteriores eran correctos.

El patrón recurrente no es en absoluto que las prácticas estructuradas de ingeniería fracasen sistemáticamente en las organizaciones corporativas reales. El patrón real es que, a veces, las organizaciones reales prefieren conscientemente el colapso absoluto antes que tolerar la alteración de su statu quo que el éxito les exigiría.

Entrevistador

Hablemos de Preston Hale, a quien mencionó antes. Él suele encabezar importantes congresos de agilidad discursando extensamente sobre equipos autogestionados y alta autonomía.

Ethan Carter

En el escenario, Preston era un visionario de la liberación del potencial humano. Exhortaba a confiar plenamente en las personas, a firmar la muerte definitiva del mando y control clásico, y a creer que los equipos de alta autonomía superaban siempre a los verticalmente gestionados. El público asistente tomaba notas de sus palabras como si de escrituras sagradas se tratase.

No obstante, detrás de puertas cerradas, le aconsejaba enfáticamente a Graham mantener a los programadores bajo rienda muy corta. Sus palabras textuales, según me relató Nathan más tarde, fueron: «Rienda corta, Graham. La gente da su mejor rendimiento técnico cuando tiene perfectamente claro dónde está el límite del perímetro de su cerca. No les des margen de maniobra para improvisar».

El mismo individuo. El mismo mes. Le vendía fantasías de autonomía romántica al público que consume y compra sus libros, mientras le facturaba rígidos esquemas de control centralizado al cliente que financiaba sus consultorías directas. Danny Kovacs —un gran colega mío de profesión— lo resumió magistralmente como la gestión de un establo de ganado implementando el vocabulario sofisticado de una charla TED. Personalmente, nunca he escuchado una analogía más precisa.

Entrevistador

A usted lo despidieron en dos ocasiones distintas dentro de la misma compañía. Explíquenos detalladamente el mecanismo social detrás de eso.

Ethan Carter

El primer incidente ocurrió estando a solas en una sesión de trabajo con el vicepresidente Derek Lawson, ya que Nathan tuvo que ausentarse de urgencia por un fallo en producción. Yo le expuse a Derek las evidencias incuestionables de un cálculo de impuestos erróneo que afectaba a la zona metropolitana de Detroit. Datos reales de regresión. En lugar de priorizar el problema operativo, Derek interpretó mi diagnóstico transparente como un acto intolerable de insubordinación técnica proveniente de alguien que carecía de rango o jerarquía corporativa en el organigrama. Inmediatamente redactó una nota presupuestaria para cancelar mi acceso a los repositorios. La elegante jerga que utilizó fue algo así como «falta de adecuación de alcance y gobernanza en el marco del soporte externo». Una abstracción conceptual de triple capa. Ni un solo verbo directo que alguien pudiera apelar razonablemente en el departamento de Recursos Humanos.

Posteriormente, Nathan logró reincorporarme bajo unas condiciones de consultoría externa extraordinariamente temporales. Durante dos frenéticas semanas intensivas de trabajo, utilicé la extracción automatizada asistida por IA para convertir la indescifrable maraña de COBOL clásico en miles de especificaciones ejecutables. El funcionamiento real del sistema se hizo visible con absoluta nitidez por primera vez en toda la historia corporativa de la empresa. Esa transparencia generó pánico en todos aquellos profesionales cuya subsistencia dependía de preservar la opacidad del legado técnico —y no lo menciono en absoluto con tono despectivo o de superioridad—. Linda, Sharon, Donna, las expertas locales del negocio, no conspiraban por maldad innata. Eran profesionales que rondaban los cincuenta años, cuya vida laboral útil se había ido estrechando tanto con el tiempo que el conocimiento y folklore organizativo era a la vez su mayor ventaja competitiva y su propia trampa de obsolescencia. En el instante en que nuestra metodología de refinamiento automático comenzó a drenar el foso defensivo que rodeaba su castillo de especialización, su legítimo pánico se canalizó en una sutil resistencia institucionalizada.

El segundo y definitivo despido provino directamente del puño y letra de Graham. Observó consternado las abrumadoras pruebas técnicas de las fallas de nómina, presenció el absoluto bloqueo defensivo de las expertas corporativas ante la realidad expuesta, vio a Derek amilanarse ante dicho bloqueo apoyando su resistencia, y concluyó que el camino hacia la armonía organizativa requería expeditamente erradicar la fuente original de toda esa incómoda agitación. El mensaje oficial dictaminaba: «A Graham le agradaría que el acceso del señor Ethan a la infraestructura quedase concluido de forma inmediata». Concluido. Como si mi cuenta de desarrollo estuviese redactando un relato de ficción literaria y simplemente hubiese arribado de modo natural a su desenlace predeterminado.

Entrevistador

Se percibe un patrón sumamente marcado en los expedientes judiciales: nadie toma ninguna decisión firme por sí mismo. Todos utilizan sistemáticamente la hesitación del resto como la justificación ideal para postergar su propia acción.

Ethan Carter

Exacto. El equipo de expertas de negocio se negaba a firmar formalmente que los cálculos vigentes estaban mal porque pretendían que fuese el vicepresidente Derek quien asumiera la responsabilidad de esa llamada crítica. A su vez, Derek se abstenía de desautorizar la reticencia de las expertas alegando que su falta de seguridad interna probaba que las evidencias empíricas no eran definitivas. Graham contemplaba cómo ambos estamentos titubeaban cruzados de brazos y concluía alegremente que el análisis de la base impositiva requería de mayor tiempo de estudio prudencial. Nadie tuvo la necesidad real de mentir descaradamente. Todos se limitaron, sencillamente, a continuar delegando y aplazando de forma perpetua su criterio ejecutivo.

Y ante esa coyuntura, la única persona que se atrevió a romper ese ciclo infinito de inacción compartida —quien pronunció de viva voz el primer diagnóstico real y sin tapujos— pasó a constituir instantáneamente la amenaza principal para la supervivencia colectiva. No porque mis datos o aserciones fuesen inválidos. Fue por el hecho de haber asumido la responsabilidad de emitir un juicio definitivo que ningún otro profesional en la organización tenía el coraje de manifestar, exponiendo con total claridad la vergonzosa parálisis preventiva de todo el resto.

Una cifra de negocio verificada provista por un empleado de rango en nómina interna se procesa como un hallazgo de extraordinario valor directivo. Esa exacta y calcada cifra provista de forma externa por un consultor independiente se califica como una mera sugerencia pretenciosa con delirios de grandeza. Idéntica información técnica. Peso sociopolítico radicalmente opuesto en la balanza de poder. Ese es exactamente el mecanismo organizacional en funcionamiento cotidiano. Y como ves, no requiere de una malicia perversa o maquiavélica; le basta plenamente con estar inserto en un sistema jerárquico que prioriza conceder muchísima más validez a la etiqueta social y al envoltorio que a la evidencia material de los hechos.

Entrevistador

¿Qué recomendación directa le daría a un director general al frente de una organización de similares características a la de Whitaker, que todavía no ha colisionado de frente contra la pared de la realidad?

Ethan Carter

Que lea minuciosamente las cartas de contratación y los términos de referencia antes de que el profesional cruce por primera vez el umbral de su puerta. Y no lo expreso como una metáfora. El hecho de que Graham hubiese dejado de lado sin leer el documento donde se definían mis atribuciones delimitó de antemano el encasillamiento invisible del rol: «No requiero comprender en detalle qué clase de servicios prestas ni tus credenciales porque tu criterio profesional no me es relevante». En el instante en que esa premisa inconsciente se asienta dentro de la cúpula, cualquier aporte técnico ulterior que exceda ese ajustado perímetro tácito pasa a ser considerado por la gerencia como una intromisión intolerable.

Si decides incorporar los servicios de un experto externo por su juicio y criterio técnico constructivo, proclámalo abiertamente ante todos. No mediante comentarios al pasar en el pasillo, sino de forma solemne y transparente en la sala de juntas donde están sentados el vicepresidente, las expertas de negocio y los desarrolladores técnicos. Haz explícita su legitimidad para actuar. De lo contrario, habrás cometido el gravísimo despropósito de contratar criterio analítico especializado para enrejarlo en una casilla preconfigurada como mano de obra operativa estandarizada. Y para colmo, terminarás despidiendo al profesional precisamente por responder como lo que realmente requerías con urgencia operativa, en lugar de actuar sumisamente alineado con la etiqueta banal con la que decidiste bautizarlo.

Mantén siempre a los desarrolladores y a los referentes de negocio insertos en un mismo ecosistema continuo de evidencias empíricas comprobables en producción. Evita a toda costa estructurar flujos secuenciales de relevo de postas donde un departamento aislado se limita a predefinir, otro diferente a picar código a ciegas, y un tercer grupo inconexo valida tarde y con pinzas meses después de haber culminado la escritura de los programas. Ese esquema solo sirve para proteger los privilegios jerárquicos de cada estamento, pagando el carísimo precio de estrangular la verdad técnica de tu producto.

Y también monitorea cuál es tu reacción en el instante en que se te presenta una evidencia técnica clara. Tan pronto como empiece a sentirse como un agravio o insulto personal, habrás entrado formalmente en zona de peligro. Graham vio números correctos en un monitor y los experimentó como una profanación al legado de su padre. Eso no es criterio de gestión de negocio; eso es duelo y luto patológico vistiendo un traje sastre. Y ninguna compañía puede sobrevivir basando sus decisiones sobre la melancolía del luto.