Long Suciu es de esas personas cuya trayectoria hace que la transformación organizacional suene a algo que realmente podría funcionar si la persona adecuada está en la sala. Ha liderado equipos ágiles en Procter & Gamble, Gartner, Freeletics y Vistaprint, ha dado soporte a más de 30 equipos de producto simultáneamente, ha reducido los tiempos de entrega en un 75% y, de algún modo, ha conseguido que la gente deje de usar story points sin provocar una revuelta en la oficina. Patrycja Radwanska se sentó con él para descubrir cómo se ven dos décadas y media de rediseño operacional cuando le quitas el barniz de conferencia y llegas a la parte donde las cosas son desordenadas, políticas y, en ocasiones, simplemente están rotas.
Entrevista Expert Insight
Lo que sigue es un recorrido por la mecánica de escalar operaciones de producto: desde la primera semana diagnosticando una organización con problemas hasta el momento en que la planificación trimestral deja de sentirse como un pánico trimestral y empieza a sentirse como una cadencia. Suciu no trafica con eslóganes motivacionales. Trafica con configuraciones de Jira, estrategias de adopción de Productboard, dashboards de Power BI que los managers de ingeniería realmente abren por la mañana, y la incómoda verdad de que la mayoría de equipos ágiles están haciendo teatro de scrum sin darse cuenta.
Conclusiones clave
Conclusiones clave
- Confianza antes que cumplimiento: Empezar desde un lugar de confianza en vez de proceso impuesto acorta drásticamente el lead time de cada cambio posterior que quieras hacer.
- Elimina los story points primero: Cuando los equipos dedican más tiempo a discutir si algo es un 3 o un 5 que a hablar de cómo construirlo, eliminar la práctica por completo suele ser el shock más productivo para el sistema.
- La planificación trimestral es un flujo, no un evento: Una cadencia de seis semanas que construye incrementalmente – pensar, compartir, alinear, solidificar – supera la carrera de construir objetivos desde cero cada trimestre.
- Diseña las herramientas para impulsar comportamiento: Automatizar un mal proceso solo hace que tu mal proceso sea más eficiente. Configura Jira, Productboard y Power BI para reforzar los comportamientos que quieres, no para documentar los que tienes.
Qué se rompe primero cuando una organización escala
La respuesta, según Suciu, es predecible y casi cómicamente universal: todo, a la vez, porque alguien decidió que todo debía cambiar simultáneamente. El instinto de arreglarlo todo en un solo empujón transformacional es lo que rompe las organizaciones de forma fiable, no los problemas individuales en sí.
Su prescripción es lo contrario de dramática. Encuentra las cosas que son críticas y urgentes. Concéntrate ahí. Haz la transformación de forma incremental e iterativa. Suena al tipo de consejo que encontrarías en un póster motivacional en un coworking, excepto que Suciu lo dice con la especificidad de alguien que ha visto la alternativa repetirse docenas de veces.
“¿Cómo empiezas ese cambio desde un lugar de confianza en vez de un lugar de cumplimiento?”
Lo primero que hace cuando entra en una organización nueva es mapear los canales de comunicación informales: no el organigrama que probablemente lleva cuatro o cinco reorganizaciones de retraso, sino los caminos reales por los que fluye la información. Quién habla con quién en la máquina de café. Qué persona en producto es a la que todo el mundo acude porque es accesible, aunque no sea quien decide qué entra en el backlog. Estas redes informales son donde se esconde la mayoría de la disfunción organizacional, y entenderlas antes de intentar cambiar nada es la diferencia entre una transformación que se sostiene y una que se desmorona en el momento en que dejas de vigilar.
Teatro de scrum y el argumento para eliminar los story points
Suciu tiene un término para lo que encuentra en aproximadamente el 90% de las organizaciones con las que trabaja, y no es halagador. Teatro de scrum. Las dailies están en el calendario. Las retrospectivas están programadas. Las sesiones de refinamiento ocurren, y los story points se asignan a los tickets con la seriedad de un comité evaluador. Todas las ceremonias son visibles. Todas las casillas están marcadas. Y nada de ello produce resultados significativos.
Su enfoque diagnóstico consiste en hacer preguntas de tercer y cuarto nivel. No “¿usáis story points?” sino “¿qué hacéis cuando algo es demasiado grande? ¿Cuánto tiempo dedicáis al pointing? ¿Estáis re-estimando tickets después de terminarlos?” Esa última – re-estimar un ticket después de que el trabajo ya está hecho – es el canario en la mina. Si los equipos ajustan las estimaciones cuando ya saben la respuesta, la práctica se ha desacoplado completamente de su propósito.
“Automatizar un mal proceso solo hace que tu mal proceso sea más eficiente.”
La jugada que Suciu describe como una de sus favoritas es engañosamente simple: dejar de hacer story points. Solo la sugerencia tiende a producir una reacción que revela cuánto peso ritualístico tiene la práctica. Equipos que llevan 10 o 15 años estimando tickets experimentan algo entre la confusión y el pavor existencial. Pero cuando la práctica se elimina, lo que Suciu encuentra de forma consistente es que las conversaciones se desplazan hacia las preguntas que realmente importan – ¿cómo lo construiríamos, qué tamaño creemos que tiene, podemos dividirlo en piezas más pequeñas? – y la calidad de esas conversaciones mejora porque nadie está discutiendo si algo es un 3 o un 5.
Lee nuestro análisis completo sobre eliminar los story points
Planificación trimestral como cadencia de seis semanas, no como pánico trimestral
Una de las partes más detalladas e inmediatamente accionables de la conversación es el desglose de Suciu sobre cómo construyó un proceso de planificación trimestral en Gartner que no hizo que todo el mundo quisiera dimitir. La suposición fundacional es contraintuitiva: abandona la creencia de que cada trimestre empieza desde cero. La planificación trimestral debería ser un flujo continuo. Estás pasando de un trimestre a otro, no inventando un universo nuevo cada 13 semanas.
La cadencia que diseñó tenía tres fases de dos semanas. Las primeras dos semanas: simplemente empieza a pensar. Considera qué podrías querer hacer el próximo trimestre y de quién podrías necesitar ayuda. Probablemente no sabes qué necesitas todavía, pero probablemente sabes que vas a necesitar analytics, o UX, o DevOps. Las dos semanas intermedias: comparte tu pensamiento. No para conseguir alineamiento, sino para dar a todos transparencia sobre lo que otros están considerando. Las últimas dos semanas: solidifica roadmaps. Inicio del trimestre: presenta a dirección, que tiene la oportunidad de cuestionar prioridades pero no de inventarlas desde cero.
Todo el sistema fue diseñado para resolver un problema específico: cualquiera con suficiente peso organizacional podía anteriormente pasear por la oficina vendiendo proyectos favoritos a quien quisiera escuchar, sin alineamiento, sin priorización y sin cadencia. Los equipos invertían meses en trabajo que se abandonaba cuando el stakeholder que lo patrocinaba dejaba la empresa.
Lee nuestro análisis completo sobre la cadencia de planificación trimestral de seis semanas
Diseñar tu cadena de herramientas en torno al comportamiento
Suciu es enfático sobre un principio que suena obvio hasta que ves a la mayoría de organizaciones violarlo: las herramientas deben reforzar el comportamiento que quieres, no moldear comportamiento que no pretendías. El corolario es igualmente directo: si ignoras esto, las herramientas moldearán el comportamiento de tu equipo por ti, y probablemente no será lo que tenías en mente.
El ejemplo práctico que da es el viaje desde objetivos viviendo en presentaciones, pasando por objetivos en Excel, luego en Quantive, hasta finalmente objetivos y roadmaps consolidados en Productboard con integración directa con Jira. La progresión no fue lineal y no fue indolora. Quantive nunca logró la adopción que necesitaban porque nadie quería entrar en otra plataforma más. Pero cuando Productboard añadió soporte para OKRs, la consolidación se hizo posible: objetivos, roadmaps e ideas vivían todos en un lugar, y pulsar un botón creaba el epic de Jira cuando era momento de construir.
El efecto upstream fue que Jira se limpió. Dejó de ser el lugar donde cada idea se volcaba como un ticket y empezó a ser representativo solo del trabajo que realmente iba a ocurrir. Los product managers, que habían estado gastando sus días sumergidos en tickets de Jira en vez de pensar estratégicamente en roadmaps, finalmente podían trabajar en la herramienta correcta a la altitud correcta.
Lee nuestro análisis completo sobre la alineación entre Productboard y Jira
Los dashboards que nadie pidió pero que todos usaban
Los dashboards de Power BI que Suciu construyó usando datos de Jira funcionaron porque seguían un principio: eran legibles, accesibles y comprensibles para la audiencia a la que estaban destinados. Suena como un listón bajo. Es, de hecho, el listón que la mayoría de dashboards internos no logran superar.
El primer dashboard mostraba el objetivo de sprint declarado de cada equipo. No enterrado en un proyecto de Jira que requería cinco clics y saber en qué board mirar, sino ahí, todos los equipos en una pantalla, actualizado diariamente. El efecto fue inmediato. Los managers de ingeniería podían ver de un vistazo a qué se dedicaba cada equipo. Los directores de producto podían detectar desalineamientos antes de que se convirtieran en problema. Un director que creía que otro equipo iba a trabajar en su dependencia podía ver, de un vistazo, que el equipo tenía otros planes, e iniciar la conversación proactivamente en vez de descubrirlo tres semanas dentro del sprint.
El dashboard de visibilidad de backlog fue aún más revelador. Equipos con mil tickets en el backlog, equipos al día sin nada en cola, equipos con dos años de trabajo que nadie iba a hacer nunca. Suciu se acercaba a los equipos con backlogs inflados y preguntaba: “Aquí hay tickets creados hace más de un año. Representan el 25% de tu backlog. ¿Te parece bien si los archivo todos?” Planteado así – lógico, razonable, específico – era difícil para la gente decir que no en voz alta, aunque cada instinto les gritaba que acaparasen.
Lee nuestro análisis completo sobre dashboards de ingeniería
De 52 a 13 semanas: un caso de estudio sobre lead time
El caso de estudio más dramático de la conversación viene del trabajo de consultoría de Suciu con una empresa de APIs de la industria de viajes. Su ciclo normal era de uno a dos años desde el inicio de una funcionalidad hasta el despliegue. Así era como funcionaban las cosas. Los requisitos se empaquetaban en grandes proyectos, los proyectos se financiaban, se dotaban de recursos, y todo avanzaba a la velocidad de una cascada que nadie se había planteado cuestionar.
El enfoque de Suciu no fue darles un sermón sobre agile. Fue mapear el customer journey. Mientras el equipo desglosaba cómo los clientes usaban realmente sus APIs, los requisitos se descomponían naturalmente en funcionalidades discretas. Y entonces ocurrió algo que cambió toda la trayectoria: un director de producto miró una de esas funcionalidades y dijo: “Puedo usar esa funcionalidad ahora.”
“En vez de tener que obtener todas las funcionalidades antes de lanzar al público, el director de producto vio una funcionalidad que podía usarse inmediatamente.”
Ese único momento – un stakeholder senior dándose cuenta de que no necesitaba esperar al paquete completo – redujo el plazo de entrega de más de un año a un solo trimestre. La entrega incremental sustituyó al lanzamiento monolítico. El equipo empezó a construir cosas más pequeñas y a entregarlas antes, y la conversación pasó de “¿cuándo estará todo listo?” a “¿qué podemos entregar a continuación?”
Lee nuestro análisis completo sobre la reducción del lead time
La reorganización que empeoró todo
Suciu es refrescantemente honesto sobre los fracasos. Un equipo de CRM marketing con el que trabajó decidió dividirse de una organización única en un equipo B2B y un equipo B2C, organizados en torno a segmentos de clientes recién identificados. El business case tenía sentido sobre el papel. La transformación operacional se ejecutó competentemente: las bases de clientes se dividieron, las herramientas se reconfiguraron, los equipos se separaron limpiamente.
El problema fue que nada de ello generó diferenciación de negocio. Los ingresos no mejoraron. El crecimiento no se aceleró. Y el efecto secundario operacional fue devastador: dos grupos que habían colaborado intensamente, compartiendo ideas libremente y resolviendo problemas juntos, ahora operaban en silos. El muro entre ellos era organizacional, pero el daño era cultural. Gente que antes se acercaba al escritorio de un colega para hacer brainstorming empezó a depender de sí misma. La reducción en la colaboración llevó a una reducción en la calidad y la velocidad de todo.
Tras aproximadamente 18 meses, todo se volvió a fusionar en una sola organización. La lección que Suciu extrae no es que las reorganizaciones siempre estén mal. Es que la excelencia operacional solo puede servir a la estrategia de negocio que se le da. Si la estrategia es defectuosa, la mejor ejecución del mundo no la salvará, y por el camino puedes romper justamente la colaboración que mantenía las cosas unidas.
Transcripción completa de la entrevista
Leer la transcripción completa de la entrevista
Patrycja Radwanska: Welcome to Let’s Talk Operations. My name is Patrycja, and in this series we ask industry experts about their practical workflows and the specific B2B tools that they use. Today we’re receiving Long. Our guest has led transformation across companies like Gartner, Freeletics, and Vistaprint, scaling operations across dozens of teams, implementing systems like Jira, Power BI, and Productboard, and driving real measurable outcomes like reducing lead times by 75% and cutting defects by 80%. This conversation, though, is all about what actually works in practice. Welcome, Long.
Long Suciu: Thank you, Patrycja. Thanks for inviting me for this conversation. I’m super excited to talk about product and operations.
Patrycja Radwanska: We’re super happy to have you here. So just in one sentence, as we can start, tell us what you actually do today.
Long Suciu: Yeah. So I help teams and organizations be the best version of themselves, and that’s by designing, optimizing tools and practices to help good people do great work.
Patrycja Radwanska: That’s amazing. That sounds really good. So maybe let’s start with the scale, because I think everything breaks there. You supported more than 30 products and not only product teams. What is the first thing that breaks when an organization scales?
Long Suciu: Yeah, so one of those first things is trying to do everything all at once. And so what’s important as a leader when you’re trying to do any type of transformational organizational change is focus on the things that are important to get changed immediately, quickly, and do this in an incremental, iterative way that transformation. So regardless of what it is that you do, it’s always gonna be when you try to do everything and wanna do it in a short period of time, everything’s going to break. But if you look separate from the massive checklist of things to do and ask the questions, what’s most important, what’s critical, what’s urgent? Put your focus on there. Because also part of that transformational change is the teams, organizations are the ones on the receiving end of that change. And so how do you start that change from a place of trust rather than a place of compliance?
Patrycja Radwanska: Sure. So trust and prioritization, I think that’s the absolute must-haves.
Long Suciu: For sure.
Patrycja Radwanska: When you first started at a company, what is normally messy or unclear and how do you actually decide to prioritize what’s first? So how do you do this prioritization that you were just mentioning is so important?
Long Suciu: So, I think part of that is what’s often messy from the people doing the work to the leaders of the organization is what is a strategy. And understanding what that is. And then on top of that, what are the channels of communication that occur both from a formal standpoint, like from directs and leaders, to the informal conversations, the peer-to-peer or those that are just my friends over there. And I usually get all of my information from that person. The water cooler talk. Because this is essentially at the end of the day where the information flows. And the flow of information tends to be most often the messy part. When you go and you ask, hey, can you give me an organizational map? You’ll be lucky to get an organizational map. Or the version of that map that you have might be four or five orgs ago. So anytime I go into organizations, I wanna understand the organizational landscape, who’s where, where are the teams, who are the leaders and whatnot. And then spending time with the people within the organization to try to understand how information flows. And that tends to be the place where if you invest in the early stages of being introduced to a new organization, that is where you get most of your return.
Long Suciu: And for myself as a practitioner, it’s important for me to also do what I say or commit to what I’m being asked. Because I’m starting from a place almost of zero in terms of trust, right? I’m new. People, in good faith, will give me their trust. But you have to early on as best as you can solidify that and then incrementally build on that trust. Because further down the line, might take one year, might take two years, but at some point that trust becomes instant. And then when you reach that place of instant trust, then you’ll also start to find that the things that you want to do, because you see problems that others don’t see, the lead time to take an action on it or presenting it becomes shorter as well.
Long Suciu: And so I can speak to a place where we were trying to integrate – we were having this problem with sales. Bugs being reported by sales, not actually knowing what’s happening with them. The process at the time was sales would submit a bug in their tool, Freshdesk, that was their tool of operations. And then a sales support person would essentially contact somebody in product and say, I have this bug. And then that person would then maybe create a ticket. So this problem – you have bugs not being reported, bugs being reported but not being moved or not even knowing the status of them. We automated some rules in Jira such that the use of tags can direct the flow. And all we need for the sales support person to be able to do is just ask a standard set of triage questions. The tag goes on the Freshdesk ticket that syncs to Jira. And Jira says, oh, okay, I know which Jira backlog to create this ticket in. It actually significantly improved the visibility and transparency of bugs that were being reported, which was 100% capture of all bugs.
Patrycja Radwanska: And at the same time, we also hear a lot of companies that say, oh, we are very agile. What’s your first reaction or what are the patterns that you keep seeing when you hear that kind of a statement?
Long Suciu: Yeah. When I hear that type of statement, my first question is to try to understand why are you doing any of those practices? And can I try to decipher – are you applying the principles on which those practices are based? So what’s often coined as scrum theater. You have to start to ask third, fourth level questions. Oh, so why are you using story points? What do you do when something is too big? How much time are you spending on story points? Are you re-pointing a ticket after you’ve started it? Or even worse, after you finished it?
Long Suciu: And story points is a great example. Let’s not do story points anymore. Let’s just focus on the question of, how would you do this? How would you do this piece of work and how big is it? And what I’ve found is you’re able to bring the conversations within the team to the things that actually matter, which is how might we design this feature? How might we develop this feature? And the quality of the conversation starts to increase, and then the tickets themselves become smaller.
Patrycja Radwanska: Could you, from your experience, walk us through what would be the ideal quarterly planning process?
Long Suciu: Absolutely. So I think one of the key assumptions is to throw away the belief that every quarter you’re coming up with objectives from scratch. The quarterly planning process should be thought of as a continuous process. You’re just going from one quarter to another quarter. At the start of six weeks, all we’re gonna say is start thinking about it. Start thinking about what you might want to do next quarter. And then for the next two weeks, just think about who you might need help from. And then the next two weeks was around sharing with people what you believe are the things that you want to achieve. And then the final two weeks was build your roadmaps. And then at the start of the quarter was when we would share the objectives and roadmaps with leadership.
Long Suciu: You can also think of this as how do you scale team-level agile? Teams are working in sprints every two weeks. Organizationally, we’re gonna work by quarters. And then we know at the top level, the organization is in annual planning. And so we can have this cascading alignment way of thinking about our flows.
Patrycja Radwanska: Do tools shape behavior or should behavior shape tools? What’s your answer to that?
Long Suciu: So you should design your tools to reinforce the behavior that you’re looking for. And when you overlook that, yeah, the tools start to shape your own behavior, which may not be what you’re desiring. Now I always say to folks – automating a bad process just makes your bad process more efficient.
Long Suciu: We brought on board Quantive for our objective management platform. And we brought on Productboard for our roadmap but also product management platform. We integrated the tools such that a roadmap item in Productboard was linked directly to the epic in Jira. Productboard introduced OKRs into their platform. So we were able to consolidate objectives and roadmaps into Productboard, which then allowed product managers to easily associate objectives with features. And when it came time to do a feature – great, push a button, it creates the Jira epic. And so we kept Jira much cleaner.
Patrycja Radwanska: You built Power BI dashboards using Jira data. What made them actually useful?
Long Suciu: What made them useful is the dashboards that we worked on could be read and interpreted. They were readable, they were accessible, and they were able to be understood. One of the key things that we made visible for engineering and product leaders was what were the stated sprint goals of each of the teams. We created a dashboard that had every team’s stated sprint goal on there. And it was a very quick way for engineering folks to just look at what a team’s trying to do that sprint. We also looked at the size of all the teams’ backlogs. You could see teams had huge backlogs and teams had tiny backlogs. Some teams had a backlog that, if they stopped creating tickets, it would take them two years to complete.
Patrycja Radwanska: You reduced the lead time from 52 to 13 weeks. What specifically did you do?
Long Suciu: In this case, I was working as a consultant for this team. They built APIs for the travel industry. They typically worked on features that would get deployed a year to two years after they started. We just wanted to better explore what is the customer journey when they’re using the product. And the journey started to break down naturally into features. There was this aha moment where the product director recognized – I can use that feature now. Instead of having to get all the features before releasing it, the product director saw a feature that could be immediately used. And they did that within the quarter.
Patrycja Radwanska: Do you have any stories where a transformation failed?
Long Suciu: I’ve been working with a CRM marketing team that split into a B2B CRM and a B2C CRM. From a transformational operational standpoint, we were able to get them separated. But the split didn’t drive any business differentiation. And operationally, when we split these people apart that had worked very closely together, it actually created a silo. After about 18 months, it just got collapsed again.
Patrycja Radwanska: Imagine you have 30 days to fix a struggling product organization. What would you do in the first week?
Long Suciu: First seven days? It’s all about talking to people, looking at the tools, and understanding how they work. I look at how big is their backlog and then what’s the frequency of stuff getting done. And also, how big is your work in progress.
Patrycja Radwanska: Rapid Fire. One metric that every leader should look at.
Long Suciu: Flow efficiency. It’s the ratio of the time spent doing work versus the time that work spends being worked on.
Patrycja Radwanska: Most overrated tool.
Long Suciu: Any OKR platform. People believe we have this OKR platform, we’re doing OKRs. But doing objectives, doing OKRs, it’s hard work and it’s messy.
Patrycja Radwanska: Most underrated practice or tool.
Long Suciu: Keeping your backlog clean. It’s very easy to create tickets. It’s a hassle to review what’s there and to toss things out. Just like in your house, the less clutter you have, the easier it is to find what you need.
Patrycja Radwanska: One piece of advice for scaling teams.
Long Suciu: Start with trust and incrementally scale across. A place of compliance will easily fall apart once no one’s watching.
Patrycja Radwanska: This was a super masterclass in making product and engineering teams work at scale. Thank you, Long.
Long Suciu: Oh, thank you so much. It was an excellent conversation.
Herramientas mencionadas en la entrevista
Las siguientes herramientas y plataformas fueron mencionadas durante esta conversación.
Contenido relacionado
Por qué eliminar los story points es el primer paso en cualquier transformación ágil
Long Suciu explica por qué eliminar los story points -- una práctica que usa el 90% de los equipos de software -- suele ser el shock más productivo para el sistema cuando se transforma la forma en que los equipos planifican y entregan.
Una cadencia de planificación trimestral de seis semanas que escala en 30 equipos
Long Suciu construyó un proceso de planificación trimestral en Gartner que eliminó el caos del patrocinio ad-hoc de proyectos. Desglosa la cadencia exacta de seis semanas -- pensar, compartir, solidificar -- que trajo alineamiento a más de 30 equipos de producto.
Cómo la alineación entre Productboard y Jira eliminó el problema de las presentaciones
Long Suciu traza el viaje desde objetivos en presentaciones hasta un sistema Productboard-Jira totalmente integrado en Gartner: una transformación que consiguió que 70 product managers trabajaran a la altitud correcta y mantuvo Jira limpio para los equipos que realmente ejecutaban.