About Thom Kaleta

I’ve spent most of my career inside organizations at moments when something important about technology needed to change.

Over more than 25 years, I’ve worked across software architecture, enterprise architecture, product and engineering, infrastructure, enterprise systems, cybersecurity, modernization, M&A, and technology strategy. I’ve served as CTO and interim CTO, built and reorganized teams, inherited difficult systems, made investment decisions, and lived with the results.

Since 2021, much of my work has been in private equity. I’ve led or helped lead more than 100 engagements involving buy-side and sell-side diligence, portfolio value creation, carve-outs, integrations, architecture and organizational assessments, and interim technology leadership.

Seeing that many companies in a relatively short period gives you a different perspective.

Every company has problems. Technical debt, security gaps, aging systems, weak processes, organizational issues, ambitious roadmaps. The harder question is how much any of it actually matters.

Will it interfere with the investment thesis? Will it slow growth? Is there a large expense coming after close? Is the current CTO capable of leading the company through the next stage? Is management underestimating the problem? Is an advisor making too much of it? Those are the questions I spend most of my time answering.

I’m energized by situations where the answer is not obvious. There may be several plausible explanations for what is going wrong, and usually plenty of evidence pointing in different directions. I like getting underneath the symptoms, finding the real constraint, and reducing a complicated situation to a relatively small number of decisions.

Sometimes the answer is uncomfortable. A technology leader may be wrong for the next stage. An integration plan may depend on capabilities that do not exist. An AI initiative may be technically legitimate but have little economic impact yet. Other times, the technology is sound, the risk is manageable, and the right answer is to leave it alone.

My years as an operator matter here. I know what recommendations look like from the other side of the table. Real companies have budgets, deadlines, personalities, old systems, customers who cannot be disrupted, and teams that have to keep running while changes are being made. I account for that when I form a view and when I work with CEOs, CTOs, and their teams.

Today, most of my work sits directly between investment decisions and operating companies. I advise private equity firms during diligence, help translate what we learn into post-close priorities, and work with portfolio leadership when technology becomes central to the value-creation plan.

I work with deal teams on underwriting questions, with CEOs and CTOs on operating issues, and with investors when a technology problem becomes material enough to require a clear point of view.

What has become increasingly clear to me is the value of having that judgment close to the investment team and available throughout an investment’s life, rather than assembling it transaction by transaction.

That is the work I do now: helping investors and management teams understand what is really happening with technology, how much it matters, and what to do about it.

Pages

How to Make a Stored-Procedure Monolith Exit-Ready in 12 Months

The Diligence Killer Hiding in the Database Private equity deals don’t die because of strategy. They die in diligence. You can show a stellar growth curve, disciplined underwriting, and a strong sales funnel,but if the buyer’s CTO opens the hood and finds a monolith built on thousands of undocumented stored procedures, valuation takes an immediate haircut. Why? Because buyers don’t just buy earnings; they buy the ability to scale. A stored-procedure-heavy monolith is the opposite of scalable: it’s opaque, talent-hostile, brittle under load, and expensive to modernize. In diligence, that translates directly into lower multiples, longer timelines, and fewer bidders who stay in the game.

2025-09-10

6 min read

Exit-Ready Architecture

Squads are the Quanta

Individuals There must be KPIs for individual developers. In fact, I distinctly remember thinking the same thing when pressed by a VP who wanted to squeeze every ounce of productivity out of my team. My manager’s request was to have something like individual baseball stats (RBIs, Runs, Hits, Bases on Balls, Strikeouts). If we could measure individuals and eliminate the low performers, the rest would form a strong team. He was talking about Moneyball before the movie was released.

2025-09-02

15 min read

Exit-Ready Architecture: Designing Systems With The Next Buyer In Mind

When you prepare to sell a business, bankers talk about revenue growth, margins, and customer stickiness. But buyers have another silent multiplier in mind: your technology. In diligence, they don’t just ask, “Does it work?” They ask: “Can it scale without millions in re-platforming?” “Will our engineers revolt when they open the repo?” “Does compliance add risk or reduce it?” The answers drive valuation. Well-designed systems don’t win you the deal alone but they can shave months off diligence, keep bidders in the process longer, and protect 1–2x on your multiple. That’s why exit-ready architecture matters.

2020-01-28

3 min read

Exit-Ready Architecture