Cuando una empresa tecnológica inicia, quiere digitalizarse, o emprende un proyecto de base tecnológica sin el respaldo de una estructura adecuada para montar la maquinaria de producción (software y hardware), siempre surgen las preguntas: ¿Por dónde empezar? ¿Cómo construir una organización tecnológica que genere valor, ya sea en forma de activos tecnológicos que creen una nueva oferta en el mercado, o que reduzcan costos operativos mediante automatización y escalabilidad?

Eric Ries: “The only way to win is to learn faster than anyone else.”

Hay muchas fórmulas, muchos libros, mucha teoría; un sinfín de contenido en forma de pláticas, conferencias y artículos compartidos por los actuales gurús de la tecnología (piénsese en libros influyentes como The Lean Startup de Eric Ries o Measure What Matters de John Doerr ). La gran mayoría de estos materiales ofrecen consejos sobre liderazgo, organización de los insumos tecnológicos, implementación de metodologías de manejo de proyectos y técnicas para mejorar la calidad de los entregables. Otros hablan de tácticas para manejar el incesante flujo de peticiones tecnológicas de una organización con bajo presupuesto, o explican cómo formar un área o departamento tecnológico con presupuestos limitados.

John Doerr: “Ideas are easy. Execution is everything.”

Entre tanto contenido (a veces inflado por el deseo de vender más libros), tantos gurús que pasan la mayor parte de su tiempo dando conferencias sobre su “infalible” sistema, tantas culturas aplicadas de distinta manera en las organizaciones y tanto positivismo, es fácil perderse sin saber a quién o qué hacer caso. Como advierte John Doerr, “si tratamos de enfocarnos en todo, no nos enfocamos en nada”.

En muchos casos surgen contradicciones obvias entre las tácticas para crear tecnología de calidad y las múltiples estrategias de manejo de proyectos que aseguran que, si las seguimos, nunca entregaremos tarde. Mientras se cocina esta estampida imparable de metodologías, frameworks, trucos (lifehacks), reglas y títulos “disruptivos”, al interior de las organizaciones unos se atacan a otros discutiendo por creencias o posturas de distintos autores que se contradicen entre sí. Esta situación recuerda la afirmación de Fred Brooks de que “no existe un solo desarrollo, ni tecnológico ni de gestión, que por sí solo prometa siquiera una mejora de un orden de magnitud en productividad, fiabilidad o simplicidad” — es decir, no hay silver-bullet en desarrollo de software.

Fred Brooks: “Adding manpower to a late software project makes it later.”

Hay quien defiende el agilismo como si realmente cumpliera todo lo que promete, intentando implementar al pie de la letra todas y cada una de las herramientas que proponen Scrum, Kanban, Lean y demás autoproclamadas metodologías definitivas. La mayoría defiende conocimiento que no han generado ellos mismos, que han devorado ansiosamente esperando encontrar la respuesta al caos e incertidumbre que generan los proyectos tecnológicos sin éxito; y, por otro lado, lo hacen con completo desconocimiento de metodologías contrarias que en muchas ocasiones sugieren los mismos fundamentos pero con distintos diagramas, conceptos y hasta colores. Todo con el objetivo de lograr que, si la metodología se implementa perfectamente, no habrá retrasos, el cliente o stakeholder quedará 100% satisfecho y se evitará por completo cualquier molestia o imperfección durante el proceso.

Otros se enfrascan en discutir técnicas de libros enfocados en la limpieza del código, el pragmatismo de la arquitectura o la orientación a pruebas, criticando el código de los demás con frases como “no es lo suficientemente lean”, “le falta ser más pythonic”, “no sigue el principio KISS”, o preguntando “¿por qué no se empezó por las pruebas?”. Todo esto sin darse cuenta de lo incongruentes que son tales argumentos, lo lejos que están de entregar valor de negocio y, en muchos casos, la gran distracción que representan de una realidad que cuesta trabajo aceptar: el caos en los proyectos tecnológicos es inevitable.

