Las decisiones de arquitectura se quedan en los diagramas
El equipo resuelve cada tarea con criterios diferentes porque las decisiones no llegan al trabajo diario.
Liderazgo técnico.
Llevo la arquitectura al código, al despliegue y a la operación con el equipo.
Convierto las decisiones tecnológicas relevantes en criterios que el equipo puede aplicar y comprobar. Explico el contexto, reviso cómo se ejecuta la decisión y evito que el conocimiento quede concentrado en una sola persona.
Dónde se concentra la complejidad
El liderazgo técnico se vuelve crítico cuando la forma de coordinarse ya afecta al producto.
El problema se reconoce en decisiones contradictorias, revisiones tardías y deuda técnica de la que nadie se hace cargo. Con el tiempo, la operación deja al equipo cada vez menos tiempo para mejorar el producto.
El proyecto avanza con demasiadas incógnitas críticas
Las dependencias, las integraciones y las restricciones operativas se descubren cuando cambiar ya resulta caro.
La calidad depende de intervenciones de última hora
Faltan contratos, pruebas, observabilidad y un criterio de finalización que incluya comprobar el comportamiento en producción.
El conocimiento está concentrado
Dos o tres personas concentran el conocimiento sobre las decisiones, los diagnósticos y los despliegues. El resto del equipo no puede explicarlos.
Los equipos de producto y tecnología negocian tarea a tarea
Cada área utiliza criterios distintos para valorar el trabajo, ordenar las prioridades y decidir qué deuda y qué riesgo puede asumir.
Las responsabilidades entre proveedores y equipos están difusas
Al delegar el trabajo, la organización puede haber cedido también parte del criterio necesario para gobernar su propia plataforma.
Alrededor del equipo
Qué preparo para que el criterio del equipo no dependa de mí.
No considero bien dirigido un equipo que solo trabaja bien en presencia de quien lo lidera. Dejo estas prácticas preparadas para que el equipo mantenga el criterio cuando yo no estoy.
Formación y crecimiento del equipo
Llevo años montando equipos de desarrollo desde cero y haciendo crecer a los que ya existían. Reviso el código y explico por qué, en lugar de limitarme a señalar qué falla. También reparto las decisiones difíciles en vez de reservármelas, para que el equipo aprenda a tomarlas conmigo.
- Formación de equipos
- Revisión de código como enseñanza
- Reparto de decisiones
- Acompañamiento técnico
- Relevo preparado
Integración y entrega continuas
Configuro las mismas comprobaciones automáticas para cada cambio antes de que el equipo lo revise: pruebas, estilo, análisis del código y seguridad. Automatizo lo repetible para que el equipo concentre las revisiones en los fallos, las excepciones y las decisiones que exigen criterio. El equipo mantiene las reglas de esas comprobaciones y sus umbrales.
- Comprobaciones en cada cambio
- Pruebas automatizadas
- Análisis estático
- Despliegue repetible
- Capacidad de revertir
Documento las decisiones y dejo rastro del trabajo
Soy procedimental por convicción, no por burocracia. Documento cada decisión relevante, con su contexto y las alternativas descartadas, y trazo el recorrido desde la necesidad hasta el cambio que la resolvió. Así, otra persona puede reconstruirla tiempo después sin depender de la memoria de quien la tomó.
- Decisiones documentadas
- Trazabilidad del trabajo
- Procedimientos repetibles
- Documentación que se actualiza con cada cambio
- Herramientas de gestión como soporte
Criterios de calidad verificables
Convierto los criterios de calidad en comprobaciones y acordamos en el equipo el umbral que deben alcanzar: pasan o no pasan. No dejo la calidad en una intención compartida, porque corre el riesgo de ceder ante una fecha de entrega apretada.
- Criterios de aceptación
- Umbral acordado
- Deuda visible
- Revisión desde perspectivas complementarias
Coordinación con quienes definen la solución y con proveedores
Concilio lo que necesitan quienes definen la solución con lo que permite la plataforma. Superviso el trabajo externo con los mismos criterios que aplico al interno. Aunque delegue la construcción, mantengo el criterio para juzgarla.
- Interlocución con producto
- Supervisión de proveedores
- Criterios de aceptación externos
- Reparto de responsabilidades
Aprendizaje a partir de lo que pasa en producción
Reviso los incidentes y busco la causa en el sistema y en el proceso, no en la persona que desplegó. De cada uno extraigo una decisión documentada: introducir una comprobación o un límite, cambiar la arquitectura, aceptar el riesgo o recabar más evidencia antes de actuar.
- Revisión de incidentes
- Causa en el sistema
- Métricas de entrega
- Mejora comprobable
Responsabilidades concretas
Doy al equipo el contexto y los criterios que necesita para decidir bien.
Me hago cargo de la arquitectura, la calidad, la entrega, la observabilidad y la seguridad junto al equipo y al área de producto. Comparto el razonamiento y reparto la capacidad de decisión para evitar que todo dependa de una sola persona.
Decisiones de arquitectura
Concreto límites, contratos y alternativas, y documento el contexto necesario para revisarlos después.
Dirección técnica de la entrega
Identifico dependencias, ordeno el trabajo según el riesgo y resuelvo pronto las incógnitas que podrían invalidar la solución.
Calidad de ingeniería
Integro las pruebas, la seguridad, la revisión, la observabilidad y la mantenibilidad en el trabajo habitual del equipo.
Desarrollo de equipos
Establezco criterios, comparto el razonamiento y reparto la capacidad de decisión para evitar una cola de aprobaciones.
Coordinación técnica
Coordino a quienes responden del producto, el desarrollo, la plataforma, los datos y la seguridad, incluidos los proveedores cuando intervienen.
Operación y aprendizaje
Utilizo los incidentes, las métricas y el comportamiento real para mejorar la arquitectura y la manera en que el equipo prepara y pone en producción los cambios.
Cómo trabajo
Me ocupo tanto de la entrega como de las conversaciones técnicas que la hacen posible.
El código, las pruebas y la automatización son parte del trabajo. También lo son unos límites de responsabilidad comprensibles y la capacidad de resolver un desacuerdo técnico antes de que genere retrabajo.
- 01
Dar contexto
El equipo entiende el problema, el resultado esperado y las restricciones antes de elegir la solución.
- 02
Reducir incertidumbre
Uso pruebas técnicas, prototipos y contratos para resolver pronto lo que podría invalidar el diseño.
- 03
Hacer visible la calidad
Los criterios se convierten en pruebas, revisiones, métricas y señales que el equipo puede observar.
- 04
Transferir criterio
Documento las decisiones y trabajo con el equipo para incorporarlas a su práctica. Después compruebo, ante decisiones nuevas, si puede aplicar el criterio sin depender de mí.
Recorrido profesional
He ejercido el liderazgo desde dentro de los equipos y con responsabilidad sobre producto, plataforma e infraestructura.
Ver trayectoria y perfil- Trayectoria construida desde el desarrollo de software hasta la arquitectura y la dirección tecnológica.
- Experiencia en la toma de decisiones y en la dirección de equipos y proyectos para plataformas que deben seguir operando mientras evolucionan.
- Experiencia práctica en el desarrollo de servicios e interfaces y en el trabajo con API, nube, DevOps, seguridad, rendimiento y observabilidad.
- Especialización en EdTech, un dominio donde el producto, la operación y la ingeniería están estrechamente conectados.
Marcos propios
Estos marcos ayudan a revisar la arquitectura, las integraciones y la capacidad de entrega.
Al documentar los criterios, el equipo puede enseñarlos, discutirlos y mejorarlos sin depender de la memoria de unas pocas personas.
Ver la colección completa01Arquitectura de referencia
Arquitectura de referencia para un ecosistema de aprendizaje
Ayuda al equipo a entender qué sistema o equipo asume cada responsabilidad y qué decisiones deben coordinarse entre varias áreas.
Consultar la arquitectura del ecosistema de aprendizaje ↗02Lista de evaluación
Marco de evaluación de integraciones EdTech
Convierte la calidad de una integración en contratos, pruebas y señales que el equipo puede revisar durante la entrega.
Consultar el marco de integraciones EdTech ↗Blog
En el blog explico las decisiones técnicas y sus consecuencias.
También escribo sobre liderazgo técnico, arquitectura, calidad, dirección de proyectos y trabajo con equipos.
Contacto
Entregar con regularidad no basta si el sistema pierde capacidad de evolución.
El liderazgo técnico relaciona las decisiones diarias con la arquitectura, la deuda, la operación y el conocimiento que conserva el equipo.