Equipos humanos en DevOps

Cuando se habla de DevOps, lo técnico suele robarse el protagonismo, temas como automatización, CI/CD, contenedores e infraestructura como código son los más atractivos a la hora de escribir y explicar, de hecho la mayoría de nuestros blogs en fintech.works van por el lado técnico. Pero hay algo que muchos olvidan: DevOps sigue siendo un área humana.

Como toda disciplina donde es necesaria la gestión de personas, DevOps no se salva de tener que definir una cultura donde el crecimiento humano tenga que ir de la mano del crecimiento de herramientas, tecnologías e innovación.

Este lado humano se mejora con una cultura donde los equipos tienen voz, responsabilidad y espacio para crecer, en este punto damos un paso atrás y notamos que estas cualidades ya no son exclusivas del mundo DevOps y pueden aplicarse a cualquier área, sea del mundo de la informática o no, donde estén involucrados grupos de personas. En este artículo vamos a explorar los cuatro pilares humanos que hacen esta cultura posible, con ejemplos concretos y una guía para empezar a aplicarlos en el área DevOps.

Estos cuatro pilares no son los únicos que existen, el área de RRHH es una ciencia aparte que cuenta con sus propias técnicas para cada área, sin embargo, los que explicamos a continuación son aquellos que en nuestra experiencia son más compatibles con nuestra área de DevOps.

1. Colaboración

En DevOps, la colaboración no es un “nice to have”, es la base de todo. Implica romper los silos entre desarrollo, operaciones, QA, seguridad y negocio, para que todos apunten al mismo objetivo: entregar valor al usuario.

En equipos altamente técnicos es natural que las personas tiendan a enfocarse en sus temas particulares, lo cual no es malo, pero suele requerir líderes de equipo muy asertivos y atentos para mantener encaminado al equipo hacia un objetivo común, este tipo de dinámica entre equipos y líderes hace que el equipo pierda su capacidad de autogestión.

Ejemplo real:

En un proyecto bancario donde trabajamos anteriormente, desarrollo y operaciones vivían en canales de comunicación separados. Los incidentes tardaban horas en resolverse porque cada equipo investigaba por su lado. Se decidió implementar canales compartidos en Slack para cada servicio, con monitoreo visible para todos y reuniones semanales conjuntas. Resultado: menos tiempo en diagnósticos, más aprendizaje cruzado y una cultura más saludable.

2. Autonomía

Cuando los equipos pueden tomar decisiones técnicas, operar sus servicios y responder ante problemas, no solo se sienten más responsables: también se sienten más motivados. La autonomía genera compromiso.

Qué motivación tendría un equipo de desarrollo para mejorar la legibilidad de un log si este solo es utilizado por el equipo de producción? Esta pregunta puede sonar un poco fuerte, ya que sabemos que tener logs útiles son buenos para todos, pero sirve para ilustrar el caso que sufren equipos sin un norte común.

Ejemplo real:

Un equipo que desarrollaba una API crítica pasaba por múltiples aprobaciones manuales antes de cada deploy. Los tiempos se volvieron insostenibles. Se implementó un pipeline automatizado con pruebas y controles de calidad, y se delegó la responsabilidad de despliegue al mismo equipo. Eso no solo aceleró el flujo, sino que motivó a los desarrolladores a mejorar sus prácticas de testing y monitoreo.

3. Aprendizaje

Una cultura DevOps saludable necesita que los equipos tengan tiempo y espacio para aprender: sobre la plataforma, sobre nuevas herramientas, sobre errores del pasado. Sin aprendizaje, no hay mejora.

El área de DevOps vive en un mundo de infinita complejidad, rodeado del software compuesto por frameworks a su vez compuesto de miles de librerías, sistemas externos, bases de datos, interacciones externas de los usuarios e incluso amenazas de seguridad. Este mundo nos garantiza que tendremos que lidiar con problemas, por lo que es importante tener clara la expectativa que tendremos problemas pero cada uno nos debe hacer más fuertes.

Ejemplo real:

En un sistema con alta rotación de personal, los errores eran frecuentes porque la experiencia se perdía. Se comenzó a registrar postmortems con lecciones aprendidas y a realizar sesiones quincenales de “charlas internas” donde cada equipo compartía algo aprendido. En pocos meses, bajó la cantidad de incidentes repetidos y subió la calidad del onboarding de nuevos miembros.

4. Cultura

La moral del equipo no es solo un “clima laboral”. Es un reflejo directo de cómo se sienten las personas respecto a su trabajo, sus compañeros y su autonomía. Cuando hay buena cultura, hay mejores resultados.

En nuestra experiencia no existe una manera única de trabajar la cultura, equipos que se "sienten bien entre sí" lo logran por razones muy diferentes como:

