Field Note
Technology diligence should test change
Technology diligence can produce one hell of an inventory. Applications, infrastructure, contracts, architecture, security findings, team structure, technical debt.
Useful. The investment is still going to experience all of it through change.
Can the company launch a product, integrate an acquisition, enter a market, change pricing, consolidate systems, or recover from a failure at the speed the value-creation plan assumes?
That is the test.
Start with the value-creation plan
Technical risk is contextual.
A stable legacy platform may be acceptable for a business expected to grow through the same channels and products. The same platform may be a serious constraint if the plan depends on rapid acquisition integration, international expansion, subscription, direct commerce, or materially different customer experiences.
So diligence should begin with what the business intends to change.
Which capabilities create value? Which assumptions depend on technology? What must happen in the first year? Where would a six-month delay affect the model?
Without that context, diligence produces a list of concerns with no economic weight.
Trace one real change
Pick a representative change tied to the thesis and walk it through the organization.
For example: add a product line, onboard a new brand, change fulfillment logic, launch in another country, integrate a customer platform, or alter a pricing model.
Ask:
- Which systems and teams are involved?
- Where is the business rule owned?
- How is the change tested and released?
- Which vendors or specialists are required?
- What data must be corrected first?
- How long did a similar change take?
- What can fail and how is it recovered?
The answer reveals more than an architecture slide because it combines technology with the operating model.
Debt needs a consequence
Technical debt should not be reported as a large undifferentiated number.
Some debt increases incident risk. Some slows every release. Some creates vendor dependence. Some blocks a specific capability in the value-creation plan. Some is ugly and stable and should be left alone.
Classify it by consequence and timing.
That turns “modernize the platform” into a set of decisions: what needs to be fixed before growth, what can be contained, what should be replaced, and what does not matter to the thesis.
The investment does not receive value for making every system aesthetically current.
Test ownership and concentration
Key-person risk is often more important than the technology choice.
Who understands the pricing engine, integrations, deployment, data model, and production recovery? Is that knowledge spread across a team, documented and tested, or concentrated in one employee or partner?
Vendor dependence is not automatically bad. Unpriced and invisible dependence is.
The diligence should show which capabilities the company truly owns and what would happen if a critical person or provider became unavailable.
Separate capacity from capability
A team may be capable of the required work and simply underfunded. Another may have enough people but lack architecture ownership, delivery discipline, or skills for the target state.
Those problems require different interventions.
Adding headcount to a weak delivery system can increase coordination cost. Replacing the platform without building internal ownership can move dependence from one vendor to another.
The assessment should identify the minimum operating changes required to make the technology investment perform.
Produce decisions, not just findings
A useful diligence output connects evidence to action:
- risk to the thesis
- likely timing and cost range
- decision needed before close or shortly after
- dependencies and sequencing
- evidence still missing
There will be uncertainty. State it.
I do not expect diligence to predict every technology problem. I expect it to tell us whether the company can make the changes the investment is counting on, and what has to change if it cannot.
The inventory describes today. The transaction is buying what the company can become next.