The First 90 Days of an Interim CIO at a Credit Union
The failure mode is an interim who spends ninety days being briefed. Stabilisation and assessment have to run at the same time, because the assessment is what makes the roadmap fundable. A working playbook with what to deliver and what to refuse.

The most common way an interim technology engagement fails is not incompetence. It is spending ninety days being briefed.
The pattern is familiar. Weeks one through four are introductions. Weeks five through eight are shadowing. By week nine there is a slide deck describing the current state, and by week twelve the permanent hire arrives and inherits a function that has not moved. Everyone was busy. Nothing was decided.
Avoiding that means running stabilisation and assessment at the same time, not in sequence. The assessment is what makes the roadmap fundable, and the roadmap is the only artifact that survives the engagement.
Days 0 to 30: stabilise
The goal in the first month is that the function stops degrading. Not improvement. Stopping the decline.
Establish a reporting cadence in week one. A weekly written update to the CEO covering what moved, what is blocked, and what needs a decision. This sounds bureaucratic and it is the single highest-leverage thing available, because a departing CIO usually takes the informal reporting relationships with them, and without replacement the CEO is flying blind exactly when they feel most exposed.
Triage in-flight projects into three buckets. Continue, pause, stop. Be willing to use the third. Most institutions in a leadership gap are carrying at least one project that everybody privately knows is not going to work, and which continues because stopping it requires authority nobody currently has. Stopping it in month one buys credibility for everything that follows.
Find the contract renewals inside the next two quarters. This is the most time-sensitive item and the one most often missed. Vendor agreements with auto-renewal clauses do not pause because your CIO left. A renewal that passes unexamined during an interim period locks in terms for three to five years. Pull the contract inventory in week one and sort by date.
Map the real risk surface, not the documented one. Talk to the VPs individually. Every technology organization has two or three people who know precisely what is fragile and have stopped raising it because nothing happened last time. They will tell an interim things they would not tell a permanent hire, because an interim is leaving and has no political stake.
Keep the team. A leadership departure makes good people update their CVs. The retention conversation belongs in the first three weeks, and it is mostly about telling people the truth: what is uncertain, what is not, and when they will know more.
Days 30 to 60: assess the real state
The assessment is a written document. Not a deck. A document, because decks let you skip the parts that are hard to say in a bullet.
What it covers for a credit union or community bank:
- Core platform and integration reality. What actually connects to what, which integrations are supported versus improvised, and where the single points of failure sit.
- Digital banking and member experience. Where the platform is competitive, where it is not, and which gaps members actually notice as opposed to which gaps show up in vendor comparison charts.
- Payments. Cards, ACH, wires, and real-time rails. Whether you are on FedNow or RTP, whether receive-only or send, and what the roadmap assumes about instant payments.
- Data and BI maturity. Almost always the largest gap between what the board believes exists and what exists. Worth being blunt about.
- Security posture and examination readiness. Open findings, their real remediation status, and what the next examination will surface. NCUA's 2026 supervisory priorities centre on balance sheet management, payment systems and fraud, and BSA compliance, which is a reasonable outline for what to look at first.
- Team and vendor dependencies. Which functions depend on one person, and which depend on one vendor with no exit path. Both are risks; the second is usually larger and less discussed.
The output should be readable by a board member with no technical background, and should contain at least one thing the organization did not want to hear. An assessment that flatters is not an assessment.
Days 60 to 90: a roadmap the board can fund
Boards do not fund architecture. They fund sequenced risk reduction with named owners, decision points, and costs.
The roadmap needs:
Sequencing with dependencies made explicit. Not a wish list. What must happen before what, and what the consequence of delay is.
Build, buy, or partner calls, with reasoning. For a credit union the answer is usually buy or partner, and the interesting question is which vendor and on what contract terms rather than whether to build.
A hiring plan, including the permanent CIO. Defining the role you are currently filling is part of the job. So is being honest about whether the organization needs the same role it had, which is not always the case.
Costs with confidence levels. "Between $400K and $700K, and here is what determines where in that range it lands" is more credible and more useful than a precise number invented to look decisive.
A first AI and BI governance position. Not a program. A position: what the institution will and will not do, who approves, and what gets inventoried. Examiners are asking, and having a one-page answer beats having a committee.
Eighteen months is roughly the horizon that gets funded. Three-year roadmaps are read as aspiration and deferred.
What to refuse in the first ninety days
Being clear about this early prevents the engagement from becoming something else.
Do not run a major vendor selection to completion. You can start one, scope it, and get to a shortlist. Signing a five-year core contract on the recommendation of someone leaving in four months is a governance problem, and a good examiner will say so.
Do not restructure the team. An interim can identify that the structure is wrong. Acting on it belongs to whoever will live with the result.
Do not become the escalation path for daily operations. If production incidents route to the interim, the function has an operational gap that interim leadership will mask rather than fix, and the gap reappears the day they leave.
Do not write production code. If the engagement drifts into delivery, it was scoped as leadership and is being consumed as capacity, and the leadership work is not happening.
What handover actually means
The engagement is judged on what remains afterward. At minimum:
- The written current-state assessment, with a dated revision history
- A vendor and contract inventory with renewal dates and owners
- A risk register that someone internal has agreed to own
- The roadmap, with whatever has already been funded marked as such
- Documented decisions with their reasoning, so the next person can tell what was chosen deliberately and what is accidental
That last one matters more than it sounds. Most organizations cannot distinguish between a decision that was made carefully and one that happened by default. Writing down which is which is a small act that pays out for years.
If an engagement ends and none of this exists, the institution paid for attention rather than for progress.
For how we structure these engagements, see technology leadership for credit unions and for community banks. If you are still deciding which model fits, the interim, fractional, or firm comparison covers that. Otherwise, book a call.