1. Completar proyectos difíciles (superar dificultades)
2. Cambio del jefe (mejora de liderazgo)
3. Cambio de un colega tóxico (mejora del personal)
4. Cambio a una oficina más grande (mejora del ambiente)
5. Empezar proyectos interesantes (desafíos acordes al equipo)

Sientanse libres de agregar sus propios puntos ya que estamos seguros que cada uno conoce una razón diferente. Lo anterior hace que a primera vista sea difícil recomendar algo puntual para mejorar la cultura, pero si nos ponemos a analizarlos, nos damos cuenta que todos los puntos son "accionables", esto es, pueden ser tenidos en cuenta por un líder o el propio equipo para ser solucionados o en su defecto justificados. Pero para que esto ocurra, primero deben ser correctamente comunicados.

Y es aquí donde la "comunicación" se convierte en la base para mejorar la cultura. Cuando la comunicación es fluida en un equipo, ya sea sobre temas positivos o negativos, todos sus problemas se convierten en puntos claros listos para ser mejorados.

Para este punto en particular, podemos aprovechar el hecho de que ya existe un modelo ideal de comunicación de equipos aún vigente después de miles de años, este es el modelo de comunicación en una jerarquía militar. Este modelo funciona por estas razones:

1. Claridad absoluta en roles y responsabilidades

Cada persona sabe exactamente quién es su superior, a quién debe reportar y sobre qué temas. No hay confusión ni zonas grises.

2. Comunicación directa y concisa

Los mensajes son breves, claros y enfocados en la acción. Se evita la ambigüedad porque en situaciones críticas no hay tiempo para interpretar.

3. Protocolos definidos para transmitir información

Existen procedimientos claros de cómo informar órdenes, reportar problemas o pedir ayuda, lo que garantiza que el mensaje llegue rápido y sin deformaciones.

4. Fomento de la retroalimentación inmediata

En ambientes militares se espera (y se valora) el “informar hacia arriba” cuando hay un problema o duda. No se ocultan errores por miedo o vergüenza.

5. Prioridad al objetivo común sobre el ego personal

La comunicación no es para lucirse ni para defender intereses individuales; es para lograr una misión en conjunto. Eso elimina mucho ruido que en otros equipos suele trabar el flujo de información.

Aquí destacamos como este modelo de comunicación es ideal para identificar y ubicar problemas e incomodidades en el nivel correcto, estos puntos van subiendo por la cadena hasta encontrar al responsable, al ser una cadena "blameless" con niveles y responsabilidades bien definidas, el proceso es rápido y eficiente.

Ejemplo real:

En una startup que adoptó DevOps sin trabajar la parte humana, se implementaron pipelines automatizados, pero los equipos seguían culpándose entre sí ante errores. Luego de introducir blameless postmortems y líderes que promovían una comunicación abierta, la percepción del equipo cambió radicalmente. Más confianza, más colaboración, y menos miedo al error.

La sinergia entre los pilares

Estos cuatro aspectos no funcionan de forma aislada. Se potencian mutuamente.

1. La colaboración abre espacio para la autonomía, porque se entienden mejor las necesidades del otro.
2. La autonomía lleva a un aprendizaje más profundo, porque el equipo se ve obligado a enfrentarse a todo el ciclo de vida del software.
3. Y ese aprendizaje, si se comparte, mejora la cultura y refuerza la colaboración.

Cuando estos elementos se alinean, aparece un círculo virtuoso que mejora el equipo desde adentro.

Cuatro pasos simples para mejorar cada pilar

Si queremos aplicar estos conceptos a un equipo, no es necesario demasiado esfuerzo. Podemos empezar por cosas simples, medibles y con impacto.

1. Hacer visibles los problemas compartidos

Crear un dashboard o canal compartido con métricas clave (errores, tiempos de respuesta, incidentes). Que todos vean lo mismo.

Justificación: Promueve la colaboración y evita el juego de culpas.

2. Delegar una pequeña responsabilidad operativa al equipo de desarrollo

Por ejemplo: monitorear y responder ante fallas de su propio servicio.

Justificación: Aumenta el sentido de propiedad y fomenta el aprendizaje.

3. Incorporar una reunión retrospectiva o postmortem cada vez que algo sale mal

Sin buscar culpables. Enfoque en qué se aprendió y cómo evitarlo.

Justificación: Genera cultura de mejora continua y confianza.

4. Reservar tiempo mensual para compartir aprendizajes entre equipos

Puede ser una charla interna, un documento o una demo corta, todas con tinte informal.

Justificación: Refuerza la colaboración, el crecimiento y la cultura.

Conclusión

DevOps no es solo tecnología. Es, sobre todo, una forma distinta de construir equipos. Una forma que pone la colaboración, la autonomía, el aprendizaje y la cultura por encima de las herramientas.

Y cuando eso pasa, no solo mejoran los procesos: mejora el equipo entero.