8. Assessing the IT organization: skills, structure, and key-person risk • EL BANTLI

The investment case assumed two things would happen fast after close: the buyer would connect environments, and the business would keep shipping product while the integration team standardized tooling.

The target’s CIO had a strong story. The IT org chart looked reasonable. The diligence deck said “team is capable.”

In the first month post-close, delivery slowed. Not because the architecture was wrong. Because the only engineer who understood the order-to-cash integrations resigned after their retention package “got delayed.” The rest of the team could keep systems running, but nobody could safely change them. Integration work paused, and the model’s quarter-two benefits moved to quarter four.

Tech diligence often treats the IT organization as a soft topic: a handful of interviews, a headcount table, and a paragraph about culture.

That’s a miss. In most deals, the IT organization is the constraint. It determines whether Day 1 is stable, whether TSA exit is real, and whether value levers happen on the clock the model assumes.

The primary decision is this:

Is the current IT organization (plus realistic augmentation) strong enough to run “business-as-usual” and deliver the deal agenda on time—or do you need to change the plan, pay for capacity, or protect the downside through terms and timing?

Why this matters to deal math (not just org design)

IT org issues don’t show up as “bad tech.” They show up as:

Clock slip: integration and separation milestones move because the team cannot execute change safely
Mandatory one-time cash: retention packages, interim leadership, backfill hiring, and vendor support become non-negotiable
Day-1 fragility: incident response, access control changes, and cutovers fail when there is no depth on critical systems
Hidden run-rate: “cheap IT” is often contractors booked outside IT, vendor-delivered run, or deferred maintenance that becomes your cost after close

If you want a realistic Day-100 plan, you have to underwrite people and operating model with the same rigor as systems.

The common mistake: counting heads instead of underwriting capability

Deal teams typically ask: “How big is IT?” and “Are they good?”

Better questions:

Who can keep the lights on without heroics? (run capability and resilience)
Who can deliver change while running? (change capacity and prioritization)
Where is knowledge concentrated? (key-person risk and vendor dependence)
Who can govern decisions with the buyer’s cadence? (decision rights and throughput)

The point isn’t to judge the team. It’s to predict execution constraints and price them into the plan.

A simple lens: Run, Change, Govern (and where the bench is thin)

Assess the IT organization in three motions. Every weakness maps to a failure mode you can plan for.

1) Run: keep critical services stable

What “good” looks like:

named owners for core systems (ERP/finance, customer platforms, data pipelines, identity)
incident management that closes root causes, not just tickets
credible on-call and escalation paths
tested recovery for the systems that actually drive revenue and reporting

What breaks in deals:

a small team can keep things running in steady state, but integration adds risk and change volume
buyers introduce new controls (MFA, segmentation, logging) and the run team gets swamped by access and stability work

2) Change: deliver programs without breaking operations

What “good” looks like:

a real backlog with prioritization and capacity allocation (not “we’ll fit it in”)
a release motion that matches the business (weekly/biweekly for product; structured cadence for ERP)
delivery roles that exist (product owner, architect, program manager), even if informal

What breaks in deals:

the “change” team is the same people as the run team; every incident steals delivery time
programs are vendor-led with minimal internal ownership, so timeline and quality depend on external availability

3) Govern: make decisions at deal speed

What “good” looks like:

clear decision rights for architecture, security exceptions, and vendor choices
a forum to trade off scope, risk, and timing (and actually say no)
finance partnership to translate tech work into cash and timeline

What breaks in deals:

decisions bottleneck at one leader, or get pushed into committees that can’t move fast enough for Day-1 constraints
integration/separation work fights with “business change” work, and nothing has authority to force trade-offs

What to ask for in diligence (artifacts, not opinions)

You can get most of the signal in a week if you ask for the right evidence. Five pulls beat five workshops.

1) The real org chart (including contractors and “shadow IT”)

Ask for:

org chart with roles, tenure, and location
contractor list with vendor, role, day rate, and who manages them
a list of “non-IT” teams writing scripts or operating systems (finance data team, RevOps admins, plant engineers)

Why it matters:

If critical capability sits in contractors or outside IT, you inherit continuity and retention risk. You also inherit a run-rate step-up if the buyer’s policies require converting contractors or moving work in-house.

2) A “system ownership map” for the top 15 systems

Ask for a one-page mapping:

system → primary owner → backup owner → vendor dependency → “can we change it?”

Include at least: identity, email/collaboration, endpoint, ERP/finance, billing, CRM, data warehouse, product hosting, integrations, and reporting.

Why it matters:

This is the fastest way to surface key-person risk. If backups don’t exist, you don’t have resilience—you have availability until someone leaves.