Las discusiones inútiles en las organizaciones tecnológicas no terminan ahí. También los hay quienes critican o defienden acaloradamente un tipo de arquitectura sobre otra: algunos hablan de monolitos, mientras otros promueven a los microservicios como si fueran la panacea, y otros tantos se quejan de la “entropía” que conlleva administrar multitud de pequeños servicios. Peor aún, están los puristas que discuten incesantemente (a veces hasta llegar a la ira) sobre cuál sistema operativo es mejor, qué lenguaje de programación es superior, cuál circuito integrado es el óptimo o qué proveedor de nube es el ideal. Todo esto sin tomar en cuenta las necesidades del negocio, los problemas del usuario final, los deseos del cliente, el crecimiento del capital de los inversionistas y, sobre todo, la salud del equipo. (Por ejemplo, Eric Ries atribuye el fracaso de una de sus startups justamente a “trabajar desde la tecnología hacia adelante en lugar de partir de los resultados de negocio que se buscan lograr” ). Incluso los defensores de arquitecturas modernas reconocen límites: Martin Fowler señala que los microservicios, si bien útiles, incurren en una complejidad adicional que solo vale la pena en sistemas realmente grandes y complejos . En equipos pequeños, esa sobrecarga puede frenar el desarrollo, por lo que Fowler aboga por empezar con un monolito simple antes de escalar arquitectónicamente .

Martin Fowler: “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

Algunos colaboradores incluso incurren en comportamientos extremos por estas pasiones mal encauzadas. Habrá quien trabaje el doble solo para demostrar que su manera de hacer las cosas ahorra horas-hombre. Habrá también quien se desvele levantando pods y clusters que se cayeron en la madrugada, con tal de negar que la containerización puede fallar. Habrá quien rechace un trabajo bien pagado en una empresa que realmente busca lo mejor para él, simplemente porque allí no se programa utilizando Test Driven Development (TDD), Domain Driven Design (DDD) o arquitectura en capas. Incluso hay quien se niega a participar en un proyecto porque la distribución de Linux instalada en el servidor no es la que “ya conoce”.

Y al final, la entrega a tiempo de los proyectos, la capacidad de adaptación al cambio de los equipos y la capitalización de la tecnología terminan quedando en último lugar. ¡Luego se sorprenden cuando se cancelan los proyectos, cuando se decide convertir a la empresa en una más operativa y menos tecnológica, o cuando los inversionistas deciden no invertir más! De hecho, la realidad muestra que solo un ~16% de los proyectos de software logran finalizar con éxito (a tiempo y en presupuesto), mientras cerca del 31% terminan cancelados antes de completarse . No debería sorprendernos, pues, que las iniciativas fracasen si las prioridades están mal enfocadas.

Soy un fiel creyente de la empresa transparente y humana, y aunque algunas veces he caído en los vicios mencionados, siempre me apoyo en mis valores y en el talento de mis compañeros, metees y clientes para seguir enfocado. Este artículo es para quienes han logrado superar la ceguera de taller que da la pasión por lo que nos gusta (lo que conocemos) y el rechazo natural por lo que ignoramos.

¿Cómo hacer entonces para asegurar que, independientemente de los paradigmas utilizados, una organización tecnológica tenga éxito? ¿Cómo administrar las pasiones de un equipo eficiente de Tecnología que solo necesita un poco de dirección para alcanzar su máximo potencial?

La clave está en las personas. Primero que nada, hay que centrarse en la gente: el talento de las personas que conforman la organización, nuestros compañeros de trabajo. Hay que escucharlos y motivarlos, enfocándolos en lo que de verdad importa: ser felices, ser productivos, responsables, transparentes, humanos (en línea con el Manifiesto Ágil, que valora “individuos e interacciones sobre procesos y herramientas” ). Y luego, establecer una organización enfocada en cinco pasiones fundamentales: Calidad, Arquitectura, Agilidad, Ingeniería y Data.

