7 cosas básicas que meteríamos en el botiquín de tod@ nuev@ CTO o Engineering Manager

1. Kit de
Supervivencia
para CTOs y Engineering Managers
Carlos @Buenosvinos, SalmorejoTech 2022
7 cosas que meter en el botiquín si emprendes un viaje inesperado

7. Kit de
Supervivencia
para CTOs y Engineering Managers
Carlos @Buenosvinos, SalmorejoTech 2022
7 cosas que meter en el botiquín si emprendes un viaje inesperado

10. ¿Esta semana somos mejores que la anterior?
Calidad: # bugs netos (creados - resueltos), % Code Coverage, % Mutation
Score Indicator (MSI) en caso de hacer Mutant Testing (super recomendado)
Delivery: # deploys/day, (no muy fan de velocities y demás métricas de Agile)
Servicio: # de Errores 50X/40X/30X, Tiempo caídas
Rendimiento: Google Analytics / Lighthouse contra 3 páginas más importantes,
1 KPI por Infra (# MySQL Slow Queries, % Redis Hit Ratio, etc.), avg. Response
time (o percentil 90/95)
Iniciativas y Negocio: # widgets jQuery pendientes por migrar a React (cuando
llega a 0 está migrado y se elimina el KPI), # total de pedidos incompletos, etc.
1. KPIs

11. - Revisión Semanal / Fácil de Medir / Empezad fácil (ya complicaréis si es necesario): ¡Delta en verde, ni se discute!
- Google Spreadsheet / Notion Page / Con
fl
uence
- Rellenado a mano (la gente se lo mira, se implica, investiga a ver qué ha pasado)
- Cada persona del equipo involucrado en rellenar 1 ó 2 (distribuir responsabilidad y hacer partícipes)
- Usar en retrospectivas (cómo ha ido el partido)
- Seleccionar un subconjunto y llevarlo a la reunión con l@s CXO.
- “Living Document”, entran y salen KPIs en función de su utilidad para el equipo
Ejercicio para casa: Isla Desierta
Si te fueras de vacaciones durante 3 meses a una isla desierta y sólo pudieras mirar una pantalla del tamaño de un folio, qué
información te gustaría ver para saber que el equipo “va bien”. Coge papel y lápiz.
1. KPIs
¿Esta semana somos mejores que la anterior?

13. Behaviour Driven Development para Team Members
User Experience / User Story
“As a non logged user, I want to log in with my GitHub Account”
Team Member Experience / Team Member Story
“As a team member, when deploying I stay until production is stable and orders are happening”
“Las Stand-ups Dailies las hacemos a las 9:00 AM por Slack”
“El Códing Standard del proyecto es PSR-4”
“Cuando nos vamos a comer ponemos el emoji 🍔 de la hamburguesa en Slack”
“Subimos a producción sólo si podemos validar después de subida que las métricas en Datadog están estables”
“Si tenemos que montar una base de datos, usamos preferiblemente PostgreSQL”
“Cada una rellenamos un KPI antes de la reunión semanal, si varía en negativo, investigamos el motivo”
“Durante el sprint, tan pronto encontramos un problema técnico que pone en riesgo la estimación, hablamos con el/la PO”
…
2. Working Agreements

14. Behaviour Driven Development para Team Members
- Google Docs / Con
fl
uence / Notion Page / Code Repository
- No son ley, se puede hacer challenge, propuesta, cambios de forma regular
- Reduce el tiempo de on-boarding y la curva de aprendizaje hacia la cultura del equipo
- Más efectivo (y sincero) que muchas job descriptions
- Evita falsas expectativas y males entendidos sobre “cómo trabajamos”
- Se puede hacer al estilo Architectural Decision Record (Context, Problem, Solution, Positive Results,
Negative E
ff
ects to Mitigate): https://adr.github.io/
- Combinar con Boy Scout Rule: “Dejar el campo mejor que como lo encontramos”
Ejercicio para casa: Hacer Explícito lo Implícito
Antes de la daily, que cada persona del equipo escriba lo que crea que es un Working Agreement del
equipo. En la retro, validar las propuestas e incluir las aceptadas por el equipo en un documento sencillo.
2. Working Agreements

16. El pulso al equipo
1:1s: Checks individuales (reuniones/charlas) con cada persona que os reporta
para comprobar estado emocional, objetivos profesionales, desarrollo
profesional, formación, situación con el equipo, etc. (NO CURRO DIARIO). Cada
15 días aprox.
Bidireccional: Buen momento para recabar información sobre cómo lo
estamos haciendo. “¿Cómo viste aquella situación?”, “¿Qué podría haber
mejorado en aquella comunicación?”, “¿No fui demasiado clar@, no? ¿Qué
opinas?”
1:Ns: Checks grupales. Cada 4-8 semanas. Genial para introducir cambios que
van a venir, reforzar resultados positivos, felicitar al equipo, presentar nuevos
working agreements, etc.
3. 1:1s / 1:Ns

17. Experimentamos con Org, Working Agreements, Tech, etc.
4. Experiments / Change Management

18. Preparando y Reforzando el Cambio
- Cada semana
- Temas que van a entrar como Working Agreement en las próximas semanas
(testing, hexagonal, devops, slack, etc.)
- Rotando por dentro del equipo
- Momento perfecto para hacer 1:N previo a la formación
Ejercicio para casa: ¿Qué hemos aprendido?
En las retros, ¿qué ha aprendido el equipo esta semana para ser mejor en la
siguiente iteración? ¿Nos falta algún tipo de habilidad o conocimiento? ¿La
podemos enseñar?
5. Formación Interna Semanal

19. Facilitan que nuestras aplicaciones sean testeables
Arquitecturas para nuestras aplicaciones: Semánticas con el Negocio (User Story Driven / Behaviour Driven),
Fáciles de Testear y que mantienen las opciones abiertas a nivel de qué infraestructura utilizamos.
Ejemplos de Arquitecturas Desacopladas: Onion Architecture, Clean Architecture, Ports and Adapters (aka
Hexagonal Architecture), etc.
Bonus Point: Monolitos vs. Monolitos Modulares vs. Micro-servicios
6. Arquitecturas Desacopladas

20. En cualquier deporte, la victoria se construye desde la defensa
- Buen Testing: barato, rápido de ejecutar,
sin falsos positivos, y con amplia cobertura
- Testing Unitario es el que mejor cumple, pero
le falta cobertura en proyecto ya arrancados
- Estrategia práctica y efectiva: Basarse en
Unit Testing (con Arquitectura Hexagonal)
testeando Outside-In (desde el Caso de Uso).
No testeamos conexión con Infraestructura.
- En proyecto existentes, mientras sube la
cobertura de testing unitario, nos protegemos
con tests de GUI.
7. Testing

21. 1. KPIs
2. Working Agreements
3. 1:1s / 1:Ns
4. Experiments / Change Management
5. Formación Interna Semanal
6. Arquitecturas Desacopladas
7. Testing Unitario Outside-In

22. https://cto.camp