Como un Staff Engineer de Google encuentra problemas para resolver

Como un Staff Engineer encuentra los problemas que vale la pena resolver

Lalit Maganti, ingeniero en Google que trabaja en Perfetto —la herramienta de debugging de rendimiento que usan docenas de equipos internos y varias empresas por fuera— lo resume en una frase: «la mayoría de problemas interesantes no aparecen en una página en blanco, aparecen mientras escuchas el ruido cotidiano». El post original, «How I Find Problems to Solve as a Staff Engineer», se volvió referencia porque describe un método, no una lista de hábitos sueltos.

En su propio trabajo, ese método llevó a macros y extension servers para Perfetto: en lugar de implementar una por una cada feature que pedían los equipos, descubrió que todos querían «personalizar la UI sin imponer sus elecciones al resto». Esa tesis común —la necesidad de extender la herramienta— terminó unificando seis o siete pedidos distintos en una sola arquitectura. Antes de eso, Maganti ya había pasado por el camino contrario: convencerse de que un caching transparente resolvía a la vez dos problemas de Perfetto que en realidad querían soluciones separadas, y tuvo que partir el diseño en dos a último momento.

Por que el «tiempo para pensar» no funciona

La pregunta que le hizo su mentee —»¿cómo encuentro problemas que valgan la pena?»— es exactamente la que se hacen los ingenieros senior que quieren dar el salto a Staff. La respuesta intuitiva es bloquear tiempo en el calendario para «pensar estratégico». Maganti lo intentó y no le sirvió. Lo que sí le funciona es comportarse como una esponja: absorber problemas en reuniones, chats, mails y presentaciones, dejarlos macerar y dejar que las conexiones aparezcan solas.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

La diferencia importa porque define qué tipo de profesional te promocionan. Como él mismo escribe, hay dos carreras: la de quien espera a que el manager identifique oportunidades y demuestra valor ejecutando las más difíciles, y la de quien encuentra problemas que sus líderes todavía no saben que existen. Las dos pueden llevar al ascenso, pero la segunda es la que deja huella en la organización.

Escuchar problemas, no pedidos

El primer movimiento concreto del método es separar el problema del request. Los usuarios, dice Maganti, casi nunca formulan el problema raíz; piden la primera solución que se les ocurre. Cuando algo cae en tu área, en vez de tomar el pedido literal, hay que seguir tirando del hilo con preguntas del tipo «si X existiera, ¿te resolvería?» o «¿qué parte de tu caso cubre esta feature que ya existe?».

Tres hábitos sostienen ese ejercicio:

Escucha ambiental, sin llenar la agenda de reuniones especulativas. La información útil ya fluye en una semana normal.
Trabajo de campo: cuando el problema parece serio, sentarse con el equipo, recorrer sus workflows e incluso intentar reproducir los bugs uno mismo. Ver el problema de primera mano separa lo que el equipo necesita de la solución que pidió.
Mapear a gente con más contexto: dueños de sistemas críticos, gente que cruza varios equipos, gente con visión downstream. Un café o un 1:1 con ellos muchas veces ya tiene los puntos conectados.

Dejar que los problemas se acumulen

Maganti reconoce haberse quemado varias veces por moverse demasiado rápido. Un equipo vocal pidió una feature, la construyó y casi no la usó: sus prioridades habían cambiado o el pedido venía de una investigación one-off. La euforia del momento no era lo mismo que la importancia relativa de la feature para todo el producto.

La contramedida es dejar que los problemas se apilen. La mayoría no merece convertirse en proyecto la primera vez que aparecen. Esperar trae tres beneficios:

El mismo problema puede aparecer en equipos distintos, lo que confirma que vale la pena atacarlo.
Problemas que parecen diferentes pueden tener la misma forma y resolverse en un solo movimiento (es exactamente lo que pasó con las extensiones de Perfetto).
A veces el equipo que pidió la feature ni siquiera la necesitaba tanto; te ahorraste un mes de trabajo.

La forma de acumularlos es personal: nota mental, doc compartido, lo que sea. Lo que importa es mantenerlos a la vista el tiempo suficiente para que la evidencia se acumule.

Encontrar la forma común — y desconfiar de ella

Esperar junta evidencia, pero no dice qué construir. Hace falta dar un paso más: separar los pedidos de la necesidad subyacente. La sensación de «varios pedidos incómodos colapsan en una sola idea y se abren posibilidades que ninguno de ellos anticipaba» es, según Maganti, una de las mejores del trabajo. Y también la más peligrosa.

Porque una forma común es solo una hipótesis, y la elegancia no es evidencia. Lo case de Perfetto funcionó. El del caching transparente no: las dos cosas querían soluciones genuinamente distintas y hubo que partir el diseño en dos a último momento, con ambas mitades ya en producción. La lección: convence a otros y convéncete a ti mismo, con RFCs, prototipos y presión explícita al sesgo de confirmación.

Presionarlo antes de construir

Dependiendo de qué tan seguro esté de que la idea funciona y de que alguien la quiere, Maganti elige entre tres caminos:

Directo: cambio pequeño, bajo riesgo, lo envía y avisa al manager.
Prototipo descartable: cuando no está claro si la idea funciona ni cuánto esfuerzo lleva. Expone los puntos de falla y da algo concreto para que otros reaccionen.
Esfuerzo completo: idea grande en la que confía, semanas o meses de trabajo, venderla a otros ingenieros y equipos. Es lo que hizo con las macros de Perfetto: dos RFCs, varios 1:1s y un par de talks para refinar la propuesta con feedback.

Y si la idea no sobrevive la presión, mejor abandonarla. Maganti es explícito: prefiere soltar algo antes que construir algo que nadie use o se vuelva una pesadilla de mantenimiento. A veces la idea es buena pero el timing es incorrecto — se aparca, lista para activarse el día que sea prioridad de la organización.

¿Qué significa esto para tu startup?

El método parece pensado para una organización grande con mucha autonomía bottom-up, y Maganti lo aclara: en entornos muy top-down hay menos espacio para trabajar así. Pero el marco se puede aplicar a cualquier equipo técnico, incluido el de una startup temprana, con dos ajustes:

Convertí la escucha ambiental en un proceso explícito. Si tu equipo es de tres personas, la esponja es más simple: standups semanales donde la consigna no es status sino «¿qué te está frenando esta semana?» — y registrar las respuestas en un doc compartido. Lo que se repite en tres semanas consecutivas probablemente es un problema real.
Construí un backlog de problemas, no de features. La distinción entre problema y request es la más exportable. Un request es «necesito un botón para X»; un problema es «los usuarios abandonan en el paso 3». Mantener la lista de problemas al nivel de dolor —no al nivel de solución propuesta— te deja recombinar ideas después, exactamente como hizo Maganti con Perfetto.

Dos acciones concretas esta semana:

Destiná una hora a revisar las últimas 4–6 semanas de soporte, feedback de usuarios y notas de retros. Listá los problemas que aparecieron más de una vez, todavía sin solución. Esa lista es tu mapa real de dónde invertir.
Antes de aprobar la próxima feature pedida por un cliente o stakeholder, preguntá «¿qué problema intentás resolver?» y verificá si ya hay algo en el producto que cubra el 70% del caso. Te va a ahorrar construir features que nadie termina usando —el mismo error que Maganti describe en Perfetto.