Equipos de Proyecto Sin Jefes de Proyecto: Explorando el Dilema del PM

Lee la transcripción:

Estamos probando la transcripción de nuestros pódcast usando un software automático. Por favor, disculpa los errores tipográficos, ya que el bot no es 100% preciso.

Galen Low: Equipos de proyecto autogestionados. Esa frase por sí sola basta para provocar una crisis existencial en cualquier jefe de proyecto. ¿Pero es realmente una amenaza a nuestra existencia? ¿O es la clave para elevar el rol del jefe de proyecto a uno decididamente más estratégico?

Si llevas tiempo pensando en el futuro de la gestión de proyectos y en si los jefes de proyectos digitales seguirán siendo relevantes, sigue escuchando. Vamos a levantar el capó y ver cómo una organización está consiguiendo construir soluciones complejas de software utilizando escuadrones distribuidos y autogestionados, y lo que esto significa para la gestión de proyectos digitales en general.

Gracias por escucharnos. Mi nombre es Galen Low y soy parte de Digital Project Manager. Somos una comunidad de profesionales digitales con la misión de ayudarnos mutuamente a desarrollar habilidades, ganar confianza y establecer conexiones para poder entregar proyectos con propósito e impacto. Si quieres saber más, visita thedigitalprojectmanager.com.

Hola a todos — gracias por acompañarnos en el pódcast de DPM.

Mi invitada de hoy es una profesional de TI con base en Kiev que lleva más de 15 años impulsando el avance en la gestión de procesos de negocio y la gestión de productos digitales. Ha sido analista de negocios, directora de PMO, directora de producto, directora de éxito del cliente, trabajando con marcas como Heinz, Yandex, Adidas y Zyxel para implementar sistemas empresariales a gran escala.

Hoy es gerente de producto en Railsware, trabajando con el equipo de Coupler.io donde supervisa squads remotos autogestionados bajo metodología Agile, creando productos ampliamente adoptados que hoy día son nombres reconocidos, como Calendly.

Fuera del trabajo, imparte clases sobre procesos de negocio y gestión de proyectos en la Lviv Business School y cría a su bebé para ser la próxima generación de mujeres en tecnología.

Amigos, por favor den la bienvenida a Julia Ryzhkova. ¡Hola, Julia!

Julia Ryzhkova: ¡Hola! ¡Hola a todos!

Galen Low: Gracias por acompañarnos hoy. Gracias por nuestras recientes charlas. Realmente me entusiasma este episodio porque creo que aborda algo que a todos nos incomoda como jefes de proyecto, y es: ¿seguirán existiendo los jefes de proyecto?

Vamos a hablar de ello, pero antes quisiera preguntarte—¿cómo va la vida? ¿Qué te inspira últimamente?

Julia Ryzhkova: Son dos cosas diferentes. Si hablamos de algo relacionado con Railsware, es el marco BRIDGeS. Lo abrimos hace poco y es un marco de decisiones que te permite, a alto nivel, describir un problema y luego transformarlo en una solución.

Lo hemos abierto recientemente y actualmente estoy enfocada en fomentar el boca-oreja sobre esto. Estoy muy emocionada. Lo fuimos perfeccionando por más de 15 años y ahora es el inicio de abrirlo al público, lo cual me inspira mucho.

Y a nivel personal también colaboro, como mencionaste, con la escuela de negocios de Lviv y por el momento estamos impartiendo un curso público online sobre procesos de negocio y espero que esto mejore la madurez general de la cultura de procesos empresariales de Ucrania.

Eso también me inspira.

Galen Low: Me encanta. Ambas cosas son geniales, grandes logros. ¡Felicidades!

Si la gente quisiera saber más sobre este marco BRIDGeS, ¿dónde puede consultarlo?

Julia Ryzhkova: En el sitio de Railsware, tenemos un subdominio dedicado para ello.

Galen Low: Genial. Muy bien. Y bueno, cuando grabamos esto es diciembre, estamos por terminar 2021 y entrar en 2022. Me preguntaba: ¿qué te entusiasma para 2022?

Julia Ryzhkova: Sabes, todo el mundo habla sobre inteligencia artificial y aprendizaje automático. Recientemente tuvimos una reunión para discutir la visión de producto y surgió la idea de usar IA en mi producto, Coupler.io. Tengo muchas ganas de probarlo y ver cómo resulta.

Galen Low: Muy bien.

Entonces, vamos al grano. Hoy hablamos de cómo pequeños squads de equipos Agile remotos pueden autogestionarse y organizarse para crear soluciones de software complejas sin necesitar nunca a un jefe de proyecto. ¿Es esto una amenaza para nosotros los jefes de proyecto? ¿O es una oportunidad para que los jefes de proyecto asuman un rol más estratégico? ¿Está provocando ansiedad existencial en nuestros oyentes?

