Hacker Mindset

Hacker is a loaded term. I am using it in the older sense: a person who wants to know how the machine works and will make a small tool when the official one stops short.

When The Mentor wrote The Conscience of a Hacker, he was writing from a different internet and a different set of fights. The part worth keeping is not the outlaw pose. It is the refusal to stop asking how the machine works just because someone has wrapped it in authority. In healthcare that instinct has to grow up. Permission is not decoration. PHI is not a detail. Audit trails are part of the work. The job is not to slip around a boundary. The job is to understand why the boundary exists, then make the smallest lawful change that makes the work less stupid.

In Hackers and Painters, Paul Graham describes hackers as makers, people who learn by shaping the material. That is useful for operating work because the material is never the slide. It is the strange order of operations at a billing desk, in a referral worklist, or during a fund reporting close. You watch the work, build the rough version, see where it breaks, and keep only the pieces that change staff time, error rate, or handoff quality.

Legacy Systems Are Occupied Buildings

In How Buildings Learn, Stewart Brand follows buildings after the architect leaves. That is the useful analogy for software. People move in. They tape labels to doors. They block a draft with a towel. They learn which hallway is too slow and which room nobody uses. Healthcare systems age the same way. The EHR, RCM system, CRM, shared drive, payer portal, and finance model all change at different speeds. Some are replaced once a decade. Some are changed by a manager every Friday.

A fund sees patterns across portfolio companies, but it rarely owns the systems where the work happens. Data access may be partial. A vendor may block API access. A company may have five years of fields from a previous owner. The quarterly packet may depend on exports from systems that were never built for investor reporting. Complaining about the mess does not move anything. The useful question is smaller: who needs which signal, from which source, reviewed by whom, and by when.

Inside a portfolio company the questions get concrete fast. Intake staff enter the same field twice. Schedulers chase referral status in a portal. Billing teams learn about denial patterns after cash is already delayed. Operators need to connect staff worklists to EBITDA movement. Providers need less administrative drag without handing clinical judgment to a model. Sometimes the answer is a real integration. Sometimes it is a scheduled CSV, a mailbox rule, a browser automation, a read-only report, or an exception list that puts the right work in front of the right owner.

Creative Integration Is Operating Work

Most useful integrations are embarrassingly plain. A system sends a daily report to an inbox. A script checks the attachment, cleans up the columns, compares it with yesterday's file, and logs the rows that need review. Another version uses computer use to open a legacy portal, download the report a staff member already downloads, and stop when the screen or file does not match the expected trace. In a locked system, that may be the honest first bridge.

Access is often the work. Not every portfolio company can hand over clean data on day one. Sometimes compliance has the right concern. Sometimes the database is vendor-hosted. Sometimes the person who knew the export path left three years ago. Sometimes the only reliable source is a PDF report emailed every Monday. You do not wave that away. You map the sources that exist, write down the gaps, and build a reversible path before asking people to trust a larger change.

The first integration should be boring enough to explain and useful enough to prove itself.

AI Belongs Where It Leaves Evidence

AI earns its place in the messy middle, where ordinary scripts run out of structure. A model can classify referral notes, pull payer names from PDFs, summarize why a claim was denied, match a provider roster to a contract, or draft a field mapping that a human still approves. It should leave a trail: source file, confidence, missing field, exception reason, reviewer, and final action.

A model talking beside the work is theater. A model inside the work has a job and a receipt. The claims team sees fewer touches per denial. The scheduler sees cleaner handoffs. The fund team sees sourced operating movement before it goes into an LP update. If the model cannot name the source, route the exception, and show the reviewer, it is not ready.

What The Fund Can Use

A fund can use this without pretending every company needs the same answer. Start with one operating question. Find the ignored source. Build a thin connection. Put review where the risk sits. Measure the signal. If the connection saves staff time, catches leakage, or makes a handoff cleaner, broaden it. If it only makes a pretty diagram, shut it down.

Bad hacks hide work. Good hacks reveal it. They have owners, logs, tests, rollback paths, and human review where the stakes require it. The fund team knows which portfolio workflow changed. The operator knows who owns the exception. The provider knows clinical judgment stayed with a person. The LP sees a sourced operating claim, not a story polished after the fact.

I do not think of this as edgy. It is closer to maintenance. Look at the system honestly. Respect the people already keeping it alive. Change the few details that make the rest work better. Do not wait for perfect access, perfect data, or a replacement system. Do not confuse AI with judgment. Portfolio work lives inside constraints. Healthcare work lives with consequences. That is why the small bridge earns its place.