Sobre mí
Soy ingeniero, pero ha cambiado bastante el tamaño de lo que considero un sistema.
Llevo casi toda mi vida adulta construyendo cosas.
Durante mucho tiempo, eso significó escribir software.
Empecé como desarrollador y sigo sintiéndome como uno. Me gusta entrar en un problema que no entiendo, desmontarlo, descubrir cómo funciona y acabar construyendo algo que antes no existía.
Pero con los años empezó a cambiar el tamaño de esos problemas.
Ya no era sólo cómo construir un sistema que aguantase más tráfico, sino cómo conseguir que veinte personas pudieran trabajar sobre él sin pisarse. No sólo cómo entregar más rápido, sino entender qué estaba impidiendo al equipo hacerlo. No sólo qué arquitectura necesitábamos, sino qué responsabilidades, procesos y estructura tenían que existir alrededor.
En algún momento dejé de trabajar únicamente sobre software y empecé a trabajar también sobre los sistemas humanos que lo construyen.
Sigo siendo ingeniero. Sólo ha cambiado bastante el tamaño de lo que considero un sistema.
Durante los últimos años he liderado un área de ingeniería de unas 25 personas, dando servicio a otras 400, y responsable de una plataforma que sirve decenas de miles de sitios web con millones de visitas cada semana.
La escala técnica era interesante. La humana, bastante más.
Mi trabajo empezó a ser diseñar equipos, definir responsabilidades y jerarquías, contratar, hacer mentoring y construir procesos que ayudasen a tomar mejores decisiones sin convertirse en burocracia.
También significaba crear contexto suficiente para que otras personas pudieran trabajar con autonomía. Detectar cuándo un problema necesitaba una decisión técnica y cuándo necesitaba una conversación. Saber cuándo intervenir y, quizá más difícil, cuándo quitarme de en medio.
Con el tiempo he descubierto que el liderazgo y la arquitectura tienen algo en común: ambos consisten en diseñar sistemas en los que las partes puedan funcionar bien sin depender constantemente de ti.
No siempre sale bien.
Pero probablemente ésa sea una de las cosas que más ha cambiado mi forma de entender el trabajo.
He vuelto a estar mucho más cerca del código.
Después de pasar los últimos años cada vez más cerca de un rol de dirección, el siguiente paso ha sido volver a un rol de Product Engineer.
No porque haya dejado de interesarme el liderazgo.
Sino por volver a estar cerca del producto, del código y de esas decisiones pequeñas que, acumuladas durante suficiente tiempo, terminan convirtiéndose en sistemas grandes.
Y hacerlo con todo lo aprendido al otro lado.
Haber liderado equipos cambia la forma en la que escribo software. Entiendo mejor el coste organizativo de una decisión técnica, la importancia de crear contexto, por qué algunas abstracciones ayudan a un equipo y otras sólo hacen más elegante el código.
Y seguir construyendo software cambia también mi forma de entender el liderazgo.
No tengo demasiado interés en elegir uno de los dos lados.
Me interesa precisamente el espacio que queda entre producto, tecnología y personas.
He llegado hasta aquí por unos cuantos caminos.
He construido productos propios y productos para otras compañías. He trabajado con startups de distintos países, en equipos pequeños y en organizaciones bastante más grandes.
He fundado varios proyectos y un estudio (Commit Sans) con el que hemos hecho productos usados por más de 100.000 personas. He pasado varios años conociendo startups (y founders) en más de siete países, y ayudándoles a resolver problemas (muchos, muy variados). He servido bastantes millones de páginas al día durante dos años. He enseñado desarrollo de software a más de 20.000 personas y construido una comunidad de miles de desarrolladores.
Muchos números, muy fancy todos.
También he construido plataformas desde cero, heredado sistemas que llevaban años creciendo y trabajado sobre productos donde una mala decisión deja de ser pequeña bastante rápido. Legacy del duro.
He escrito código, diseñado arquitecturas, contratado, despedido, hecho mentoring, definido procesos, montado equipos y tenido conversaciones mucho más difíciles que cualquier problema técnico que me haya encontrado.
Algunas cosas salieron muy bien.
Otras me enseñaron bastante más.
No tengo demasiado interés en convertir todo esto en una cronología. Si buscas cargos, empresas y fechas, para eso está LinkedIn ↗.
Lo que me interesa de haber pasado por sitios tan distintos es haber podido mirar los mismos problemas desde perspectivas diferentes.
Me divierten los problemas.
Especialmente los que no pertenecen limpiamente a una disciplina.
Los que parecen técnicos hasta que descubres que son organizativos.
Los que parecen de producto hasta que encuentras una limitación de arquitectura.
Los que parecen un problema de una persona hasta que descubres que has construido un sistema que empuja a todo el mundo a comportarse de esa manera.
Y los que llegan perfectamente definidos hasta que haces dos preguntas.
Ahí es donde más cómodo estoy.
No tengo demasiado apego por una tecnología, una metodología o una forma concreta de hacer las cosas. Sí tengo bastante apego por entender por qué las hacemos.
A veces la respuesta acaba siendo software.
Otras veces, no.
Algunas de esas ideas terminan encima de un escenario.
Llevo muchos años enseñando y dando charlas. Con el tiempo me ha ido interesando menos explicar herramientas y más hablar de las decisiones difíciles que aparecen cuando construyes productos, sistemas y equipos de verdad.
Las que no tienen una respuesta limpia.
Las que normalmente aprendemos después de equivocarnos unas cuantas veces.
Cuando cierro el editor.
Me gustan las motos, la fotografía, hacer música, escribir, cocinar para demasiada gente y aprender cosas con una intensidad completamente desproporcionada a su utilidad.
También me gusta mucho la cerveza.
Algunas de esas cosas acaban en una newsletter que escribo en español. Otras, afortunadamente, no acaban publicadas en ningún sitio.