Vamos a explorar todo esto en detalle.

Pero primero, ¿podrías contarnos un poco sobre tu trayectoria profesional? ¿Cuál es tu rol actual y cómo llegaste hasta allí?

Julia Ryzhkova: Actualmente soy gerente de producto, lo que significa que gestiono el desarrollo, marketing, estrategia de precios y fuerza de ventas del producto.

Tengo formación técnica, lo cual me ayudó mucho en ciencias de la computación, pero en realidad no me gustaba programar. Cuando busqué oportunidades laborales, buscaba algo donde pudiera crear algoritmos, pero dejar a otros la programación. Por eso me convertí en analista de negocio. Luego fui desarrollando habilidades de liderazgo: líder del equipo de BA, jefe de proyecto, directora del departamento de BA…

Pero noté que los resultados realmente dependían del producto en el que trabajaba. Por eso decidí pasar a I+D como dueña de producto y ser parte del producto. Fue la primera vez que sentí estar en el lugar correcto. Luego nuestro producto y equipo crecieron, llegaron más dueños de producto y me convertí en directora adjunta de producto, gestionando la mitad de los equipos scrum. Quería avanzar más allá.

Como ya había director de producto, decidí—y aún quería estar en la junta directiva—ser directora de experiencia cliente, encargándome del soporte, academia, todo lo relacionado a servicios dentro de la empresa, y logré construir excelentes procesos y mostrar buenos resultados.

Así que decidimos aprovechar esas habilidades para implementar procesos en otros departamentos y fui directora de PMO. Luego vino la licencia de maternidad. Tras eso, quería volver a la gestión de productos.

Es una decisión importante y quizás te preguntes: ¿por qué gestión de producto y no de proyectos? Porque quería enfocarme en los beneficios para el cliente, dejando la gestión de procesos en segundo plano. Esa es para mí la diferencia entre gestión de producto y de proyectos, aunque hay muchas similitudes.

Sin embargo, los gerentes de producto pueden enfocarse más en el producto y el cliente; los jefes de proyecto se centran en el proceso y sus resultados. Aquí es donde los equipos autogestionados son cruciales y ahí fue cuando conocí y leí sobre Railsware, y supe que encajaba perfectamente.

Galen Low: Me encanta esa trayectoria. Me fascina tu formación técnica, tu experiencia en manejo de experiencia cliente, liderazgo de equipos PM. Es muy inspirador para quienes estamos en la industria.

¿Puedes contarme un poco de Railsware, la estructura de los equipos que supervisas y el tipo de proyectos que gestionan?

Julia Ryzhkova: Claro, empecemos por los proyectos, porque la estructura del equipo depende del tipo de proyecto. Somos un estudio de productos, lo que significa que creamos productos propios y para otras compañías. Nos gusta automatizar todo, y a veces no encontramos en el mercado una herramienta que haga aquello que necesitamos. Así que decidimos desarrollar algo para nosotros mismos, lo usamos y luego lo lanzamos públicamente porque sabemos que no somos los únicos con esa necesidad. Por eso normalmente comenzamos como un equipo pequeño, buscando mercado.

A veces, incluso es solo un desarrollador a tiempo parcial; por ejemplo, uno de nuestros productos, Smart Checklist para Jira, fue desarrollado a tiempo parcial por un solo desarrollador, y solo cuando logramos 50k de ingresos mensuales asignamos desarrolladores a tiempo completo.

En productos pequeños como Coupler.io, tenemos un squad de desarrollo (cuatro o cinco desarrolladores) y un squad de marketing (también cuatro o cinco especialistas de distintos campos).

El resto trabaja a tiempo parcial, como analista de datos, responsable de soporte… incluso yo como gerente de producto estoy involucrada en productos propios y de clientes. Cuando un producto crece (como sucedió con Calendly), extendemos el equipo de desarrollo y lo dividimos en varios squads, porque creemos que es más eficiente trabajar en squads pequeños.

Por ejemplo, actualmente Calendly tiene tres equipos de nuestro lado y muchos desarrolladores de su lado. Así funciona.

Galen Low: Muy interesante. Me gustaría profundizar en la noción de squads y swarms (enjambres). Me gusta que marketing también sea un squad. Sé que antes hablé en términos de equipos Agile, pero Agile no implica solo ingeniería o desarrollo.

Podría significar muchas cosas diferentes, y creo que lo abordaremos. ¿Cuál es el mayor desafío que enfrentas hoy desde la perspectiva del desarrollo de producto?