Calidad

La calidad debe ser uno de los pilares principales en una organización tecnológica. Lamentablemente, en muchas ocasiones al intentar implementarla terminamos distribuyendo tareas que solo vuelven más burocrática a la organización. ¿Cuántas veces hemos descubierto, como usuarios, bugs garrafales en aplicaciones o sitios web de empresas que invierten más en testers de lo que invierten en capacitación? ¿Y cuántas veces hemos visto con desilusión parches obvios en nuestros videojuegos favoritos, creados por industrias más adineradas que el cine o las apuestas? En efecto, “la calidad no proviene de la inspección, sino de la mejora del proceso de producción” — no puedes inspeccionar la calidad al final; debes incorporarla desde el inicio.

Ya sea que se forme un equipo de Calidad dedicado a implantar los estándares que el mercado ha generado, o que se promueva por medio de consejos (councils) o equipos especializados (squads), la calidad nunca debe responder directamente al equipo de Ingeniería. No se puede ser juez y parte, y en muchos casos debería incluso separarse el rol de Calidad de las áreas de Tecnología, para que pueda ejercer auditorías y revisiones sin ningún tipo de conflicto de interés.

En los último años llevado esta visión a la práctica implementando un equipo de Calidad dentro del área de Tecnología, siempre guiados por nuestra pasión. En lugar de contratar testers únicamente para encontrar fallas al final del proceso, incorporamos al mejor talento para establecer desde el inicio las bases de una cultura apasionada por la calidad. Esto nos ha permitido aplicar un enfoque de Shift-Left en nuestra metodología DevOps, integrando la calidad desde las fases más tempranas del ciclo de desarrollo. Por ejemplo, con pruebas automatizadas y validaciones de código integradas en el pipeline de Integración Continua (CI/CD), de modo que cada nueva funcionalidad sea verificada automáticamente apenas se desarrolle, detectando posibles defectos de forma temprana. Con estos cambios de proceso y la participación anticipada de un equipo de Calidad más pequeño y eficiente, se puede evitar la tediosa dinámica de “probar y probar sin fin” y, en su lugar, construir software de calidad desde la concepción hasta la entrega.

Arquitectura

La arquitectura de sistemas es algo que siempre se lleva a cabo, sin importar el tamaño de la organización; es necesaria e inevitable. Siempre hay un proceso, aunque no esté formalizado, en donde alguien decide qué arquitectura tendrá un sistema, cómo optimizar la comunicación entre componentes y qué estándares seguir. En organizaciones muy pequeñas (menos de 20 desarrolladores, sin contar management ni análisis) no es posible ni viable tener un arquitecto dedicado, aunque alguien debe asumir necesariamente esa tarea para evitar problemas relacionados con la entropía del software y con flujos de comunicación deficientes, además de mantener al equipo orientado al negocio y actualizado en tecnología.

La necesidad de un arquitecto (o área de Arquitectura) depende de muchas variables; lo importante es inculcar esta pasión en el equipo, ya sea con un área formal, con una persona responsable o mediante una designación democrática, para asegurarnos de que la arquitectura esté siempre cubierta.

A lo largo de mi trayectoria, he tenido la oportunidad de diseñar e implementar equipos de Arquitectura en distintas organizaciones, siempre con el objetivo de garantizar que la tecnología esté alineada con la visión del negocio y con las necesidades del producto. Como arquitecto principal, he conformado equipos pequeños pero altamente capacitados, integrados por talento con una profunda comprensión de funcionalidades y arquitecturas de alto nivel. En varias ocasiones, he identificado dentro de los equipos de desarrollo a programadores con la capacidad de evolucionar hacia roles estratégicos, brindándoles formación para que puedan enfocarse en diseñar y simplificar, en lugar de quedar atrapados en la rutina del código diario. Además, he complementado estos equipos con analistas que no solo cumplen un rol técnico, sino que tienen la capacidad de conectar la arquitectura con la visión del negocio. Formar un área de Arquitectura efectiva no se trata solo de contratar expertos, sino de detectar y cultivar la pasión por la construcción de sistemas robustos y escalables dentro de la organización, empoderando a quienes tienen el potencial para asumir este desafío.

