Sin PM en el equipo: ¿Qué se supone que debe hacer un Senior?

Hace poco pasé mi período de prueba, y en un 1-on-1 mi manager me dijo: "Me gustaría que fueras más proactivo explorando problemas del producto."

Eso me tomó por sorpresa. Estaba escribiendo código todos los días, corrigiendo issues y empujando proyectos hacia adelante. ¿Cómo es que eso no era suficientemente proactivo? Me tomó un tiempo entender lo que realmente quería decir.

Todo corriendo al mismo tiempo

Pasar la prueba no significó menos presión. Si acaso, significó hacer malabares con aún más cosas a la vez:

Elemento	Naturaleza	Lo que puedo controlar
Corrección de issues	Trabajo diario, con output medido parcialmente por volumen	Mantener un ritmo constante
Proyecto A	Un proyecto formal, pero el lado del usuario tarda en confirmar requisitos	Limitado — principalmente esperando respuestas
Investigación de producto	Buscar proactivamente formas de mejorar el producto	Cuándo entregar, cómo presentarlo, cómo reportarlo

Cuando estás cambiando entre tres o más cosas en un solo día, la parte agotadora no son las horas. Es el constante context switching.

Entonces me di cuenta: No tenemos PM

Lo sabía desde el primer día, pero nunca había pensado realmente en lo que significaba.

Tenemos un BA (Business Analyst) que se encarga del análisis de requisitos, pero nadie realmente se hace cargo de preguntas como: ¿En qué punto está esto? ¿Quién está bloqueado? ¿Deberíamos repriorizar?

En mi empresa anterior, el PM o Tech Lead se encargaba de todo eso. Yo solo tenía que revisar el backlog, confirmar prioridades, aclarar requisitos del producto y concentrarme en escribir código. El spec llegaba, yo lo construía. Si me quedaba atascado, le decía al PM y ellos se encargaban del resto.

Ahora ese rol no existe. ¿Entonces quién lo asume?

El Senior.

Senior no es PM, pero necesitas Ownership

Al principio no lo entendía. Soy ingeniero, ¿por qué debería estar persiguiendo usuarios por respuestas, reportando blocker proactivamente o alineando prioridades con mi manager? ¿No es eso trabajo de PM?

Pero eso no significa que un Senior deba reemplazar al PM adueñándose del roadmap del equipo, manejando coordinación cross-funcional o rastreando el progreso de todos los demás. El punto real es más simple: no puedes tratar los blocker en tu propio trabajo como si fueran problema de alguien más.

Cuando comparé los dos, la diferencia se hizo más clara:

	PM	Senior
El progreso de quién gestionar	Todo el equipo	Tus propias líneas de trabajo
Decidir qué construir	Roadmap, prioridades	No decides, pero sí alineas
Perseguir stakeholder	Todos los involucrados	Tus propios blocker
Responsable ante	Objetivos de negocio	Las funcionalidades que te pertenecen

Un Senior no necesita gestionar a otras personas. Solo necesitas mantener tus propias tres o cuatro líneas sin que se caigan. Reportar blocker proactivamente en vez de esperar en silencio. Tener opiniones sobre las funcionalidades que te pertenecen en vez de solo esperar instrucciones.

Eso se llama ownership, no PM.

No es que mi trabajo anterior fuera demasiado fácil

Por un momento, me pregunté si mi empresa anterior simplemente tenía expectativas más bajas para los Seniors. Pero mientras más lo pensaba, más me daba cuenta de que ese no era el problema. Los entornos eran simplemente diferentes.

Mi empresa anterior tenía un PM que me protegía del trabajo de coordinación, y la línea de producto era más simple. Allí, "Senior" se definía más en términos técnicos: si podías resolver problemas difíciles, era suficiente. En mi entorno actual, parte del trabajo también es empujar el progreso del producto hacia adelante, porque nadie más lo va a hacer por ti.

En un equipo lean, eso es normal. No es irrazonable. Simplemente aún no estoy acostumbrado.

Lo que realmente hice

Una vez que lo entendí, hice algunos cambios:

Priorizar y alinear con el manager. Listé todo por prioridad y pregunté: "¿Te parece bien este orden?" Es solo un mensaje, pero cambia la postura de esperar pasivamente instrucciones a gestionar activamente mi propio trabajo.

Cuando estás bloqueado, cambia de línea, pero deja registro. Si el usuario del Proyecto A no responde, hago ping una vez por semana y dejo un rastro documentado. Mi manager sabe que el blocker no está de mi lado, y puedo usar el tiempo libre para empujar la investigación de producto.

No hagas context switching con demasiada frecuencia. Usa las prioridades para decidir en qué trabajar hoy en vez de tocar todo un poco. Registra las líneas bloqueadas, déjalas a un lado y vuelve a ellas cuando se desbloqueen.

Reflexión final

Todo esto suena básico, pero para un ingeniero acostumbrado a que un PM maneje la coordinación, toma tiempo adaptarse. Bajo presión, puede sentirse como si estuvieras haciendo trabajo que no te corresponde. Pero al menos en un equipo sin PM, esto es parte de lo que significa ser Senior.

Como nota al margen, primero ordené las ideas detrás de este post a través de conversaciones con AI, y luego las rastreé con un sistema personal que construí para registro diario y retroalimentación, al que llamo Pasiv. Vibe coding no se trata solo de usar AI para construir proyectos. También incluye usarlo para desenredar dónde te encuentras actualmente.