El trabajo no existe hasta que un ingeniero lo inventa

A Staff Engineer's Guide to Inventing Work

En los equipos de plataforma, liderados por ingeniería, no hay un product manager que te entregue un roadmap. Un staff engineer debe inventar el trabajo leyendo señales que llegan desde cuatro direcciones: el sistema, los usuarios, la organización y la industria. El artículo propone once señales y las ordena según cuánto argumento aportan y si son adelantadas o rezagadas, para elegir la más valiosa.

El modo de fallo de un equipo de plataforma liderado por ingeniería no es un backlog vacío; es un backlog armado con las señales más ruidosas, normalmente el crash, a veces el skip-level.
  1. dabedee

    > Los equipos de plataforma están liderados por ingeniería en lugar de por producto. Casi nunca hay un product manager que te entregue un roadmap, no hay una línea de ingresos que seguir y no hay un mercado que perder.

    Es precisamente por este enfoque y mentalidad que los equipos de plataforma en realidad no sirven bien a las personas y suelen ser torres altamente disfuncionales de gente inventando trabajo.

    La solución para no tener mercado es actuar como si los equipos a los que sirves pudieran irse. Todo este artículo enumera señales, y ninguna de ellas es esa. Estar cautivo no significa que los usuarios o los equipos internos no tengan otras opciones y no se den cuenta. Estar liderado por producto significa preocuparse por tus usuarios. Un equipo de plataforma debería estar liderado por producto, no por ingeniería en ese sentido tan estrecho. De lo contrario, inventas trabajo como este artículo expone tan maravillosamente.

  2. fsloth

    "ese trabajo no existe a menos que un ingeniero lo invente".

    Esto es tan extraño. En mi opinión, el único propósito por el que las empresas contratan ingenieros es para apoyar el negocio. El staff engineer no debería necesitar que un project manager le diga qué es interesante para los aspectos de negocio, aunque los objetivos probablemente sean en su mayoría técnicos.

    Me doy cuenta de que esto no siempre se cumple. Pero para mí, si no puedes proporcionar algún razonamiento para tu trabajo en métricas de negocio, estás participando en un ejercicio académico.

  3. juancn

    Yo uso la filosofía de "qué nos va a matar después".

    Averigua qué es eso y haz algo para evitarlo.

    Lava, enjuaga, repite.

  4. nmehner

    "inventar trabajo" = "ingeniería de requisitos"

    "Inventar trabajo" es una frase extraña de usar en mi humilde opinión.

  5. stephbook

    El contenido del artículo es tanto verdadero como enmarcado de forma extraña.

    ¿Piensa el autor que los "clientes de producto" te entregan una lista ordenada de requisitos que el estúpido programador autómata solo tiene que traducir a código? Obviamente no. Los clientes tampoco saben lo que quieren, o podrían querer. Como es bien sabido, afirman querer caballos más rápidos.

    Luego el autor pasa a enumerar "descubrimiento liderado por caídas", como si esto fuera tan diferente de priorizar errores en producción. O, si no tienes ni idea, simplemente mejorar la eficiencia. O hablar con clientes, perdón, usuarios.

    Todo esto es cierto y nada de esto es diferente de cualquier otro software, solo traducido a otra jerga.

Más de este día

2026-09-29