[High-Performance Team] Cultura, Prácticas Técnicas y Reflexiones (Parte 3/3)

[High-Performance Team] Cultura, Prácticas Técnicas y Reflexiones (Parte 3/3)

---

En la Parte 1/3 cubrí el diagnóstico y el framework de 5 pilares. En la Parte 2/3, el diseño de equipos y la consolidación del stack. Ahora viene la sección que hace que todo lo anterior funcione en la práctica: la cultura y las prácticas técnicas.

Puedes tener el framework perfecto y el equipo ideal, pero sin una cultura definida y práctica, se desmorona en semanas. La cultura no se declara — se diseña.

Principios de Cultura

Async First

Trabajo asíncrono por defecto, reuniones solo cuando son estrictamente necesarias. La documentación escrita reemplaza la mayoría de los syncs.

Esto no es solo una preferencia — es una decisión de diseño. Con un equipo distribuido y un horario sync de 6+ horas, las reuniones se convierten en el cuello de botella más caro que existe. Cada hora de meeting con 5 personas son 5 horas-ingeniero. Un documento bien escrito cuesta 1 hora y escala infinitamente.

Radical Candor

Transparencia y comunicación directa. Feedback honesto, sin politiquería ni agendas ocultas.

En la práctica: si algo no funciona, se dice. Si alguien no está rindiendo, se habla directamente. Si una decisión técnica fue mala, se reconoce y se corrige. Sin rodeos, sin CYA emails, sin “lo discutimos offline” que nunca se discute.

Autonomía Real

Cada developer es un programador completo: desarrollo, infraestructura, base de datos. Con los permisos y accesos necesarios para ejecutar sin depender de otros equipos para cada operación.

Este punto es crítico y es donde la mayoría de las organizaciones fallan. Piden ownership pero no dan acceso. Exigen velocidad pero requieren 3 aprobaciones para hacer un deploy. Si quieres autonomía, tienes que dar los permisos que la habilitan.

OKRs y KPIs Claros

Objetivos definidos a nivel de ingeniería y por equipo. Cada persona sabe exactamente qué se espera y cómo se mide. Sin ambigüedades.

Actitud

Colaboración, enfoque en negocio, mentalidad emprendedora, doers, autogestión. No es un listado aspiracional — es el estándar que define cómo opera el equipo.

Crecimiento Continuo

Seguir aprendiendo y mejorando de forma incremental. Evitar el “así lo hemos hecho siempre” como justificación para no cambiar.

Prácticas Técnicas

Práctica	Estándar
Git	Trunk-Based Development
Code Review	Proceso estandarizado de evaluación
Coverage	>80% por proyecto
Documentación	Obligatoria para cada feature y arquitectura nueva
Permisos	Acceso completo a herramientas del flujo para todos los devs
Lenguajes	Golang / Python primordialmente
Arquitectura	Monolith First, diseños simples y escalables
Monitoreo	Dashboards y alertas por equipo, ownership directo
Entornos	Staging ≈ Production, ambos funcionales
Calidad	Cada dev/equipo es responsable de sus entregables
CD	GitHub Actions
CI	Code quality tools + tests de integración y unitarios
Guardias	24/7, documentadas
Servicios externos	Requieren documento de validación y presentación formal
Metodología	Scrum (sprints de 15 días), estimación estandarizada
Reuniones	MBR + All-hands mensual

Cada práctica está ahí por una razón. No es un checklist aspiracional — es el estándar mínimo. Si un proyecto no tiene >80% de coverage, no está listo. Si un feature no tiene documentación, no está terminado.

El Principio de Monolith First

Quiero detenerme en este punto porque es contra-intuitivo para muchos.

En una empresa con 160 microservicios donde solo 66 se usaban activamente, la respuesta no era más microservicios — era consolidar. Diseños simples, escalables, validados de forma conjunta por el equipo antes de implementarse.

No es que los microservicios sean malos. Es que son una herramienta, no una religión. Y cuando tienes un equipo compacto, no puedes mantener 160 servicios independientes. Las matemáticas no dan.

Monolith First significa: empieza simple, separa cuando tengas evidencia de que necesitas separar. No al revés. La complejidad distribuida tiene un costo que la mayoría de los equipos subestiman hasta que ya es demasiado tarde.

Problemas que el Framework Debía Resolver

Parte del análisis incluyó documentar los problemas existentes:

1. Falta de documentación — Proyectos enteros sin documentación técnica, decisiones de arquitectura sin registrar, procesos tribales que vivían en la cabeza de una persona.
2. Falta de alineación — Cada equipo trabajaba de forma diferente: distintas herramientas, distintos procesos, distintas definiciones de “terminado.”

Estos dos problemas eran la raíz de muchos otros. Sin documentación, el conocimiento se pierde con cada persona que se va. Sin alineación, escalar procesos es imposible.

Reflexiones Finales

Este framework no es perfecto ni universal. Nació de un contexto específico — una FinTech en LatAm donde el equipo de ingeniería trabajaba aislado del negocio, sin foco en producto ni métricas de impacto. No existía un equipo cohesivo como tal — eran grupos de personas trabajando en paralelo sin alineación. El reto no era solo optimizar, sino construir un equipo real por primera vez.

Los principios subyacentes son adaptables:

1. Mide antes de cortar — Mapea todo tu scope antes de tomar decisiones de equipo.
2. Menos es más — Un equipo pequeño y senior supera a un equipo grande y junior.
3. La autonomía requiere permisos reales — No puedes pedir ownership sin dar acceso.
4. Consolida antes de construir — Si tienes 160 servicios y usas 66, tu primer proyecto es consolidar, no crear el servicio 161.
5. Diseña la cultura, no la declares — Un documento de valores en la pared no cambia comportamientos. Prácticas concretas y medibles sí.

Lo comparto porque creo que este tipo de conocimiento no debería quedarse guardado en un Excel que nadie va a volver a abrir. Si estás en una posición similar — liderando ingeniería en una startup que necesita hacer más con menos — espero que algo de esto te sirva.