Agilidad

“Ágil” debe de ser una de las palabras más pronunciadas por los desarrolladores de software en todo el mundo actualmente. Y no solo por programadores; diseñadores, ejecutivos, operadores y demás involucrados en la creación de insumos tecnológicos la mencionan. Pero, ¿qué es agilidad, y cómo definimos este concepto tan abstracto y subjetivo?

Primero podemos definir qué NO es agilidad. Aunque este artículo no pretende dar al lector una definición precisa de Agilidad, podemos empezar por ahí:

Agilidad no es rapidez. La pasión por la agilidad constantemente se traduce en pasión por la rapidez al entregar, pero no es lo mismo entregar rápidamente que entregar ágilmente.

Un ejemplo lo ilustra: imaginemos un equipo de constructores de casas prefabricadas. Si levantan los requerimientos “rápidamente” y luego dedican los siguientes 8 meses a construir 10 casas, lo más probable es que cuando lleguen (temprano, sin duda) a instalarlas, muchas de esas casas no van a caber en los terrenos asignados o habrán omitido requisitos importantes (como dejar entradas para sillas de ruedas, o considerar que la parte trasera debe dar a un lago). Cientos de posibles detalles no se tomaron en cuenta porque estuvieron muy ocupados durante 8 meses yendo “rápido” en lugar de detenerse periódicamente a ofrecer pequeños entregables para que los stakeholders los orientasen. Posiblemente, cuando empezaron a construir, ese lago ni siquiera existía. Hubiera sido mejor ir entregando casa por casa, entregas constantes, revisando antes los bocetos de los planos, mejorando con cada iteración

Por eso hay que parar constantemente, entre sprint y sprint, para sacar la cabeza del lodo y entender si lo que vamos a construir en el siguiente ciclo es realmente lo que necesitan nuestros stakeholders, si no ha cambiado el mercado o las condiciones, o simplemente si no hubo nuevos descubrimientos durante esos meses.

Entonces, si agilidad no es rapidez, ¿qué es? Agilidad, en palabras simples, es la capacidad de cambiar rápidamente . Desarrollamos esa capacidad para poder ajustar el rumbo constantemente sin desviarnos demasiado, siempre alineados con las necesidades del negocio y con lo que los stakeholders identifican como valor, estando listos para tomar nuevos rumbos en caso de cambios radicales (como, por ejemplo, una pandemia).

He implementado equipos de Agilidad con un enfoque que va más allá de las oficinas de proyectos tradicionales. Mi objetivo siempre ha sido construir equipos capaces de adaptarse mejor al cambio, preparándose para lo inesperado y asegurando que la tecnología evolucione de manera alineada con el negocio. Para lograrlo, he diseñado procesos que permiten medir constantemente el desempeño de los equipos y la evolución de los proyectos, estructurando ciclos de desarrollo en sprints cortos de 2 semanas. Entre cada iteración, la clave es detenerse, levantar la cabeza y preguntar a los stakeholders si el rumbo sigue siendo el correcto. Esta mentalidad de mejora continua y retroalimentación constante ha sido fundamental en los equipos que he liderado, y está alineada con la filosofía de Scrum, descrita por Jeff Sutherland: al final de cada iteración, el equipo debe reflexionar sobre su proceso y preguntarse “¿qué podemos cambiar en nuestra forma de trabajar?” y “¿cuál es nuestro mayor obstáculo?”; si estas preguntas se responden con honestidad, el equipo “puede ir más rápido de lo que nadie imaginó”. Construir una cultura de agilidad no se trata solo de aplicar frameworks, sino de desarrollar un equipo con la capacidad de aprender, ajustar y evolucionar continuamente.