Julia Ryzhkova: No será sorpresa, es el mismo reto de todo gerente de producto en una startup: encontrar la “mina de oro” en el mercado.

Sí, resolvemos algún dolor del cliente y por eso nuestra base crece y los KPI aumentan, pero queremos mantener el ritmo y duplicarlo. Necesitamos encontrar otro dolor relevante, que el cliente pague el doble por eliminarlo.

Galen Low: ¡Sois solucionadores de problemas! Lo genial es que el problema lo resuelven para ustedes mismos y luego lo comparten con otros. Es como un producto interno que se proyecta hacia fuera. También actúan como organización de servicios para asistir a otras empresas a construir los productos de sus sueños y eliminar esos dolores intolerables.

Genial.

Ubicándonos: en mis círculos la idea de equipos autogestionados es un arma de doble filo. Por un lado, la mayoría quiere equipos independientes para no ser cuello de botella, pero por otro, todos quieren seguir siendo imprescindibles y tener trabajo.

El concepto de equipos de proyecto sin jefes de proyecto no es nuevo. En un equipo Scrum Agile, no se menciona jefe de proyecto, solo dueño de producto, scrum master y el equipo de desarrollo. La idea estaba en el aire, pero la estamos descifrando y entendiendo a quién aplica.

En cierto modo, es una amenaza: ¿quién necesita jefes de proyecto si los equipos pueden gestionarse solos? Pero en otros aspectos, es la utopía del project management: ser más estratégicos, estar más cerca del producto y del cliente y menos atados a la gestión del trabajo.

¿Hay equilibrio? Empecemos por el ancla, el punto de partida. ¿Puedes explicar cómo funciona el concepto de squads autogestionados en Railsware y el equipo de Coupler.io?

Julia Ryzhkova: La respuesta está muy ligada a nuestro concepto del “product mindset” del desarrollador.

Hicimos recientemente un webinar sobre ello. Buscamos desarrolladores maduros y polivalentes (perfil en T, como yo, con experiencia en varios campos). Pueden trabajar con cliente como desarrollador, product manager, durante el periodo MVP.

Hemos perfeccionado nuestro proceso de selección por años para encontrar ese perfil, que no es sencillo. Primero, los incorporamos a productos internos para que aprendan el oficio y compartan enfoques, desarrollando esa mentalidad de producto.

Luego pueden trabajar con clientes, siendo una especie de “hombre orquesta”. Lo mismo con otros roles: cada quien es independiente. Muchos han sido gerentes o han dirigido sus propios negocios (HR, diseñadores, product managers, etc.), así que prácticamente todos. Sin embargo, ninguno es jefe directo del equipo y se gana autoridad liderando con el ejemplo. Lideras el producto y así demuestras tu valor. No es decir “qué” se debe hacer, sino hacer el mejor trabajo posible para impactar el producto y el resultado global. Así el equipo confía y replica la actitud.

Galen Low: Me gusta mucho esa aproximación al equipo polivalente, la riqueza de experiencia. Me gustaría profundizar más adelante en el proceso de selección e incorporación.

Pero sí, el objetivo no solo son habilidades técnicas sino experiencia de gestión y liderazgo, incluso quienes han gestionado su propio negocio. Esa visión es valiosísima, aunque luego el equipo sea plano—y eso es interesante.

Has mencionado que tienes formación en gestión de proyectos y dirigiste un PMO. Como persona con ese background, ¿la idea de equipos autogestionados llegó a incomodarte o la percibiste como una amenaza?

Julia Ryzhkova: Sí, de hecho durante mi periodo de prueba en Railsware. Es fácil evaluar tu necesidad en una empresa cuando eres “el héroe” y sin ti todo se descontrola, así que tu puesto parece inamovible. Pero cuando todo va bien aún sin ti, ya no percibes tanto el impacto como antes.

Realizas cambios, implementas procesos, mejoras algo y todo sigue casi igual. Sí, hay una mejora, pero sientes que podrías tomar vacaciones de dos semanas y nada se vendría abajo. Entonces… ¿por qué me necesitan? Con el tiempo dejas de intentar controlarlo todo y, con tu tiempo libre, te enfocas en encontrar nuevas formas de aportar valor.

Te concentras en el producto, en el cliente, en la estrategia, y puedes impactar más. Incluso, cuando das más espacio al equipo, pueden crear cosas asombrosas en la guild. Por ejemplo, tenemos squads (4 ingenieros, 1 QA), y guilds como la de ingenieros, QA y gestión de producto.

