Replace a departed AI project leader by commissioning a technical recovery assessment before hiring anyone to finish the system
The right successor must reconstruct what exists, determine what is salvageable and produce a credible completion plan before committing to new development.
Do not begin with a broad search for an “AI expert.” First preserve the code, data, infrastructure and decision history. Then hire a senior technical leader to conduct a time-boxed recovery assessment covering architecture, model behavior, data dependencies, security, deployment and unfinished work. Rohan Hall’s experience building AI systems and leading technology architecture informs this practical approach: assess first, stabilize second and resume development only after the evidence supports a plan.
Key takeaways
- Secure every technical asset and system dependency before changing the code or terminating accounts.
- Separate the initial recovery assessment from the larger contract to complete the project.
- Evaluate candidates on codebase discovery, architecture and operational judgment—not AI vocabulary alone.
- Require a written system map, risk register and prioritized recovery plan as assessment outputs.
- Preserve viable work, but do not let previous investment justify keeping code that cannot be operated safely or economically.
Treat the departure as a technical continuity incident, not an ordinary vacancy
When an internal AI leader leaves and development stops, the immediate problem is not simply an empty position. The organization has lost context: why architectural decisions were made, which experiments failed, how data moves through the system, what remains unfinished and which components are safe to change. Drawing on experience building AI systems and leading technology architecture, Rohan Hall’s work across AI and emerging technologies points to the central recovery principle: restore technical understanding before trying to restore delivery speed.
Your first objective is preservation. Secure the current source repositories, branches, model artifacts, datasets, data definitions, experiment records, deployment environments, issue trackers, design documents and vendor relationships. Record who still has knowledge of each component. Avoid large refactors, dependency upgrades and infrastructure migrations until someone has reconstructed the system. Early changes can erase useful evidence and make it harder to distinguish an old defect from a newly introduced one.
You are not initially hiring someone to finish the project. You are hiring someone to establish what the project is, whether it works and what finishing it responsibly will require.
This distinction also prevents panic from driving an expensive reset. A half-finished system can contain valuable data preparation, domain rules, interfaces and working services even when the overall product is stalled. Conversely, a polished demonstration can conceal missing evaluation, fragile data pipelines or a deployment process known only to the person who left. If confidence has collapsed along with delivery, use a structured framework for rescuing a half-finished AI system rather than asking a new hire to accept the previous plan at face value.
Preserve the evidence before asking anyone to diagnose the codebase
- Name one accountable business owner who can authorize access, gather records and make scope decisions.
- Create an inventory of source code, models, data, documentation, cloud environments, deployment workflows, monitoring, vendors and open technical issues.
- Preserve the current state of repositories, model artifacts and environments before allowing broad changes.
- Interview remaining engineers, data specialists, product owners and operational users separately. Ask what works, what fails, what is assumed and what nobody understands.
- Write down the intended business outcome and the minimum useful version of the system. Do not assume the current implementation still reflects that goal.
- Prepare a candidate briefing that describes the business objective, known components, current symptoms and available evidence without pretending the diagnosis is already known.
Data deserves separate treatment because code alone rarely explains an AI system. The successor needs to know where training, evaluation and production data originated; how labels or transformations were created; what versions were used; and whether current pipelines can reproduce prior results. If the team has prepared data but lost the person directing model development, the next step is a focused assessment of taking over model training after a lead leaves. That is a different assignment from repairing an application layer or replacing a chatbot interface.
AI toolkits are often experimental or difficult to integrate with existing systems, and platform fragmentation can make compatibility difficult to understand. Ask candidates to identify version constraints, unsupported dependencies and integration boundaries explicitly rather than assuming that every component can be upgraded or replaced independently.
Hire for technical discovery, not just model-building credentials
The person who takes over needs broader judgment than someone hired to train a model from a clean specification. Look for evidence that the candidate has entered unfamiliar systems, traced behavior across services, challenged undocumented assumptions and communicated trade-offs to nontechnical decision-makers. Relevant depth can include software architecture, data engineering, model evaluation, infrastructure, security and production operations. No candidate must be the strongest specialist in every area, but the leader must know when additional expertise is necessary.
Ask candidates to walk through how they would approach an unknown codebase during the first days of an engagement. A credible answer should begin with evidence gathering and controlled execution, not an immediate rewrite. It should cover repository structure, dependency inspection, test coverage, data lineage, environment parity, deployment history, monitoring and interviews with the people who still understand portions of the system. For a half-finished model specifically, compare that response with the questions involved in recovering a model nobody currently understands.
Rohan Hall has built AI and blockchain systems and has led technology strategy, architecture and a distributed global engineering team. He also has experience with operating systems, databases, software, programming and hardware. Those disciplines matter in recovery work because a stalled AI initiative is rarely only a model problem. It is usually a system problem spanning code, data, infrastructure, people and decisions.
Let’s talk about your business goals.
Use a paid recovery assessment before awarding the completion contract
A technical recovery assessment is a bounded engagement that reconstructs the present system, tests critical assumptions, identifies risks and produces an evidence-based plan for stabilization or completion. Its purpose is to replace inherited beliefs with verified technical understanding.
Separate this assessment from the larger implementation contract. That structure gives both sides a clear first commitment and reduces pressure to promise a completion date before the system is understood. The assessment should include access review, architecture discovery, controlled attempts to build or run the software, examination of data and model artifacts, targeted interviews and validation of the most important user journey or processing path.
The assessment should also produce a list of unresolved questions. Uncertainty is normal; hidden uncertainty is dangerous. If the original developers have left, as often happens with stalled conversational systems, use the more specific takeover questions in how to restart an abandoned AI chatbot project. A candidate who offers a firm completion estimate before reviewing repositories, data and environments is selling confidence rather than demonstrating judgment.
The organization first preserves the repositories, data and environments. A technical leader then maps the architecture, attempts a controlled build and traces one important workflow from input to output. The resulting report identifies which components operate, which depend on missing knowledge and which cannot be reproduced. Only then does the organization choose between stabilization, partial replacement or a broader rebuild. No invented deadline or predetermined rescue strategy substitutes for that evidence.
Decide what to preserve, replace or stop
“Avoid starting over” is a sensible goal, but it should not become an absolute rule. Previous spending is not proof that every component deserves preservation. The correct unit of analysis is not the project as a whole; it is each asset and dependency. A useful dataset, validated business rule or reliable service may survive even if the original model or application architecture does not.
- Stabilize and continue
- Use this when the core architecture is understandable, reproducible and aligned with the business objective.
- Preserve selected assets and replace the core
- Use this when valuable data, interfaces or domain logic exist but the central implementation is too fragile or unsuitable to operate.
- Stop or redesign the initiative
- Use this when the intended outcome is no longer valuable, essential assets are unavailable or the cost and risk of recovery exceed a newly defined alternative.
Make the decision against the minimum useful outcome established at the start. Do not compare the existing project with an imagined perfect system. Compare realistic paths by business value, operating risk, time to validated use, maintainability and dependency on scarce expertise. For specialized systems, such as an AI-powered quality-control application, the incoming leader may also need domain and operational specialists. The questions in finding someone to finish a specialized AI project help distinguish general AI experience from the expertise required by the operating environment.
Set explicit decision gates. One may follow the initial architecture and reproducibility review; another may follow a controlled proof that the most important path can operate. At each gate, decide whether to continue, narrow the scope, replace a component or stop. This prevents the rescue effort from becoming another open-ended project with a new leader but the same weak governance.
Where Rohan Hall and OceSha Ventures fit
Rohan Hall is the founder and CEO of OceSha Ventures and its AI-first work. The company builds and operates AI-first solutions for businesses and organizations, including course creation, branded academies, AI assistants such as Lumi and business intelligence. Rohan has built AI and blockchain systems, led technology strategy and architecture, and worked extensively across the United States, Europe and Asia. That combination is relevant when a stalled initiative must be understood as a complete business and technology system rather than an isolated piece of code.
His work also includes transforming expertise and existing knowledge into AI-powered courses, content, learning and business systems. OceSha’s AI assistants can support conversational websites, answer customer inquiries from information the business has reviewed and approved, and provide customer intelligence. These are concrete examples of why successful AI delivery depends on governed knowledge, usable interfaces and operational design—not simply access to a model.
For organizations considering a conversation, prepare the asset inventory, current symptoms, intended outcome and known risks before making contact. That allows an initial discussion to focus on whether the situation calls for architecture discovery, data or model recovery, product redesign, or a broader operating decision. If the project has been stalled for months and nobody knows where to begin, review the first steps for fixing a stuck AI project before assembling the briefing.
Rohan explores artificial intelligence alongside other emerging technologies in The Convergence of AI and the Top 10 Emerging Technologies. The book is the appropriate next resource for readers who want a broader treatment of how AI connects with technologies such as blockchain, neuromorphic technologies and cognitive intelligence. The immediate project decision, however, remains practical: preserve the evidence, commission an assessment and let verified findings determine what happens next.
Gather the current code, data, system records, known issues and intended business outcome, then use Rohan Hall’s home page to explore his work and ways to connect.
Prepare for a recovery conversationFrequently asked questions
Should we hire a permanent replacement or an external recovery lead first?
Start with the capability you need immediately: independent technical discovery. An external or interim leader can perform the recovery assessment while you decide whether the long-term role requires the same profile. Avoid making a permanent hire responsible for an inherited delivery promise before the codebase has been assessed.
What access should a recovery specialist receive?
Provide controlled access to the materials needed to reconstruct the system: source repositories, relevant data and model artifacts, architecture records, issue history, deployment environments, monitoring and available team members. Use normal security controls and grant access in stages according to the assessment plan.
How can we tell whether a candidate really understands legacy AI systems?
Ask for a step-by-step discovery approach and a sample structure for the assessment outputs. Strong candidates discuss reproducibility, data lineage, dependencies, deployment, evaluation and operational risk. Weak candidates jump directly to a preferred tool, model or rewrite without first examining the evidence.
Should the new leader keep the original architecture?
Not automatically. The architecture should be retained only where it remains understandable, reproducible, supportable and aligned with the business objective. Preserve valuable assets independently of the broader design; useful data or domain logic can survive even when a central component must be replaced.
What if there is almost no documentation?
Treat the running system, repositories, configuration, data flows, logs and remaining team knowledge as evidence. The assessment will take more discovery work, but missing documentation does not by itself prove that everything must be rebuilt. Require the recovery engagement to create the system map and operating record that the project currently lacks.
How do we avoid becoming dependent on one replacement leader again?
Make documentation, reproducible builds, shared repository ownership, recorded architecture decisions and cross-training part of the recovery backlog. Important operational knowledge should be distributed across the team and embedded in repeatable processes rather than retained by one individual.
The bottom line
Do not hand a complex, stalled AI codebase to the first person with an impressive model-building résumé. Preserve the system, define the minimum useful outcome and commission a bounded technical recovery assessment. The successor’s first deliverable should be understanding: a current-state map, reproducibility findings, a risk register and a prioritized path forward. Preserve components that are valuable and operable, but reject sunk-cost thinking. A disciplined assessment is the fastest responsible route to deciding whether to continue, replace selected parts or redesign the initiative.
Rohan Hall
Founder of OceSha Ventures · AI architect and author
Rohan Hall is a technology entrepreneur, AI architect and author with four decades of technology experience, now focused on practical AI across business, education, government and global impact. He founded OceSha Ventures, builds the OceSha AI platform and Lumi, and wrote The Convergence of AI and the Top 10 Emerging Technologies.
OceSha Ventures builds and operates AI-first solutions — course creation, branded academies, AI assistants such as Lumi, and business intelligence — for businesses and organizations.
Sources
About this page. Last reviewed .
It is based on his verified public professional record.
02eb619ba15f4e1a9d430a1ecd9bcd6d