The more I look back on the work I have done over the years, the clearer one thing becomes: what I do best is not simply delivering a project on time, but reorganizing work that could easily become chaotic into a rhythm that can keep moving forward.
My professional identity is still Agile Project Manager. But if I describe my work more precisely, what I have really been doing for years is building and stabilizing delivery systems. It is not just about making plans, tracking milestones, or pushing tasks forward. It is about connecting stakeholder alignment, dependency management, risk exposure, acceptance rhythm, and quality closure into a mechanism that can actually run.
That is also why I now have a much clearer view of where I want to go next.
For a while, I looked more toward large-scale frameworks such as SAFe. But over time, I found myself leaning more toward Nexus as the direction I want to go deeper into. Not because I reject scaled agility itself, but because I care more and more about one question:
Is a framework helping delivery become more efficient, or is it simply making the organization look more complete and formal?
To me, this is ultimately a Lean question.
One of the most important ideas in Lean is not just continuous improvement, but also eliminating waste. And in management and organizational design, waste is not limited to rework, waiting time, or communication overhead. Waste can also appear in another form: adding roles, processes, meetings, and layers that create little real value, simply because they make the structure appear more “mature” or “complete.” On the surface, the system looks bigger. In reality, flow becomes slower, decision chains become longer, and teams spend more energy maintaining the framework itself than delivering value.
That is one of the main reasons I now resonate more strongly with Nexus.
To me, Nexus is not a framework that tries to become large for the sake of being large. It is a way of thinking that feels much closer to Lean: when multiple Scrum teams need to work together, use as little additional structure as necessary to solve real integration, dependency, and coordination problems. It does not encourage adding complexity just because work is happening at scale. Instead, it focuses on introducing only the mechanisms that are actually needed, so that teams can keep their attention on delivery itself.
That direction fits very naturally with the way I have worked for years.
I have never been the kind of person who believes in a single standard answer. In real projects—whether software delivery, system integration, data migration, field implementation, or multi-party coordination—I have never depended on applying one framework exactly as written. What I have relied on is first identifying the core tension in the situation, and then deciding how to combine methods, how to design cadence, how to structure feedback, how to expose problems earlier, how to deal with dependencies sooner, and how to bring teams into real alignment.
Some situations benefit from a stronger Scrum rhythm.
Some are better managed through a Kanban-style flow approach.
Some require a tighter acceptance mechanism.
Others need cross-team integration and dependency handling to be addressed first.
The more I work in complex environments, the more I believe that mature agile practice is not about attaching yourself to one framework identity. It is about whether you can, based on Lean principles, combine different agile frameworks and methods in a flexible way, and make them serve actual delivery efficiency rather than forcing teams to serve the framework.
That is how I now look at Nexus.
I am not choosing it because it is another label to pursue. I am choosing it because it fits the management logic I believe in:
use as little as possible that adds no real value,
preserve the flow of useful information and feedback,
and keep cross-team coordination as light as possible while still effective.
To me, this way of thinking is not only relevant to software teams. It also applies to broader delivery organizations. In many organizations, the real problem is not the absence of a more complex framework. The real problem is the absence of a capability: the ability to see what is a real problem and what is merely formal complexity; what needs more mechanism, and what actually needs less.
That is also the kind of role I want to take on next.
Not simply finishing a project.
Not scaling for the sake of scaling.
But helping multiple teams build a genuinely effective shared rhythm around common goals; helping organizations solve dependency, integration, prioritization, and delivery stability problems without creating unnecessary overhead; and helping agile practice return to what it should have been about from the start:
delivering value faster, more steadily, and with less waste.
For me, moving from Agile PM toward Nexus is not about switching slogans or chasing another certification path. It is a more essential judgment formed through years of practice.
Project management taught me how to get work delivered.
What I want to do next is help reorganize multiple teams, in complex collaborative environments, into a system that runs efficiently through a more Lean way of working.