When I joined the program, it had gone through many attempts without reaching production readiness.
Each previous attempt has made some progress – but no one has gotten the program into a shippable state.
No, the team was not solving technical problems that were wrong; The real problem was the lack of alignment at the system level. The system lacked a shared framework for aligning requirements, integration, and ownership across the system. When I examined them, three structural gaps immediately appeared.
First, the regulatory requirements were never finally mapped. In a compliance-heavy situation, that’s an important issue. Teams were actively developing features, but no one had a unified vision of how those features together satisfied regulatory constraints. Every uncovered gap becomes a strong barrier to extraction.
Second, the delivery was very fragmented. Each group works within its own tools, environment, and processes. Communication was inconsistent, and important information was lost between teams. Ownership existed at the component level, but no one was responsible for the final experience.
Third, what made matters worse – the needs themselves were emerging. The team not only tried to deliver the original range, but also to integrate new features and expectations introduced over time.
The work was happening, and progress was evident. But the program was preparing for local preparedness instead of system-level preparedness and did not meet the definition of done. And such a product was impossible to ship.
Change Begins With Real Understanding
The first thing I did was a thorough study of coordination – internal and external – to map what was actually working versus what was thought to be working. That alone had a huge impact.
We found integrations in different states of maturity, including some that were outdated or incomplete, and some that evolved differently from the way they appeared in the system.
The audit also revealed the real dependencies between parties and external partners, and brought other tasks into the system early, including legal ones, for example, revising contracts and statements of work where necessary.
Since then, we’ve redefined how progress was measured. Instead of tracking milestones at the component level, every testing environment had to represent something end-to-end: fully integrated, testable, and demonstrable. Not “this component is built”, but “this flow is running.”
We ran regular demos on this flow and gathered early feedback. That allowed us to catch problems quickly, refine the transaction continuously, and avoid typical late-stage surprises.
We also introduced a general framework for operation: shared tracking, clear escalation paths, defined ownership for each component, and common cross-group access.
Importantly, we worked hard to identify and manage dependencies, rather than allowing them to block further progress later. That change alone helped teams move from operating in similar silos to operating as an integrated system.
Once teams have a shared structure, shared visibility, and shared identity, execution ceases to be separate, and the system finally begins to flow as one, as intended.
Simplifying Action Without Simplifying the Problem
In a compliance-heavy situation, you can’t simplify the problem. What you can do is make it easier for execution to be managed around you by making the trade transparent.
Regulatory requirements were non-negotiable. The flow of financial transactions was supposed to be bulletproof. Some areas, especially the UX parts, we considered more flexible. We also moved some features to post-MVP.
The key here was alignment: everyone must understand governance. Where parties know what to do it should ship against what it can be to move, they stop arguing essentially under pressure and start releasing.
However, there was still time when failure felt very close. It’s time to set up the production environment and final validation. Due to regulatory constraints, access to that area was highly controlled – any change had to be planned in advance, fully documented, and approved by multiple stakeholders. In addition, only licensed workers were allowed to work in the area, which greatly reduced the resources available.
So, we ended up in a situation where we were working with limited time, limited visibility, a small pool of available people, and zero tolerance for mistakes. To stabilize ourselves, we switched to extreme planning and collaboration. Every task leading to an implementation has a clear owner, clearly mapped dependencies, and a timeline defined at a granular level. The launch itself was coordinated almost minute by minute across the engineering, marketing, and sales teams.
All this time reinforced to me that in complex environments, no one group has the full picture. The only way to work under that kind of pressure is to put those ideas together early, and keep them together. Execution then becomes less about control and more about alignment under pressure.
5 Pieces of Advice for a Leader Inheriting Evil
The feeling, in the first 30 days, when you find a system that fails, is to start fixing things immediately. In my experience, that thinking is wrong. Your first goal is to understand where reality diverges from speculation.
- Check the program as it really is. Map integration and dependencies. In complex systems, you can find outdated and missing components, as well as hidden dependencies. This step alone can completely reshape your understanding of programming.
- Specify end-to-end ownership across full systems. If no one is responsible for the dead-end feeling, the system will be stopped regardless of how strong the individual groups are.
- Reconstruct requirements from an engineering perspective. Break them down according to their purpose. Find out what is truly negotiable, what is flexible, and what has changed over time. If not, the parties will prepare a different interpretation of “done.”
- Find the real critical method. Focus on the flow that determines whether the system can actually work. Everything else should be traced to that.
- Shift the way you measure progress. Stop tracking work or component completion. Start measuring whether the end-to-end flow is functional, compliant, and ready for production. That change changes the behavior of the group immediately.
In the first 30 days, your job is to make the ambiguity visible, align around it, and manage it continuously. Once ownership, requirements, and reality are aligned, execution becomes more predictable.