Por ejemplo, la guild de gestión de producto creó el marco BRIDGeS que ya mencioné. Sería imposible crear algo así sin ese espacio y autonomía.

Galen Low: Sí, es clave. Todos con quienes he hablado me cuentan que los equipos autonómos son protagonistas de sus mejores proyectos. No significa prescindir del jefe de proyecto, sino empoderar. Como jefe de proyecto, a veces caemos en la microgestión; somos los que “arrean gatos”, asegurándonos de que todo se entregue. Pero se trata de orientar, inspirar y empoderar al equipo para logros mejores. En tu cultura, no es cuestión de “no necesitamos a Julia”, sino de que ahora Julia puede aportar desde un nivel más estratégico. Poder irse de vacaciones es síntoma de madurez… ¡y eso es enorme!

Y veo que aunque ya no eres jefa de proyecto, sino gerente de producto, de alguna manera actúas como la directora de orquesta…

Julia Ryzhkova: Sí, puedes decirlo así.

Galen Low: ¿Sigues usando tus habilidades de gestión de proyectos? ¿Te beneficia haber pasado por ese rol?

Julia Ryzhkova: Por supuesto. No imagino a un gerente de producto sin experiencia en gestión de proyectos. Es crucial. Mi formación técnica me ayuda, pero las habilidades de gestión son esenciales para un gerente de producto.

Como parte de nuestras competencias, todos los cargos senior en Railsware requieren habilidades de gestión de proyectos: comunicación, resultado, etc.

En cuanto a competencias específicas, según PMBOK, ya no hago tanto integración ni gestión de comunicación (autogestión), pero el alcance, costes, cronograma y gestión de interesados siguen siendo clave.

La calidad la gestionan QA e ingenieros, casi no me encargo de ello. La gestión de riesgos y compras es responsabilidad compartida del equipo. Si alguien necesita algo para el trabajo, envía una solicitud de compra y explica por qué. No imagino tener que entender por qué se necesita tal herramienta de marketing o librería de desarrollo. Me alegra no tener que hacerlo.

Galen Low: Me encanta que todos los cargos senior requieran esas habilidades. A menudo damos por sentados el alcance, coste, cronograma y los interesados, aunque en realidad son el corazón del trabajo. ¿Eso se incluye en el proceso de contratación o alguien en un puesto senior debe formarse en gestión de proyectos?

Julia Ryzhkova: Cuando hablo de cargos senior, me refiero también a ingenieros y QA, no solo a oficinistas. Todos los que contribuyen al producto o proyecto deben, como mínimo, poder autogestionarse: su propio alcance, tiempo, costes y adquisiciones. Por eso buscamos perfiles maduros, no quienes deban ser formados desde cero.

No exigimos formación explícita o un background definido en gestión de proyectos. Sin embargo, son habilidades que todos aplican, a veces sin saberlo, y nosotros ayudamos a ampliarlas, no a desarrollarlas desde cero.

Galen Low: Eso me encanta: como gerentes digitales de producto y proyecto debemos aprender de los artesanos de nuestros equipos y ellos deberían aprender de nuestra disciplina: autogestión, colaboración, visión de negocio… No se trata solo de construir, sino de hacerlo con propósito, dentro de limitaciones.

Vamos a profundizar en cómo funciona todo esto, especialmente pensando en quienes escuchan y desean aplicar este modelo. Probablemente gestionar clusters de equipos autogestionados requiere procesos bien definidos y una excelente incorporación. ¿Cómo se comunican y se mantienen alineados los squads?

Julia Ryzhkova: Es parte de la cultura. Cuando solo estaban los dos fundadores de Railsware, definieron procesos, aunque fueran simples to-dos. Tenían enfoque estructurado y lo documentaron todo. Buscaban sumar gente alineada con esa cultura. No es común en pequeñas empresas; normalmente se piensan procesos recién cuando todo empieza a desmoronarse. Aquí fue desde el origen.

Por eso, tenemos excelente onboarding y el principio de "documenta mientras avanzas".

Toda reunión tiene documento compartido (doc, Figma, etc.) donde todos escriben apuntes antes o durante la reunión, nunca después. No hay “actas de reunión” que requieran tiempo extra tras la reunión: los apuntes ya existen. Si alguien menciona algo fuera de la agenda, otro lo apunta, para que nada quede fuera.

Así que, tras dos semanas de vacaciones, solo abro los documentos relevantes y ya sé qué ha pasado, sin tener que pedir que me pongan al día. Nada se pierde.

Es una cultura de transparencia. Además, las comunicaciones son públicas en canales de Slack (más de 300), casi no hay privados laborales. Cualquiera puede leer y responder rápidamente, incluso si no fue el destinatario original.

