- El líder de ingeniería de Apple Michael Lopp enfatiza que, cuanto más fácil es crear productos rápidamente, más importantes se vuelven la operación centrada en las personas y el buen juicio
- “¿Quién toma las decisiones y cómo se ejecutan esas decisiones?” es la verdadera esencia de la ingeniería
- Más que la capacidad de escribir código, el liderazgo y las organizaciones centradas en las personas determinan el desempeño de una organización
- Con base en su experiencia en entornos diversos como Borland, Netscape, Palantir y Slack, presenta de forma concreta la estructura organizacional, la cultura de colaboración y las capacidades clave de liderazgo
- Se enfoca menos en el liderazgo técnico y más en la operación organizacional, la colaboración entre personas y la comprensión humana
- Esta entrevista no es una simple discusión técnica, sino que se concentra en diseñar organizaciones de ingeniería sostenibles y efectivas, y ofrece consejos prácticos para fundadores y líderes técnicos sobre la relación con los equipos de producto, las capacidades centradas en las personas y las cualidades de un buen líder
Cómo diseñar la estructura de una organización de ingeniería
- Incluso en distintas industrias, identifica como factores comunes de éxito la confianza en la ingeniería, el crecimiento rápido y la captación de talento inteligente
- A partir de eso, propone tres consejos prácticos para diseñar una organización de ingeniería exitosa
Tip #1: Fomenta el “Wolf Time”
- Divide el tiempo de los ingenieros en 71% trabajo sustancial / 29% tiempo libre para crear
- Ese 29% es un “tiempo imposible de medir y que no necesita explicación”, un espacio donde crecen la creatividad y la iniciativa propia
- En Palantir, el intento de formalizarlo fracasó → es más efectivo impulsarlo y comunicarlo de manera informal que convertirlo en un proceso rígido
- Ejemplo: proponer un espacio informal para compartir ideas cada viernes
> “Si el equipo no sabe que este tiempo está permitido, terminarán haciéndolo a escondidas entre reuniones y no crecerá nada”
Tip #2: Mientras más regulares sean las discusiones, mejor
- Los grandes productos nacen de la colaboración entre ingeniería, diseño y producto
- Esa colaboración suele venir acompañada de conflicto, pero justamente ese debate es clave para elevar la calidad del producto
- Debe haber discusión activa dentro del equipo sobre si se trata de un problema de diseño, de producto o de comprensión de una funcionalidad
- Los líderes deben fomentar el cuestionamiento de opiniones tanto de abajo hacia arriba como de arriba hacia abajo
- A menudo hay momentos en que una discusión entre fundadores y empleados cambia el rumbo de la empresa
Tip #3: Construye un sistema operativo escalable
- Buen juicio + capacidad operativa son la base de un producto escalable
- El juicio no se trata solo del resultado, sino de la capacidad de explicar “por qué se tomó esa decisión”
- El significado de la responsabilidad (Accountability) es tener una historia que se pueda contar
- Para que el buen juicio de unos pocos se extienda a todo el sistema, hacen falta procesos claros
- La calidad operativa se nota incluso en el proceso de contratación (rapidez de respuesta, claridad del calendario, etc.)
- No ignores los procesos con la excusa de ser una startup → construir una empresa es, en esencia, construir una operación
Cómo fortalecer la relación entre ingeniería y el equipo de producto
- La tensión y los malentendidos entre el equipo de producto y el de ingeniería son una historia vieja, pero
si quieres escalar un producto de alta calidad, es indispensable pulir bien esa relación
- Un mal PM hace que los ingenieros sigan el producto sin sentido de pertenencia,
- un buen PM ayuda a que los ingenieros entiendan plenamente “por qué estamos construyendo esto”
- Lopp define al ingeniero como la persona del “cómo” y al PM como la persona del “por qué”
- El equipo de producto debe transmitir la historia del cliente y delegar en ingenieros y diseñadores el cómo construirlo
- La clave es compartir el “por qué”
> Pregúntale directamente a un ingeniero, no al PM: “¿Por qué están construyendo esta funcionalidad?”
- Si la respuesta es “porque lo pidió el PM”, eso da rabia
- El verdadero problema no suele ser que el juicio del equipo de producto esté mal, sino que el ingeniero no entendió el contexto
> “Los ingenieros son quienes construyen el producto con sus manos. Una organización donde trabajan sin entender ‘por qué están construyendo esto’ está destinada al fracaso”
- Ante la pregunta de por qué Slack no tiene función de bloqueo, Stewart explicó con claridad la filosofía de que “es importante que la información sea visible para todos”
- Compartiendo la perspectiva de que se trata no de una funcionalidad, sino de una visión
- Un buen product manager debe ser capaz de dar contexto a cada funcionalidad o idea dentro de la visión completa del producto
- Esa es precisamente una parte del ‘why’ en la que todos deben enfocarse
¿Qué hace grande a un líder?
- El verdadero liderazgo en ingeniería va mucho más allá de la simple capacidad técnica
- “Al final, el liderazgo es el arte de tratar con personas”
-
Rasgo de liderazgo #1: Tiene flexibilidad (Malleability)
- Un líder trabaja con personas de estilos muy distintos y debe poder ajustar su propio estilo según cada caso
- Lo subraya usando como ejemplo su experiencia liderando equipos de formas completamente distintas en Pinterest y Slack
- A los nuevos managers siempre les hace la misma pregunta: “Después de recibir feedback, ¿qué cambiaste?”
- La composición del equipo también se reorganiza con base en las fortalezas y debilidades que aparecen al trabajar juntos, más que en criterios fijos
- Para eso, él reorganiza cada 6 meses
-
Rasgo de liderazgo #2: Tiene gran capacidad de storytelling
- Muestra un fuerte rechazo al micromanagement: “No hay nada más irritante que darles instrucciones a los ingenieros”
- En su lugar, el líder debe proporcionar “Box y Soup”
- Box: un espacio lleno de ideas y contexto
- Soup: una base de información que los miembros pueden beber o combinar libremente
- Si en vez de dar órdenes ofreces historias que inspiran, las personas juzgan por sí mismas y crecen
- Algunos dirán “solo dime qué tengo que hacer”, pero incluso entonces terminan interpretándolo a su manera
> El rol del líder es dar la sopa. Si la toman y qué le agregan, es decisión de ellos.
-
Rasgo de liderazgo #3: Entiende la motivación y los objetivos de cada integrante
- Un líder debe saber qué hace crecer y qué motiva a cada miembro del equipo
- Un ejemplo: a un ingeniero cuya fuerza vital son los desafíos técnicos, hay que darle oportunidades constantes de resolver problemas
- Otro ejemplo: una asistente en Palantir dejó claro que su motivación principal era la compensación → eso permitía gestionarla con claridad
- La clave es identificar la única motivación central de cada persona e invertir de forma constante en ella
- Para eso son indispensables la curiosidad (curiosity) y la pregunta constante de “¿por qué?”
> Un líder debe descubrir motivaciones que ni la propia persona conoce y crear oportunidades para su crecimiento.
Conclusión: la esencia de la ingeniería exitosa es entender a las personas
- Una organización de ingeniería exitosa depende de una dinámica humana (Human Dynamics) que funcione bien
- Los grandes productos no nacen de individuos brillantes por separado, sino de un conjunto de personas que colaboran bien
- El rol del líder empieza por empoderar a las personas que forman la organización
- “Los equipos de ingeniería son un gran tapiz (tapestry) de seres humanos complejos y maravillosos”
- El esfuerzo por entender la estructura y el flujo de ese tapiz es la clave para que el valor del producto se transmita de forma efectiva a toda la organización
> “Cuando tienes la motivación de entender cómo interactúan las personas, tu empresa está lista para transmitir el valor del producto a escala.”
6 comentarios
Hay un Slack para líderes técnicos administrado por Michael Lopp.
RLS - Rands Leadership Slack
Si les interesa, échenle un vistazo. Actualmente es un Slack enorme con más de 36,000 participantes.
Para unirse, hay que leer bien la información en el enlace de arriba y enviarle un correo a Lopp.
Nombre/profesión/por qué quieres unirte/dónde te enteraste de RLS/tus cuentas como LinkedIn o Twitter
Entonces, si trajeron ingenieros caros, no se trata de tratarlos como si fueran un LLM solo porque se la pasan escribiendo, ni de darles instrucciones hasta en lo más mínimo como si le estuvieran ordenando a Doraemon que les sacara algo de la manga; más bien, uno solo debería compartir su visión y dejar que se encarguen por su cuenta, porque justamente el enfoque de ingeniería para implementarla es su área de especialidad.
Mientras lo escuchaba en silencio, ¿por qué será que se me vino a la cabeza esa dinámica de discusiones y roces entre contratistas, constructoras o arquitectos y la gente que en nuestro país quiere construirse una casa de campo o remodelar un departamento viejo?
¿No será que el segundo caso tiene un contexto un poco distinto?
La remodelación de una casa en las afueras o de un departamento antiguo,
antes que nada, es un ámbito más cercano a cumplir un sueño que a un negocio,
y además, como pasa demasiado seguido que uno confía en una constructora o empresa de remodelación y termina recibiendo una puñalada por la espalda...
Creo que pasaría exactamente lo mismo si el dueño no lo hiciera directamente y se lo encargara a alguien más.
Por más bien que lo expliquen, siempre hay malentendidos, y por más meticuloso que uno sea, siempre existen áreas que no se llegaron a considerar.
Si van preguntando una por una las partes que el dueño no les dijo mientras lo hacen, toma mucho tiempo y resulta frustrante, así que hay bastantes cosas que el experto resuelve por su cuenta, y siento que justamente ahí es donde surgen casi todos los roces.
Por cierto, lo envidio; parece que no le ha tocado tantas veces que una empresa de SI le juegue una mala pasada.
Esto también me recuerda a Modern Software Engineering, que recientemente leí. Porque también habla de los equipos y de la organización, no solo del desarrollo en sí.
Aunque hay muchas opiniones y métodos sobre el liderazgo en ingeniería, creo que todos coinciden en que la esencia está en comprender a los miembros del equipo. Entender a las personas del equipo suena fácil, pero me parece que requiere construir confianza entre líderes y colaboradores a partir de la empatía, basada en la retroalimentación mutua. No parece ser algo que se construya de una sola vez. Gracias por compartir un contenido muy valioso para reflexionar.