3) Delivery capacity and demand (backlog + programs in flight)

Ask for:

the current change backlog (even if it’s a spreadsheet)
the top 10 programs and their current staffing
a simple capacity split: run vs change (by team, not by hope)

Why it matters:

Most integration and separation plans assume capacity that does not exist. Diligence should force the uncomfortable truth: what will stop, what will delay, and what you must fund.

4) Incident and operational load (what run is really consuming)

Ask for:

6–12 months of P1/P2 incidents with root-cause actions
a weekly ticket volume trend and top categories
on-call and escalation coverage

Why it matters:

High incident load is not “bad ops.” It’s a capacity tax. If run work is already consuming the team, you cannot stack a deal agenda on top without adding people or reducing scope.

5) Attrition and retention risk (who is likely to leave and why)

Ask for:

12–24 months of attrition by role (including regretted attrition)
critical role compensation bands vs market (rough is fine)
any change fatigue signals: reorganizations, leadership changes, hiring freezes

Why it matters:

Deals change reporting lines, tool stacks, and job security. If the team is already thin, losing 1–2 people can move your timeline more than any architecture decision.

Key-person risk: how to spot it early (and what to do about it)

Key-person risk isn’t “there’s a strong engineer.” It’s when a single departure changes what the business can do.

Practical red flags

a core workflow (order-to-cash, month-end close, provisioning) is “owned” by one person
the backup owner exists on paper but cannot execute independently
integrations and scripts have no documentation and no test coverage
“the vendor handles it” but the vendor’s contract does not include change capacity or response SLAs you can live with

Decision triggers that should change your plan

If any “crown jewel” system has no credible backup owner, treat retention and knowledge transfer as mandatory one-time cash before you count on delivery.
If more than ~30–40% of critical run/change work is performed by contractors, assume continuity and cost risk unless contracts and day rates are locked and governance is strong.
If the team cannot name owners for core systems in under an hour, assume execution risk and slow the integration/separation clock.

How best teams de-risk key-person dependency

Do three things early, in parallel:

Retention packages for named roles (not everyone). Tie to defined milestones: documentation complete, cutover support, TSA exit, first integration release.
A 2–4 week knowledge capture sprint. System ownership docs, runbooks, “how we close,” integration maps, access lists. Keep it ugly but usable.
Shadowing and backup ownership. Assign backups with time carved out; don’t pretend it happens “after close” without capacity.

If you can’t do those three, don’t pretend the timeline holds.

Translating the org assessment into an executable deal plan

The output of this diligence stream should be a posture, not an org critique.

1) A Day-1 and Day-100 staffing plan (roles, not names)

Define:

what must be staffed for Day 1 stability (identity, security operations, core apps, finance reporting)
what must be staffed for the deal agenda (integration/separation program, data migration, ERP decisions)
what you will defer because capacity is not real

Then price the augmentation you will actually use: interim leadership, program management, security engineers, application owners, and vendor capacity.

2) A scope-and-sequence call that matches capacity

If the target’s team can run but cannot change fast:

sequence the agenda (stabilize → secure → connect → optimize)
delay the value lever that depends on change capacity (platform migration, app rationalization)
avoid stacking multiple transformations in the first 100 days

If the team can change but run is fragile:

protect run first (incident reduction, monitoring, access hygiene)
avoid big-bang cutovers

3) A deal protection posture (when the org risk is not curable quickly)

Sometimes the right answer is not “hire more people.” It’s to protect the downside:

reprice for mandatory one-time cash and run-rate increases
restructure the integration plan so synergies don’t depend on early connectivity
use close conditions where continuity risk is real (for example, minimum security controls in place)

What to do in the next two weeks (owners included)

If you want the IT org assessment to change outcomes, force it into the deal pack.

Build the system ownership map (tech DD lead + target IT lead). Top 15 systems, owner/backup/vendor, and “can we change it?”
Quantify capacity (tech DD lead + PMO). Run vs change split, current backlog, and the top 5 programs that compete with the deal agenda.
Name key-person dependencies and mitigation (deal lead + HR + target CIO). Identify 5–10 roles that set the clock; draft retention and knowledge-transfer plan with dates.
Price the augmentation (integration/separation lead + finance). Interim roles, vendor capacity, and mandatory one-time cash tied to specific risks.
Reset the timeline where needed (deal lead + IC sponsor). Make one explicit call: what moves, what stops, and what you will not promise in the first 100 days.

Deals don’t fail because an org chart looks imperfect. They fail because the plan assumes capacity and continuity that aren’t there. Underwrite the IT organization with evidence, and you can choose a realistic clock.