Puedes revisar el canal y saber qué ocurrió en tu ausencia.

Galen Low: Muy bueno. Muchos quieren dominar esa comunicación asíncrona donde todo queda registrado y se puede consultar después.

¡Railsware fue progresista desde el primer día! Con to-dos sencillos; no hace falta que sea extenso, basta con que esté escrito en algún lado y que otros lo puedan entender.

Me encanta.

Julia Ryzhkova: Yo también admiro eso. Antes solía decir en mis formaciones de procesos que solo necesitas procesos cuando creces, pero al conocer Railsware cambié de opinión. Ahora digo que hay que empezar desde el principio, aunque sea con una lista de comprobación simple.

Si haces temas personales, como buscar empleo, creas una lista de empresas y etapas; necesitas registrar el estado, el próximo paso, etc. Eso también es un proceso y lo necesitas, si no, es imposible de gestionar.

Así que, si quieres hacer negocios, necesitas procesos.

Galen Low: Totalmente. Quisiera tocar el tema de los indicadores para el equipo.

En este modelo, muchos se preguntan: “¿Cuáles son las métricas clave de rendimiento y cómo saber si va bien?” Si el equipo funciona solo y la estructura es plana, la responsabilidad se comparte y cuesta saber si todo avanza. ¿Qué controlas tú?

Julia Ryzhkova: Es gracioso, pero en realidad no controlo métricas de rendimiento. Puede sonar irreal, pero así es. En cambio, hago seguimiento a métricas del producto.

Seguimos el crecimiento, si van bien las métricas SaaS, conversiones, ingresos, etc. De equipo, solo sigo la velocidad pero no como métrica de rendimiento, sino para predecir lo que puedo lograr en un release o los próximos tres meses. La gestión de cronograma aún cuenta.

Tomo la velocidad para estimar fechas probables de los épicos futuros. Pero al entregar en producción diario o mínimo cada dos semanas, si algo sale dos semanas después, no pasa nada grave.

Y así puedes dar más libertad al equipo. Los squads gestionan su propio rendimiento mediante pair programming, cross-testing y code review. Se corrigen mutuamente y comunican claramente qué hay que mejorar.

Eso se ve en los dailys, en las retrospectivas, que son abiertas a stakeholders y dueños de producto desde el inicio. Compartimos feedback de desempeño y calidad.

Esa retroalimentación es parte de la cultura. Todo el que ingresa obtiene feedback de todos, y cualquiera puede señalar problemas de desempeño o calidad, o el propio novato puede decir cómo podemos mejorar procesos, la empresa o yo misma como product manager.

Solo hay dos opciones: no pasar la prueba o rendir bien; entonces no hace falta seguir midiendo el desempeño.

Galen Low: Muy interesante. ¿Puede llegar a ser intenso?

Julia Ryzhkova: Puede serlo, pero generalmente todos están alineados. Si alguien ve un problema, todos lo reconocen y se da el feedback. No hay problema real.

Galen Low: Y como decías, está en el ADN del proceso de contratación: buscan personas con mentalidad adecuada y preparadas para el feedback desde el inicio.

Julia Ryzhkova: Sí, es algo que evaluamos en el proceso de recruiting. Dedicamos mucho tiempo e inversión.

Por ejemplo, para managers de producto organizamos una jornada completa de colaboración (ocho horas) resolviendo problemas reales con alguien del equipo y un ejecutivo de nivel C. Observamos cómo reacciona el candidato al feedback. Es una inversión enorme de la empresa porque una alta dirección y product manager ceden un día completo para decidir.

El candidato también invierte, claro. Nadie recibe oferta antes de pasar por esa fase. Pero el resultado es óptimo: ambos lados perciben si encajan a nivel cultural, no solo técnico.

Para otros roles es menos tiempo (dos o cuatro horas), pero siempre queremos sentir ese encaje.

Galen Low: Eso lo dice todo. En muchos procesos hay pruebas arbitrarias, pero aquí el contacto real para medir la dinámica es muy valioso. Quizás no todas las estructuras lo permiten, pero para asegurar la calidad y afinidad, lo veo fundamental.

Julia Ryzhkova: Para el candidato también es una inversión, pero mejor dedicar un día que pasar tres meses para darse cuenta de que la empresa no le encaja. Y nosotros no hacemos ese proceso con todos los roles, solo según el nivel y el impacto: para algunos dos o cuatro horas basta, pero la interacción es obligatoria siempre.

Galen Low: Muy bien. Cambiando de tema: como product manager gestionas el roadmap, haces promesas de entrega… ¿Qué pasa cuando cambias el roadmap, repriorizas o modificas fechas? ¿Qué actitudes esperas del equipo frente al cambio?