Jeff Sutherland: “Scrum is like your mother-in-law, it points out ALL your faults.”

Ingeniería

La descripción de la ingeniería es más simple de lo que parece, pero tendemos a complejizarla los mismos ingenieros. Podríamos decir que la pasión por la Ingeniería es la pasión por resolver problemas usando la intuición. Y no olvidemos que la intuición es simplemente otro nombre para las matemáticas; así como la programación es un tipo de matemática (también la estadística — Machine Learning — , la teoría de números en criptografía, y demás disciplinas relacionadas con la tecnología).

Entonces, un ingeniero es aquel que utiliza la intuición (las matemáticas) para resolver problemas. Luego entonces, la pasión por la Ingeniería es la pasión por resolver problemas que sólo pueden ser solucionados matemáticamente.

En muchas ocasiones, sin embargo, esta pasión nos juega en contra: nos gusta tanto resolver problemas complejos que tomamos cualquier problema simple y le encontramos complejidad. A esto le llamamos over-engineering, y es algo que los que desarrollamos tecnología tendemos a hacer mucho. Nos gana la pasión por resolver problemas donde no los hay y, de nuevo, nos olvidamos del objetivo final: el negocio, los stakeholders, el usuario. (Como bromeó el caricaturista Scott Adams, “los ingenieros resuelven problemas; si no hay problemas a la mano, ellos mismos los crean”).

Para poder usar la pasión por la Ingeniería a nuestro favor, solo tenemos que combinarla con otra pasión: la pasión por la simplicidad. Ingeniería simple, eso es lo que nos debe apasionar cuando hablamos de tecnología.

He tenido el privilegio de crear y liderar equipos de Ingeniería donde la pasión por resolver problemas ha sido el motor central. Aunque cada miembro del equipo pueda especializarse en áreas como frontend, backend, mobile, IoT, ML, Data o infraestructura, siempre he fomentado una mentalidad que prioriza la simplicidad y evita la complejidad innecesaria (over-engineering). Uno de mis principales enfoques ha sido instaurar organizaciones donde la tecnología no es un recurso centralizado en un grupo aislado de expertos, sino una herramienta accesible para toda la empresa. En los equipos que he conformado, el objetivo no es solo desarrollar software eficiente, sino también facilitar que otros dentro de la organización puedan comprender, utilizar y hasta mejorar la tecnología. Democratizar el acceso al conocimiento técnico empodera a los equipos y permite que la tecnología realmente agregue valor en todos los niveles del negocio.

Data

La Inteligencia Artificial (IA) y los Large Language Models (LLMs) están redefiniendo la manera en que las organizaciones utilizan los datos. Hoy, no basta con almacenar información; el verdadero valor está en la capacidad de convertir esos datos en conocimiento accionable, optimizando procesos, automatizando decisiones y anticipando tendencias. A lo largo de mi carrera, he liderado equipos de Data Science e IA, implementando modelos de Machine Learning (ML), procesamiento del lenguaje natural (NLP) y analítica avanzada para transformar datos en activos estratégicos.

En los equipos que he formado, la clave ha sido superar la dependencia de reportes estáticos, reemplazándolos por análisis en tiempo real, modelos predictivos y automatización de insights. La meta no es generar reportes por generar, sino estructurar un ecosistema donde cada área tenga acceso a datos relevantes para la toma de decisiones. En varias organizaciones, hemos logrado diseñar sistemas que entregan más métricas y reportes mensuales de los que hay personas en la empresa, asegurando una gestión basada en evidencia.

Sin embargo, trabajar con datos conlleva sus propios desafíos. Es fácil caer en la obsesión por obtener y almacenar datos sin propósito claro, o enfocarse exclusivamente en la visualización de datos (Business Intelligence, BI) sin validar la calidad y fiabilidad de las fuentes. También es común que los equipos de datos se enfoquen en aplicar algoritmos sofisticados — desde Machine Learning hasta Deep Learning — sin un entendimiento claro de cómo estos modelos impactan realmente el negocio. Un modelo predictivo que no responde a un problema real no agrega valor.

