The curse (and benefit) of the Epic culture

 Working at a place for 8 years -- through your 20s -- really shapes how you view the world, how you interact with people. I think about this more and more the further I get away from my time at Epic (I left in Jan 2023). There's some quirks I've noticed about myself as I venture into the outside world, double-edged swords. A few of the things I've been thinking about are below.

Speaking with certainty

We're trained to speak with our hospital customers with certainty and knowledge; better for someone to trust that everything you're saying is accurate, even if it means half your answers are "I'll get back to you." In healthcare, this works amazingly well -- it's a cornerstone of building long-lasting trust. Works less well in the real world / the investing world, where you can't possibly know everything and are rewarded for having an opinion.

Replaceability

Part of the Epic culture -- for better or for worse -- is that everyone is replaceable. My cynical take: the genesis culture of this is that turnover is/was high, so you need to ensure that if someone leaves, you can replace them. This works well when you have to travel to a customer site or go on vacation -- you can have real back-ups to replace you. A lot of energy thus goes into ensuring that other people can easily know what you're working on, into educating others on niche areas of the software, on building redundancy. In some investment firms (and in some governance structures), this replaceability -- a focus on process, on sharing -- is not a focus. 

Deference

At Epic, we supported the hospital IT's team who supported end users (doctors, pharmacists, etc.) Thus, as Epic staff, my goal was always to make the end users trust the hospital IT team -- and ideally, never know that I existed (unless I came onsite). I would go out of my way to ensure that the hospital IT team looked like the heroes instead of me -- good for them, good for me. Same with newer team members: the quicker customers trusted the newbie, the quicker I could roll off; feeding the newbie answers was a win-win strategy. However good this may be for the org, the "leading from behind" strategy is not visible enough, especially when switching careers. It's a hard skill to unlearn.

"Build it yourself" mentality

Epic famously does not acquire; any tool you wanted, you had to build yourself. I feel the same way now -- I'd rather build a tool that works just how I want it than try to find a pre-existing software that does 80% and locks me in. A blessing and a curse.

VC Notes (Part 3)

"In investing, you're rewarded for having a point of view." 

Heard this recently, and it's a mindset that's been hard for me (and other STEM majors?) to adopt. In my prior roles, I was rewarded for being knowledgeable, not saying wrong things, and couching my uncertainty. In investing, the best speak with knowledge and conviction, but it seems the next best thing is to speak with conviction but not necessarily knowledge. To sound impressive -- or to have a view, even if ill-informed -- can take you further. Investors don't like to hear "I haven't done my research on that topic"; it seems they'd sometimes rather force you to glom onto a position. Obviously, there's a lot more nuance than that, but I'm slowly learning how to thread the needle of speaking like an investor. 

Gut investing

I wrote about this a little previously, but it also feels like there's some flavor of machismo in some corners of venture where people "trust their gut" and increasingly "learn to trust it more." I've heard it at least a few times, and I think it's something that uniquely exists in venture as something that people are proud of? You never hear a fundamental equities investor talk about their gut as the sole driver of decisions. Anyways, I hear it a lot, I agree with "gut" as a data point, but I think it behooves everyone to tease apart what "gut" means (founder charisma? founder anti-charisma? etc.)

What it takes to build a novel software (e.g. computer science research) is drastically different than what it takes to distribute a novel software

Perhaps it's embarrassing it's taken this long to fully comprehend, but the cool stuff that computer scientists are doing seldom translates to a successful software company, especially in age of AI. Cool algorithms or cool technology usually don't sell; "dumb" software with great distribution are what matter. Most of the MAG7 today are fundamentally "dumb" software with great distribution (save Google perhaps). I've become increasingly cynical about the software technology itself being any sort of differentiator; it's the people and sales channels that make a tech product pop.

Same goes deep tech, say in climate. Great lab work (i.e. science research) needs to be coupled with even better engineering to have any chance of survival. Sometimes it's not the best core science, but the one that can scale up better that wins. 

Syndicate vs. the more modern sole lead

