Early on, a lot of GC work feels heroic. You jump into contracts, product launches, board matters, financings, compliance questions, employment issues, and random fires, often in the same afternoon. That can feel valuable because the surface area is so broad. But over time you realize that reactive usefulness does not scale nearly as well as embedded judgment.

I felt that clearly in one period when a company I advised was moving fast on multiple fronts at once. It was signing referral agreements several times a week, often on different forms depending on the partner. It was bringing on a new client or two every month, again on different paper. At the same time, it was building a leaderboard and points campaign as a new product layer, while also launching a builder application as another new product. Everything was happening at once, and everything seemed to create a slightly different legal question. The business did not need a lawyer who could heroically re-answer the same category of issue every few days. It needed a legal operating system.

So I built one: contract templates and approved fallback positions for recurring deal types, intake forms that forced teams to surface key facts earlier, product review and launch checklists, simple approval thresholds for when legal, finance, or leadership had to weigh in, escalation paths for edge cases, and shared guidance for commercial and product teams so that routine decisions could move without starting from zero each time.

The real leverage comes from things that seem less glamorous: playbooks, fallback positions, approval thresholds, contract standards, escalation rules, training, intake design, and knowing which 20 percent of issues drive 80 percent of the legal drag. A good GC is not just answering questions. A good GC is designing the operating system through which better questions get asked.

The highest-leverage legal teams are not the ones producing the most memos. They are the ones quietly reducing chaos, increasing consistency, and helping the business make better decisions with less effort.

Working across several domains at a fairly deep level has made me more attentive to how ideas, systems, incentives, and human behavior interact. That kind of pattern recognition may not look like mastery in the traditional sense, but it often produces better judgment.

I see this daily at Thrive. When I’m providing legal product counseling, I’m reminded that a feature is never just a feature; it’s a marketing problem, a support burden, and – usually – a quiet decision about the future business model. Prioritizing customer needs and business objectives, while being informed by potential legal and regulatory implications, is a skillset that every good product owner needs.

Or prior to joining a startup, having spent over a decade working at some of the world’s largest companies. At Davis Polk, drafting airtight acquisition agreements for M&A clients or at Morgan Stanley, drafting error-free investment agreements with startup accelerator companies, were simply table stakes. At Thrive, we’re building new things every day, and while we have strong hypotheses through data and intuition, we have to make decisions before we know definitively if customers will buy something. One world trains you to reduce error before action; the other trains you to act before complete certainty. Good judgment is often knowing when to turn on one vs. the other.

Being a generalist does not always produce the cleanest title. But it can produce unusually useful judgment.

Usually, good product judgment looks boring at first. It often means narrowing scope, reducing edge cases, and resisting the urge to ship something that creates more risk than commercial upside. In startups especially, there’s a temptation to confuse more with better. But in product work, as in law, what gets removed is often just as important as what makes it into the final version.

Being an in-house lawyer at companies both large and small has taught me that the best legal advice tends to be “yes, and”. Often the “and” means a business model needs to be modified, a feature changed, or the scope narrowed. In all cases, by working side by side with product and engineering, legal becomes a thought partner, and technical teams use legal as a forcing function for sharper thinking.

If a product cannot be clearly explained to legal, it often cannot be clearly explained to users, regulators, or the market either. That’s not a legal problem. It’s often a product problem.

Building a startup is improv, where the cardinal sin is using the word “no” – just as you build a coherent and interesting scene in improv on the fly, so are you building a profitable startup with product market fit in real time.

In that sense, technology law made me much more bullish on simplicity. The best products, like the best legal analysis, make hard things feel obvious in retrospect.

Over the last fifteen years, I’ve lived inside a number of demanding environments that do not often get put in conversation with one another. I completed law and business school, worked at one of the most elite corporate law firms in New York, helped build and sustain legal functions inside global investment banks, and then left traditional institutions to join the founding team of a startup. Along the way, I’ve been a first legal hire, scaled a customer success function, worked across legal, operations, strategy, and special projects, and invested in more than fifty startups across fintech, crypto, digital health, consumer, food, real estate, and other sectors.

Some of my deepest lessons did not come from work at all. A life-changing medical malpractice event altered the way I think about time, fragility, and the body. Travel, community, and years of trying to understand health and performance changed the way I think about agency, discipline, and what it means to lead a life well lived. I’ve become less interested in impressive-looking lives and more interested in coherent ones. Less interested in status for its own sake and more interested in whether a person’s values and attention are pointed in the same direction.

My instinct toward building has been there for as long as I can remember. I started my first business at nine, collecting cans for a nickel while biking around the neighbourhood with friends. As a teenager, I co-founded nonprofits and helped raise over $1 million for causes I cared about. In my twenties, I started a media and events business. During the pandemic, I co-founded and later wound down a healthcare employee tech startup. I’ve started, scaled, abandoned, rebuilt, and reimagined enough things to know that building is not just about creating external outcomes. It is also one of the ways I’ve discovered who I am.

What I’ve seen over and over is that the same tensions repeat across domains. I’ve spent enough time moving across disciplines and ways of life to believe that some of the most useful insights come not from staying in one lane, but from learning how to translate between them.

This is my place to think in public about ambition, restraint, risk, reward, identity, and the long game of building a life that reflects what I truly value.

Thanks for being here.

— Martin