Julia Ryzhkova: Te sorprenderá, pero… no pasa nada. Puedo sacar tareas del sprint o añadir otras, explicando el contexto; por ejemplo, debemos… y se discute, y ya está. Puedo cambiar el backlog a mitad de sprint y no detenemos nada, a veces si son pocas tareas.

Si hay que hacer grandes cambios, solemos revisar roadmap una vez al mes, incluyendo insights nuevos o métricas de los dashboards.

El equipo ya lo sabe y participa en las sesiones estratégicas con los ejecutivos para compartir desde su perspectiva técnica. Incluso aportan sugerencias; por ejemplo, al cambiar el modelo de precios, un ingeniero advirtió que, al integrarnos con otra herramienta muy popular, las tarifas ya no cuadraban y propuso ajustes. ¡Eso fue increíble! Y el equipo acepta los cambios: en mis primeros seis meses, cambié tres veces de herramienta de gestión de proyectos—de Trello a Coda, luego a Pivotal Tracker y finalmente a JIRA. Siempre fueron flexibles: “¿Necesitas ayuda? Solo danos una miniformación y listo”.

Eso me inspira mucho.

Galen Low: Lo es. Cambiar la herramienta de gestión suele ser traumático, la gente necesita cierta estabilidad aunque sea solo en “su” herramienta. Pero aquí lo que resalta es que buscáis personas con mentalidad de producto, no solo ingeniería, diseño o marketing.

Sería bueno profundizar en qué implica esa mentalidad, pero creo que es visión de negocio: basta con explicar el “porqué” del cambio, y el equipo lo comprende. Así, cuando dices “hay que cambiar el modelo de precios”, saben que es por y para el cliente, el usuario final y el negocio. No es cuestión de “pero ya llevaba medio sprint con esto”, sino de “esto es lo mejor para el producto o el cliente”.

El producto es cambio. Y es lo que más destila de esta conversación: el trabajo consiste tanto en responder al cambio como en planificar, organizar y comunicar. La estabilidad absoluta no existe. Hay que saber responder al cambio.

Julia Ryzhkova: Una cosa más: al hablar contigo recordaba una conversación reciente. Un desarrollador me decía que sentía estabilidad por tener backlog planificado para varios sprints, aunque le daba igual si cambiaba del todo. Simplemente sabe que hay tareas y conoce la visión. Ve la hoja de ruta global y eso le da sensación de estabilidad, aunque los detalles cambien. Solo discutimos tareas pendientes al inicio del sprint, pero saber que hay material suficiente da tranquilidad.

Galen Low: Sí, es transparencia y confianza. Compartís la visión, y el equipo no es solo un conjunto de “manos” ejecutoras, sino parte real del rumbo del producto.

Eso permite independencia, autonomía y sensación de seguridad. Muy bueno.

Por cierto: ahora que mencionamos cambios de backlog y velocidad, muchos dirán: “Vale, esto funciona para desarrollo ágil, pero ¿y otros equipos?” ¿Crees que este modelo vale solo para ingeniería ágil o puede implementarse en cualquier equipo funcional de producto?

Julia Ryzhkova: Hay que ser ágiles, pero entendiendo el manifiesto ágil—que no dice que hay que hacer software, ¿verdad?

Todos nuestros squads aplican enfoques similares; marketing, finanzas, operaciones… todos saben estimar, hacer grooming, gestionar roadmap, usar story points y medir velocidad, como en equipos de desarrollo.

Galen Low: ¡Eso da para otro episodio! Muchos oyentes desearían que marketing fuese ágil: backlog, sprints… Hay resistencia fuera de desarrollo y diseño, pero toda organización debe planteárselo. Ser ágil significa ser flexible ante el cambio, lo cual es útil para cualquier departamento.

Julia Ryzhkova: Como mencionaste, ingeniería y diseño usan Scrum, pero marketing usa Kanban; tienen su hoja de ruta y les sirve mejor. Pero todo es ágil al fin.

Galen Low: Así es. Muy claro.

Vamos al meollo porque seguro que muchos oyentes tendrán preguntas. A menudo se pone en un pedestal el proyecto liderado por un PM o el auto gestionado, pero ningún modelo es perfecto.

Para quienes estén pensando en migrar a este modelo esperando la utopía, mejor preguntar: ¿qué errores o problemas han surgido?

Julia Ryzhkova: Pregunta complicada. Suelen ser problemas de alto nivel.