Historically, VC investors looked for syndicates of other investors to share risk. The largest VC firms now don't need -- or want! -- syndicates; there's too much money that needs to be deployed. Instead, it feels like it's sometimes better to elbow others out of rounds. Almost has a PE flavor to it. 

Authentic differentiation

This is probably more through the lens of an allocator, looking at VC funds. (We recently had a day where we saw a few of our portfolio VC managers.) The VC funds that resonate the most are the ones where the point of differentiation feels authentic -- ties back to the person's past career, past predilections, or a difference in the way the GP thinks that manifests itself as strategy. Hard to describe without naming names, but something I think about more and more as I build my "brand."

Progress on CRM

I wrote a few weeks ago that I had started to build a CRM tool. I've made pretty good progress, but I've realized that it's less about the CRM itself and more about building the tools that I want to see, with AI/document processing at its core. I've come to remember that I'm opinionated on making the tools as easy to use as possible, but also insistent on clean audit trails and ease of troubleshooting, as well as clean data structures and modular code. 

What's done so far:

• Core data models -- I've built out the core data models and data tables into Supabase. Users can manually build companies, investment firms, and people into the system. 
• Document uploads -- Users can upload documents -- which can then create new companies, etc. in the system and link them automatically. I think this is the holy grail -- just upload documents and have it update your internal notes! 
• Audit trail -- I have a good audit trail mechanism built out, telling you how a company was created (manually vs. automatically), as well if individual fields were updated. May seem like overkill now, but I think a must longer-term (and something we can build on). Good foundations!
• Authentication -- started but not quite working. Google OAuth login enabled through Supabase. Something not 100% working
• Designed to be plug-and-play -- I've designed this to be plug-and-play for any investment firm. All you'd need to do is plug in a few of the company's own things (e.g. Supabase information, OpenRouter API key, and a few more things), and you'd be off and running! (This could also be deployed in a Docker and shipped to multiple customers!)
• Data pipelines -- Much of the data gets piped in from somewhere, on some sort of cadence. Examples: (1) some VCs look at a16z's website weekly to add to their sourcing queue, (2) CT Innovations could pull companies from the CT business registry weekly, (3) newsletters delivered to my email might contain start-ups I should check out. I have a simple data structure to schedule these pipelines, which will need to be built on with more use cases.

What's next:

