I'm 32. I've worked in private equity, retail technology, and now asset management, and the role that taught me the most about resilient systems was the one with the smallest transaction volumes I've ever dealt with.
In retail, we processed millions of transactions a day. In private equity, we might process a few hundred data points. And yet the PE environment was where I first genuinely understood what resilience means - because the consequences of getting it wrong were more visible and more immediate than anything I'd experienced before.
What private equity actually does, quickly
Private equity firms raise money from investors (pension funds, endowments, wealthy individuals) and use that money to buy companies, improve them, and eventually sell them at a profit. The firm makes its money from management fees and a share of the profits when investments are sold.
The technology infrastructure at a PE firm supports the people doing this: deal teams, analysts, portfolio monitoring, investor reporting. It is not high-frequency trading. The pace is different. But the stakes per decision are enormous, because each "transaction" might be a multi-hundred-million-dollar investment decision.
Due diligence season: the real load test
When a PE firm is seriously considering buying a company, they go through a process called due diligence. This means examining everything about the company: its finances, its operations, its technology, its legal situation, its customer base. Dozens of people across multiple teams are simultaneously pulling data, running models, producing reports, and sharing documents.
This is the load test that no one plans for. Not because it's unpredictable - it happens with every deal - but because the specific questions it generates are unpredictable. Someone will ask for five years of monthly revenue broken out by product line and geography, adjusted for a recent acquisition. They need it in two hours. Nobody has ever asked for that exact combination before.
The systems that could handle this reliably had one thing in common: they were honest about what they knew. Data was clearly labelled. Sources were documented. If a figure was estimated rather than actual, that was visible. If data was missing or stale, that was surfaced, not hidden.
The systems that fell over were the ones that tried to produce an answer no matter what - silently filling gaps with approximations, hiding uncertainty behind confident-looking outputs. These were the systems that caused someone to walk into a partner meeting with wrong numbers. That happened twice while I was there. Both times were bad.
The specific thing that changed how I think about monitoring
At my current firm I'm responsible for monitoring the trading infrastructure. We have dashboards showing latency, error rates, system health. Green means fine, red means problem.
What I changed after PE is that I am now extremely suspicious of systems that are always green.
In PE, the reporting systems were always telling us numbers were fine. They weren't always fine - they were just presenting stale data as if it were current, missing data as if it were zero, and estimated figures as if they were actuals. The dashboards were green because nobody had written the code to make them red when things were actually off.
Now I build in explicit staleness alerts. If a data feed goes quiet for more than 30 seconds, I want to know. If a metric hasn't updated in the expected window, I want to know. A green dashboard that I can trust is worth far more than a green dashboard that might be lying to me.
What retail taught me that PE couldn't
I want to be clear that retail technology taught me things PE couldn't. In retail I learned what genuine scale looks like. Millions of concurrent users. Real-time inventory that has to be accurate or customers order things that don't exist. Promotions that change pricing dynamically and have to apply consistently everywhere simultaneously.
The discipline that retail demands around data consistency - two systems cannot disagree about the price of an item - is the same discipline that PE demands around financial data, just applied to a different problem. I didn't realize how connected those two lessons were until I was sitting in an asset management firm trying to build infrastructure that could serve both a trading desk and an investor reporting team with confidence.
The through-line is this: the systems that serve people well are the ones that are honest about their own state. Not optimistic. Honest. They say "I don't know" when they don't know. They surface uncertainty rather than hiding it. They fail loudly rather than silently.
Building that kind of system is harder than it sounds. It requires actively choosing to show problems rather than hide them. Most systems, left to their defaults, trend toward false confidence. Fighting that tendency is most of what I do.