Es decir, un squad no siempre sabe lo que ocurre en otro. Por ejemplo, tenemos dos productos (Mailtrap y Coupler.io). El equipo de desarrollo de Coupler.io lanzó muchas funciones que el pequeño equipo de marketing no alcanzó a cubrir en contenido y atracción de mercado.

En Mailtrap ocurrió lo contrario. Ahí la dirección decidió repartir recursos, asignando parte del marketing de Mailtrap a Coupler.io y gente de desarrollo de Coupler.io a Mailtrap. Estas son decisiones que los squads no pueden tomar por sí solos; se requiere dirección global.

Galen Low: ¿Quién toma esas decisiones? ¿Es de tu rol o es más nivel operaciones?

Julia Ryzhkova: Es tarea de C-levels. Yo informo la situación de Coupler.io en sesiones estratégicas y si necesito recursos, lo comunico. El PM de Mailtrap hace igual. Los C-levels, al no estar saturados de micromanagement, pueden decidir con claridad y equidad.

Galen Low: ¿El cambio fue permanente, temporal, introdujo bi-compartición de equipos?

Julia Ryzhkova: Es un enfoque mixto. Si es algo urgente, alternamos entre mover gente o contratar nuevos; el equipo lo acepta sin dramas, incluso si es por un año. Somos ágiles y flexibles.

Galen Low: Al final la raíz es el alineamiento entre squads. ¿Con qué frecuencia interactúan los de marketing y desarrollo en Coupler.io?

Julia Ryzhkova: Depende. Tenemos demo donde el equipo de desarrollo muestra novedades, y sincronización semanal donde yo actualizo sobre lanzamientos. Si hay que actualizar landings, releases, etc., marketing lo añade a su hoja de ruta. Ambos equipos pueden proponer cambios para los demás, que se revisan semanalmente y se priorizan en el roadmap. Así hay alineación. En marketing también pueden proponer cambios de diseño, mejoras, etc., y desarrollo igual puede pedir contenido para mails, etc.

Galen Low: Muy bueno. Otro aspecto es la distribución geográfica y de husos horarios. Tienes squads por el mundo. ¿Hay ineficiencias o la clave es ser hiper eficiente desde el modelo?

Julia Ryzhkova: Más bien al contrario, el trabajo remoto permite ser más eficiente. El reto puede ser la coincidencia de horarios para llamadas puntuales, pero solo eso.

El 80% del equipo trabaja remoto, repartido en 15 países, y, con documentos compartidos y canales públicos, la organización funciona muy bien. Trabajamos y nos comunicamos en modo asíncrono, así que no es imprescindible coordinar tantas reuniones en horarios internacionales.

Galen Low: Importante distinción: el trabajo asincrónico no significa “nunca reunirse”. Y también diferenciar entre trabajo remoto y trabajo desde casa: no son lo mismo. Puedes estar remoto y tener oficina y, con la documentación y cultura adecuada, la comunicación sigue siendo clave. No hacen falta encuentros constantes si todo está bien documentado y accesible para todos.

Sobre los equipos autogestionados: ¿la gestión de proyectos resulta un estigma o tabú? ¿Los equipos ven al jefe de proyecto como algo innecesario, incluso problemático?

Julia Ryzhkova: No lo veo así. Nos gusta experimentar sin obligación de nada. No hace falta una formación PM completa. Preferimos compartir el know-how en guilds o según se necesite—por ejemplo, yo expliqué a operaciones cómo estimar tareas, qué es Kanban/Scrum, etc. Cada quien puede usar su presupuesto de formación si quiere profundizar, pero creemos que es mejor la formación puntual y específica según la necesidad.

Galen Low: Me gusta ese enfoque: compartir herramientas sin querer convertir a todos en PMs, ni los PMs en ingenieros, sino lo que favorece la colaboración y la entrega de calidad.

Para ir concluyendo… Como ex jefe de proyecto y ex directora de PMO que ahora desempeña un papel estratégico como product manager, ¿crees que los squads autogestionados son el futuro de la gestión de proyectos?

Julia Ryzhkova: Creo que es el futuro de las empresas de producto exitosas, sin duda.

Los equipos autogestionados permiten al jefe de proyecto centrarse en estrategia, producto y cliente, y ahí es donde puedes por fin dedicarte a lo “importante, no urgente”. De lo contrario, nunca tienes tiempo para eso. Mientras el equipo se encarga de lo “urgente, no importante”, generalmente fuente de agotamiento.

Eso sí, no todos serán siempre autogestionados: los juniors necesitan dirección y mentoring clásico al inicio. Incluso algunos seniors requieren deadlines externos. Siempre habrá espacio para la gestión de proyectos clásica.

