Avatar
Thom Kaleta
CTO | Private Equity
Technology judgment for private equity

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

A growth company signs a customer several times its size, and its board starts looking for its maturity gap. Security review boards, change management, disaster recovery testing. Those gaps are predictable and cheap to close, and unless something is badly broken, I would rather see a credible plan and a person responsible for it than watch a forty-person company spend twelve months trying to look like a Fortune 500. The gap that costs you money is in the codebase, and it is not on the checklist. Engineering forks the product for the whale. They copy the software, change it for the large customer, and keep the original running for everyone else. Fork is a friendly word. What the company has actually done is start shipping a second product while charging like it has one, and you underwrote the opposite. From the fork forward, engineering headcount grows with enterprise revenue. The multiple was built on that line staying flat.
2026-08-24
6 min read
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
The Ten-Minute Test Before You Fund More Engineers Somebody will ask you for more engineers this year, and they will make a good case. Releases are slipping, and the plan has slid two quarters. Before you fund it, read the document the team was building from. Ten minutes. It usually settles the question, and it usually settles it against the headcount. Almost nobody asks for that document. Diligence asks for the architecture, the source code, the cloud bill, the org chart. It rarely asks to see the spec behind the last feature that shipped late, which is close to the only document that tells you whether engineering is actually your constraint.
0001-01-01
6 min read