Por eso, he impulsado en mis equipos una cultura de datos que prioriza tres principios fundamentales:

1. Calidad sobre cantidad — Es preferible contar con menos datos, pero bien estructurados y verificados, que grandes volúmenes de información desorganizada.

2. Automatización inteligente — Integrar procesos de validación, transformación y análisis que reduzcan la carga manual y permitan la toma de decisiones en tiempo real.

3. Alineación con el negocio — La ciencia de datos no es un ejercicio académico, sino una herramienta estratégica. Los modelos de IA y ML deben estar directamente vinculados con los objetivos de negocio y necesidades de los usuarios.

En mi experiencia, una estrategia de datos exitosa no solo implica contratar analistas o científicos de datos, sino construir una cultura donde los datos sean un pilar clave de la operación y la toma de decisiones. La IA, los modelos generativos y la analítica avanzada no deben ser iniciativas aisladas, sino motores de transformación para toda la organización.

Negocio, usuarios, P&L, cliente

Como queramos llamarle, podemos (y debemos) apasionarnos con cualquiera de los pilares tecnológicos: Data, Ingeniería, Arquitectura, Calidad o Agilidad. Pero de nada servirá todo ello si no dejamos que nuestra pasión principal sea el cliente, el usuario, el negocio, el resultado financiero (P&L). En la teoría de Jobs To Be Done, Clayton Christensen enfatiza precisamente entender a fondo la lucha del cliente por progresar y crear la solución adecuada para ayudarlo a lograrlo . Después de todo, como señaló Eric Ries, “¿qué importaría que lo hayamos hecho a tiempo y en presupuesto, si al final nos encontramos construyendo algo que nadie quería?” .

Transformando la tecnología en valor real

He ayudado a organizaciones a estructurar equipos tecnológicos eficientes, optimizar procesos de desarrollo y maximizar el valor de sus datos. He trabajado en la implementación de arquitecturas escalables, estrategias de DevOps, metodologías ágiles y ciencia de datos aplicada, asegurando que la tecnología esté alineada con los objetivos del negocio.

Si tu empresa enfrenta desafíos tecnológicos, necesita fortalecer su infraestructura, mejorar su estrategia de datos o implementar IA y automatización de manera efectiva, puedo ayudarte. Desde la creación de equipos de ingeniería y arquitectura hasta la definición de estrategias de transformación digital y adopción de IA, mi enfoque se basa en soluciones prácticas, escalables y alineadas con el crecimiento del negocio.

Si estás buscando asesoría para mejorar la eficiencia de tu equipo tecnológico, migrar infraestructura a la nube, adoptar metodologías ágiles, implementar DevOps o transformar datos en conocimiento accionable, contáctame. Será un placer ayudarte a potenciar la innovación en tu organización.

1. Eric Ries: “The only way to win is to learn faster than anyone else.”

Eric Ries, The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses (New York: Crown Publishing, 2011), 193.

2. John Doerr: “Ideas are easy. Execution is everything.”

John Doerr, Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs (New York: Portfolio Penguin, 2018), 25.

3. Fred Brooks: “Adding manpower to a late software project makes it later.”

Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering (Reading, MA: Addison-Wesley, 1975), 25.

4. Martin Fowler: “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

Martin Fowler, Refactoring: Improving the Design of Existing Code (Reading, MA: Addison-Wesley, 1999), 15.

5. Jeff Sutherland: “Scrum is like your mother-in-law, it points out ALL your faults.”

Jeff Sutherland and J.J. Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time (New York: Crown Business, 2014), 45.

6. Clayton Christensen: “The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail.”

Clayton M. Christensen, The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail (Boston, MA: Harvard Business Review Press, 1997), 3.