No obstante, creo que toda empresa que quiera obtener resultados excepcionales en producto debe llegar al punto en que la autogestión sustituya la gestión directa de proyectos, liberando así tiempo para la estrategia y la mejora de procesos generales en vez de solo apagar fuegos.

Galen Low: Fantástico. Y estoy muy de acuerdo con eso de distinguir entre lo urgente y lo importante. Muchos PMs se sienten atascados en la gestión clásica y quieren ser más estratégicos. La clave está en el equipo y la cultura: empoderar puede acabar liberándonos para enfocarnos en lo realmente importante.

Y eso no significa perder el empleo, sino poder aportar más valor estratégico y dejar atrás lo urgente…

Julia Ryzhkova: La gestión de proyectos sigue siendo importante. Puedo ser menos jefe de proyecto al trabajar con equipos autogestionados, pero en otros contextos el PM seguirá siendo el responsable final de la entrega a tiempo y dentro del presupuesto, y eso es indispensable—salvo con equipos autogestionados, donde puedes delegar y pensar más en el “qué” que en el “cómo”.

Galen Low: ¡Eso es! Hay que elevar el rol y ser proactivos.

Julia, todos estos consejos son muy valiosos. Lo que más me resonó fue la mentalidad de producto. Antes creía que se trataba de pensar en producto como ciclo de vida, lanzamientos, etc., pero en realidad se trata de adaptabilidad y apertura al cambio: hoy un producto no es estático sino que evoluciona por el usuario, el cliente y el mercado, y estos cambian todo el tiempo.

La mentalidad de producto es la capacidad de responder al cambio y ser ágiles. Porque el cambio no es algo que te sucede, sino que es necesario para que el producto sea lo mejor posible. Y eso significa que tu trabajo, backlog, cronograma o incluso la herramienta de gestión pueden cambiar tres veces en un año. Pero ese es el verdadero sentido de la mentalidad de producto, y es vital para un equipo autogestionado.

Última pregunta: ¿Qué consejo le darías a una organización que quiera avanzar hacia equipos pequeños y autogestionados?

Julia Ryzhkova: Simplemente háganlo, no lo intenten: comiencen con un equipo pequeño, pero comiencen ya. No intenten aplicarlo a toda la organización si es grande. Reunan a la mejor gente, denles autoridad y aseguren resultados; los beneficios llegarán. Cuando los veas, harás lo que sea para trasladarlo a toda la empresa porque quieres el éxito. Y para lograrlo, hay que intentarlo con personas que encajen en el perfil que describí.

Galen Low: Genial, Julia. Muchísimas gracias por acompañarnos hoy. Me encantó la conversación y aprender cómo en tu organización están afrontando este reto, cómo funcionan vuestros squads autogestionados y el proceso ágil de desarrollo de producto del estudio.

Espero que los oyentes hayan aprendido algo y se lleven ideas para fomentar equipos más autogestionados y culturas colaborativas sin la amenaza de que los jefes de proyecto vayan a desaparecer en el futuro. Ha sido muy interesante.

Nos encantaría tenerte en el futuro, incluso hablar sobre la integración de IA en Coupler.io, pero eso será para la próxima…

Julia Ryzhkova: Espero poder compartir pronto esos insights.

Galen Low: ¡Genial! Gracias de nuevo.

Julia Ryzhkova: Gracias, fue un placer compartir porque todo esto me inspira mucho y espero inspirar a otros a seguir este modelo y disfrutar los resultados.

Galen Low: Maravilloso. Gracias, Julia.

Galen Low: ¿Y tú qué opinas? ¿Son los equipos autogestionados el futuro, o tienen límites que los hacen poco aptos en ciertos sectores u organizaciones?

Cuéntanos tu historia: ¿Cuál es el equipo más autogestionado con el que trabajaste y cómo fue? ¿Cuál ha sido tu experiencia más frustrante “arreglando el caos” en vez de ejercer tu rol estratégico? Déjanos tu opinión en los comentarios.

Y si quieres potenciar tu liderazgo estratégico en proyectos, ¡únete a nuestra comunidad!

Visita thedigitalprojectmanager.com/membership para acceder a una comunidad de apoyo que comparte conocimiento, resuelve retos complejos y construye juntos el futuro de nuestra disciplina.

Desde plantillas robustas y sesiones mensuales de formación que ahorran tiempo y energía, hasta el soporte entre pares en el foro, eventos y grupos mastermind, ser miembro significa tener a más de mil personas a tu lado mientras avanzas en tu carrera como gestor/a digital de proyectos.

Y si te ha gustado el episodio, suscríbete y mantente en contacto en thedigitalprojectmanager.com

Hasta la próxima… ¡Gracias por escucharnos!