• Vision of email-driven + automated workflows -- From what I've seen, investment workflows and communications are driven largely by email. Therefore, a good CRM should integrate into existing workflows, while having the capacity to augment them. What this looks like: the system tracks email flow, downloads documents (and automatically uploads them to CRM), and the CRM interprets where we are along in the process. A concrete example: if we're doing diligence on a fund, the CRM tool should (1) automatically download the pitch deck and supporting docs, (2) interpret them, (3) interpret and import important dates (e.g. expected closing date or other funds circled), and (4) ensure we follow up (either with a rejection or a request for updates, if it's been a few months since last communication). The system should drive the investor to do this, without having to configure anything additional in the system. 
• More granular company/investor data -- Next up from the data model side will be adding in things like revenue (for a single company), funds (for investment firms), and other data (portco allocation, percent ownership, cash flows, etc.) The challenge is finding a good, flexible data structure that can account for all the pieces of info you might want to store discretely. 
• Showing provenance of data -- Data can come from multiple sources e.g. public/published articles, hearsay from other investors, and source documents from the company itself. The system should be smart enough to track the data provenance -- revenue numbers from the company themselves are much better than a guesstimate from a published article, which are much better than a rough estimate. This distinction is crucial for contextualizing the system data (and thus for downstream AI processing)
• Handling Excel and better text extraction -- Right now, the text extraction (i.e. PDF -> text) is pretty good but not bulletproof, which'll be important for trusting the numbers. Likewise, we don't handle Excel yet. (Excel documents are universally tricky for LLMs to handle.) Both are fixable but more technical problems; better to get a rough version 1 of the entire system before honing in on these challenging minutiae. 
• Integration with other vendors -- So far, I have integration with Google OAuth for login. Perhaps some integrations with other parts of the investment stack (e.g. CRMs, knowledge management tools, financial tools) to allow this tool to orchestrate everything together.

What I've learned/observed about AI and sustained human superiority:

• Humans still need to make decisions -- I can use AI to help me build the data models and SQL tables, but I (as the human) still need to make decisions on how simple or complex the data models are. LLMs often over-engineer, so it's still up to me to set a good foundation by building a simple but strong core data model. (These data structure tradeoffs are nearly impossible for AI to handle -- it doesn't know exactly what I want to build next, so it doesn't know what foundation to lay!)
• A silly example: if we had robots that could build a house, we would still need expert humans to help guide us through the trade-offs (e.g. how many bathrooms, what materials to use, cost vs. quality of material, which type of siding, etc. etc.). No difference in engineering code.
• AI lacks taste -- For some decisions, like on UI layout, the AI adds a bunch of crud which makes the app look/feel distasteful. I'm no designer, but I think on many decisions, I have taste that AI will never quite be able to capture. 
• Humans know when to quit (and where to be creative) -- My AI coding agent was dogged in trying to fix a particular issue -- it tried to brute force its way through the problem, without success. After about 20 minutes (and a few failed updates), I pushed it to try a different solution.  (Technical detail: I asked it to make a synchronous call asynchronous, and update/centralize code to make this work.) The new solution worked well. It's a case where a human (me) knew when to say: "This is taking longer than it should, and I have other good ideas on how to fix this that match my longer-term vision better." This is also a case where knowing how the underlying system works is crucial -- if this were vibe-coded, there'd be no way to know the root cause of the problem, or approaches to fixing it. 
• AI coding agents are great at execution -- AI coding tools are very good at writing code. The more prescriptive you can be, the better the execution.

Claude Co-Work vs. In-House Tools

Just a month or two ago, the tech world boasted about how many tokens it burned (i.e. how large its operating expense was). That party didn't last long. The consensus now is that for many jobs, hiring a person is easier/cheaper than hiring an AI agent. 

This has been my fear with agents all along: (1) what kind of agent truly needs to run automatically 24/7 and (2) how many tokens would this eat up needlessly. Side note: I got burned with cloud hosting on both Snowflake and Databricks for a personal project -- billed for cloud/GPU capacity that I wasn't using at all -- so I'm more sensitive than most to trusting tech companies with my credit card.

I've also consistently heard great things about Claude Co-Work. I've been tinkering with building my own tools for a while, and I had a moment of panic: is there any use in what I'm building, or am I reproducing things that Claude (and thousands of other smart developers) are already building?

ChatGPT helped drum up where the tradeoffs are. I put them below, as a reminder to myself that in-house tools -- ones that you know how they work, that link to the data you want, etc. -- have lasting value. Maybe not as a venture-backable company, but real time-saving workflow value. 

Anyways, here are the top dimensions where building your own software really shine over what Claude (or similar) offers. 

Dimension	Claude / Chat UI	Custom Pipeline
Time-to-value	Extremely fast	Slower
Repeatability	Weak/moderate	Strong
Flexibility	Limited	Full control
Structured data extraction	Okay	Excellent
Audit trails	Weak	Strong
Multi-stage workflows	Awkward	Natural
Integration with database	Limited	Native
Cost at scale	Can become expensive	Often cheaper at volume
Vendor lock-in	High	Low
Human-in-loop review	Limited	Fully customizable

Intuition vs Process

In the investing world, there's a tension between intuition and process. 

Some of the "greats" that I've met seem to eschew frameworks or process. The thinking goes: process makes your lazy -- you think better if you start from "first principles" every time. On the face of it, it feels like it should be correct; great investors are great because they've had to teach it to themselves from the ground up. What makes an investor great is their ability to think and diligence. 

It feels like some investment firms (especially smaller ones) are designed with the solo investor in mind. There is no firm standardized process, no standardized sourcing pipeline, no general training. To do so would constrain the investor, who needs to use their gut to make their decisions (so the thinking goes). A framework would stand in the way of intuition.

However ... when you assess funds as an LP, a lot of focus is on process: can we trust this manager to produce alpha, and do they have a replicable process? To assess this at larger investment consultants is the other end of the extreme. The investment framework is truly a process, a 200-plus-line Excel spreadsheet of investment criteria which is then synthesized into a memo. The intuition purists would say: yes, you've checked every box, but you've missed some je ne sais quoi about the investment, something not in your checklist that makes it stand out (or makes it fall apart). There are parallels to Atul Gawande's The Checklist Manifesto, where checklists improve surgery (and air flight safety) despite being initially despised by surgeons (and pilots, etc.)

All this to say: the investment firms that will be most successful with AI will be those that translate process into software-codified systems -- i.e. investment in AI will be all about process. One example: right now, as a firm, sourcing at some places feels spontaneous -- every investor has their own set of connections, resources, rules, etc. Some of this could/should be codified in agentic workflows; I've started to collect a list of "high quality" sources (e.g. a16z speedrun, etc.). Another example: we have a light investment memo template, but many questions are asked beyond what the template contains. These questions should ultimately be subsections of the template, which can then a yardstick by which to measure investment diligence. This means updating a core investment framework template, to ensure that that questions is answered every time. 

On one hand, I hate it -- filling out a 200-question survey (and adding questions to it) seems to take the joy out of reading, learning, and investing. On the other hand, it's a bit embarrassing to miss certain pieces of diligence over and over again. And as a newer investor, it's a bit bewildering to be given tens of documents to read, without a rough mental framework in mind. 

Ultimately, I'm coming to believe that "investment experience" might just mean "I've built a really solid investment framework in my head." It means you know where to look first when doing diligence, or what the top questions are to ask -- those sections of the framework are raising red flags. So why not hand out this framework to earlier-career investors? I think it's ultimately what we'll be training investment LLMs on, a long-time reckoning that investment process is essential.

Beginning a larger project: creating a CRM

 I've been putting off creating a CRM tool, but I think it's about time. Maybe CRM is the wrong word: I need a tool to store info about all companies, investors, people, etc. to be able to build on down the road. The tipping point: I want to create a sustainable sourcing framework that scrapes data from X source weekly. (Again, I am too "lazy" to do this weekly myself -- I'd rather list all the sources I want to pull from, and have it run automatically.) 

Part of this project is to see how long it takes to build something like this. I know a lot of folks are building these kinds of tools in Notion, but who wants to build a "Notion database" when you can build a more robust SQL one? I also think this sort of tooling is going to be critical scaffolding to build other AI tools on top of (e.g. document processing). 

My full vision makes this a little clearer:

1. Create core data models. Create data models for "organizations" (companies and investors), funds, people, programs (e.g. a16z speedrun, DARPA) and cohorts, as well as all the relationships between them (company-to-person, investor-to-company, program-to-company, etc.). Allow users to create/update these. All built in Supabase (backend), frontend in Streamlit (for now).

2. Create data pipelines. Populate companies from websites. For example, a16z speedrun cohort 6 was recent; the pipeline should be able to pull from their website and pull companies and relationships.

3. Audit trail. See who updated the companies (pipeline? user?) 

4. Add authentication, other usability tools. Let users log in via Google, email users when things are updated in the pipeline, make the scheduler work.

5. Add in investment details and company details. Right now we have the basics (basic company demographics, binary on whether an investment was made). Expand out to support a more full investment structure (e.g. X invested $Y in Z in Series A) as well as more robust company reporting ($X in revenue in 2025, etc.)

6. Add database partition? Find best way to make the database specific to a single investor, so that you can layer on multiple companies who can't see each others' data? (And try to stay in Streamlit for simplicity?)

6. Add in document processing. This is where it gets investor-specific. Process documents to extract revenue, investment #s, etc.

7. Add in other fun workflows? Allow users to connect their emails so you can see if you've emailed X company? Layer in automated meeting notes?

Hoping to be able to get through #1-3 this weekend; would be great proof-of-concept. The hard parts: database design (need well-designed database to withstand all future additions I'm planning!), knowing how to layer in the additions, knowing which order to tackle these in, knowing what the benefits/weaknesses of the tools (like Streamlit, SQL, scraping tools, etc.) are, hoping Google Antigravity is able to suss out what I want it to build with my instructions. 

The various modes of investment work

I've worked on a few deals in the past month, and I now finally have a lull to think a little more about how to use AI to automate/replicate some of the work I've been doing. I've been thinking a lot about the types of work that I do. Investment memo work falls into a few buckets:

• Information distillation - given a data room of information, distill it down into the main points
• Information search and aggregation - given a topic, try to find as many pieces of info on it and aggregate them together
• Information verification - given a piece of information, verify whether it's correct 
• Financial analysis - digging into the historical financials as well as checking the assumptions in the financial projections
• Anomaly detection - given a document or set of data, see if any piece of it is off/wrong
• Interviews with founders, experts, customers, etc. - requires a lot more EQ and conversational skills, but also preparation to tee up the highest impact questions for the investment (and the best fitting questions for the interviewee)

This all feels a little abstract and unnecessary, but teasing out these modes of investment work is the way a developer would look to approach a broader fix to the problem. And, more importantly: AI is going to be used in a different way for each of these modes of work. I think that LLMs are sufficiently strong where a lot of problems can be resolved through clever infrastructure (i.e. not just throwing everything into the chatbot and hoping it does everything we want). 

Some examples of the investment memo process that are particularly time-consuming:

• Industry background - a lot of "information search and aggregation" -- Googling, ChatGPT'ing for trusted sources, listening to podcasts, reading consultant market maps, etc. Requires a lot of exploration and breadth; feels a little like climbing a mountain, and the surrounding landscape becomes clearer bit by bit. 
• Competitors - "information search and aggregation" -- Google/ChatGPT for competitors, then look up info on each of them (market niche, traction, last fundraise, etc.)
• Public comps and recent M&A - "information search and aggregation" - Google/ChatGPT for this info, then look each up (e.g. in Bloomberg/Yahoo Finance for public comps, internet verification for recent M&A)
• Company (e.g. team, product, GTM, moats) - "information distillation" -- taking the whole data room and compressing it into a few pages of info. There's additional critical thinking (e.g. does their GTM actually make sense? are the moats really moats?), but otherwise a lot of depth here.
• Term sheet review - most terms are typically standard (or within reason), so this is both "information distillation" (taking a 30-page legal document and boiling it down to a few key points) and "anomaly detection" (seeing if there are any particularly egregious or atypical terms). 
• Traction/Financials - "Financial analysis", but then a lot of critical thinking and gut-checking on top of that.
• Investment benefits and risks - this feels like it should be a lot about "gut" ... but I think an LLM could surface many good benefits/risks (and a human could then review and prioritize them)

I've been working on a verifiable, AI-driven "information distillation" process. Given a data room of information (or a pile of industry reports from McKinsey plus a few internet articles I dug up), can I get the AI to synthesize the info rooted in the files I give it? 

Part of me feels a little foolish for doing this: the Googles and Anthropics of the world are already doing this, and they have teams that are much smarter than me! However, I think the tech giants are solving a fundamentally different problem. Their chatbots are generally interested in: "can I answer any question given to me well?" and "if the user uploads documents, can I answer any question he asks about it?" The challenges are at least twofold: (1) the chatbot has to retrieve info about any topic I might throw at it, and (2) it has to be able to answer any question I ask. 

My little tool is much simpler: given documents, read the info and file it away neatly into folders that I ask it to. The process looks something like this:

• Go through each document and extract information relevant to different buckets I give it (e.g. "company background," "team," "moats," etc.)
• After processing all the documents, take one final pass to synthesize the extracted data together

Advantages: 

1. You can apply this process to any document in the data room (just need to dial in the "folders" you file info into)
2. The extracted info and process are verifiable (unlike typical LLMs which are black boxes)
3. You can apply this process to many use cases -- just swap out the extraction schema and synthesis prompt

I'll have another post with more details, once I tidy up the development.

1.