My First 90 Days Inside a Portfolio Company

Every interim executive has a ninety-day plan, and most of them read like they were written by the same committee. Listen. Assess. Align. Fine words. But a portfolio company on a hold-period clock deserves something more specific than that, so here is what I actually do, in the order I actually do it.

The context: I've stepped into the CTO seat of a PE-backed company, usually because the burn is too high and delivery is too slow, and the value-creation plan assumed both would be fixed by now. The clock started before I arrived.

Days 1–30: read everything, touch nothing big

I start with paper, not code. The investment memo, the diligence report, the 100-day plan, the board decks since close. I want to know what the fund believes it bought and what it already suspects is wrong. Only then do I go into the systems, because architecture only means something relative to where the business is going, and in a portfolio company that destination is written down.

The other half of the first month is people. One-on-ones with every engineer if the team is small enough, every lead if it isn't. Not to evaluate them yet. To find out what they know that the diligence didn't catch, because they always know. The deploy that everyone fears. The system one person understands. The contractor who is quietly load-bearing. Thirty days of listening buys me a map no audit produces.

Two things I refuse to do in this window: reorganize, and re-architect. Both are irreversible-ish moves made with the least information I will ever have. What I do instead is keep the ships moving. The team keeps shipping whatever was in flight, and I make small, visible fixes: a broken deploy pipeline, an approval that takes a week for no reason. Early small wins buy patience for the bigger moves.

Days 31–60: cut the fat, fix the constraint

By week five I know where the bottleneck is, and it's almost never where the board deck said. Sometimes it's technical debt in one specific system. More often it's process: releases so painful they happen monthly, testing gaps that make every deploy a gamble, decisions with no owner. I've written about how I find the real constraint; the short version is that you follow the work, not the opinions.

Then I fix the loudest one thing. Not five things. One. In most engagements that means getting the delivery pipeline to a place where shipping is boring: automated tests where they matter most, deploys that happen daily instead of monthly, rollbacks that take minutes. The cost work starts in the same window, because by now the audit has found the money: cloud spend nobody right-sized, vendors nobody remembers buying, tooling that overlaps three ways. I cut aggressively and in sequence, each cut matched against the AI leverage that absorbs the work. Agents and copilots in the development loop are what let a leaner team ship like a bigger one, and they're what keep the cuts from becoming a slowdown.

This middle month is also when the honest conversation with the fund happens. By now I know which thesis assumptions the technology can support, which it can't, and how much of the promised cost savings is actually there. If a workstream in the plan was never realistic, day forty-five is when the operating partner hears it, with evidence and an alternative, while the plan can still bend without breaking.

Days 61–90: make it legible, make it durable

The last month is about two audiences: the board and my successor.

For the board, I make delivery measurable. DORA metrics, wired into how the team already works, reported as a trend line a non-technical partner can read in ten seconds. This is the difference between "engineering says things are better" and a chart that has moved for eight straight weeks. I've done the full low-to-elite DORA transformation in ninety days, and while every company starts from a different place, the direction should be visible by the first quarter-end board meeting. In one engagement, the shape of it looked like this:

For my successor, I write things down. The architecture as it actually is, the decisions I made and why, the risks I found and which ones I retired. A turnaround CTO who leaves behind a lean, documented function has done the job. One who leaves behind dependence on themselves has just built a different kind of key-person risk, which is the exact disease we were hired to cure.

What day 91 looks like

Sometimes I stay on through the permanent search, and helping define and evaluate that hire is part of the mandate. Sometimes the fix is done and I hand the keys to an internal leader who was ready all along and just needed the runway cleared. Either way, the test of the ninety days is simple: is the run-rate lower, is the company shipping faster, is the board reading numbers instead of narratives, and could I disappear tomorrow without anything falling over?

If you have a portfolio company where day one should have been a month ago, let's talk this week →