¿Es loco pensar que Python podría ser el idioma que managers y developers hablan por fin en la misma reunión?
Dos idiomas, una reunión
En consultora vi el mismo patrón repetirse durante años. El manager vendía un scope al cliente prometiendo features que no había consultado con el equipo. El developer recibía el ticket sin contexto, lo resolvía, y después tenía que explicar por qué la estimación original era imposible. Los dos tenían razón. Los dos se hablaban en idiomas distintos.
Lo que el manager no veía
La cultura de management en software se construyó sobre Scrum, sprints y velocity points. El manager era el que negociaba scope, protegía al equipo de cambios de último minuto y traducía lo técnico en fechas para el cliente. El cliente pedía fechas porque necesitaba saber cuánto tardaba en entrar al mercado y cuánto le iba a regresar lo que invertía. El manager convertía esa presión en deadlines para el equipo. Sabía cuánto tardaban en entregar, pero no entendía qué estaban construyendo.
Lo que el developer no decía
El developer vivía en GitHub, Stack Overflow y la terminal. Su identidad estaba en el código, no en las diapositivas. Medía su valor en PRs mergeados, sprint points liberados, cuánto trabajo entregaba a comparación de sus compañeros, cuán competitivo era. No en features prometidos.
Pero esa misma burbuja lo aislaba del negocio: podía construir cualquier cosa, menos explicar por qué importaba. En Arkus eso se sentía más fuerte. El developer era un recurso que se asignaba por ticket, no un socio que participaba en la decisión, por más que se dijeran las típicas frases de: "Somos una familia", "Debemos trabajar bajo la misma cultura", "Unamonos para llegar a la misma meta".
Cuando la herramienta cambió, la conversación no
Cuando llegaron las herramientas de AI, la entrada de GitHub Copilot, ChatGPT, Claude Code, etc., la brecha no se cerró, se amplió. Los managers empezaron a pedir "automatizar todo" sin entender qué significaba. Los developers veían cómo sus herramientas se volvían accesibles para cualquiera, pero la conversación entre ambos seguía siendo la misma: uno pedía fechas, el otro daba excusas. La distancia nunca es un SKILL.md, es un contexto compartido.
Un idioma que ambos pueden leer
Python es el idioma donde estos dos mundos, o mas, pueden encontrarse. No porque los managers deban escribir código de producción, sino porque necesitan leer lo que su equipo construye. Un manager que puede seguir un script de pandas, entender un notebook de análisis o cuestionar una estimación técnica no está haciendo el trabajo del developer, está haciendo el suyo mejor. La pregunta nunca fue "¿deberían los managers programar?" La pregunta es "¿cómo hablan el mismo idioma sin que uno deje de ser lo que es?"
Referencias
- James Stanier, Should managers still code? (The Engineering Manager, feb. 2025)
- Kelly Vaughn, Should Engineering Managers Be Writing Code at Work? (The Modern Leader, dic. 2025)
- Anees Merchant, What Senior Leaders Get Wrong About Learning to Code in 2026 (may 2026)
- Jim Grey, The player/coach trap: why Engineering Managers shouldn't be expected to code (mar. 2026)
- Lee McKeeman, Should Managers Code? (Substack, abr. 2024)
- Panayiotis Kritiotis, Staying Technical as an Engineering Manager (may 2026)
- Piergiorgio Niero, Should Engineering Managers Still Code? Wrong Question. (Substack, nov. 2025)
- r/EngineeringManagers, Everyone's framing this as binary: managers who code vs managers who don't (jul. 2026)
- Josef Cruz, Why Managers Should Learn Python Even if They Are Not Programmers (mar. 2023)
- AI Tutor Code, Should Product Managers Learn to Code (or Python)? (jul. 2026)
- V8 Global, When a Senior Leader Dismisses Python, That's the Signal (abr. 2026)
- Columbia Business School, Python for Managers (Online)
- Kit France, Learning to programme as a Product Manager (part 1) (jun. 2025)