Picture this. You're the founder of a 30-person startup. You believe in "radical transparency." Every Wednesday at 4 p.m., you host an all-hands. This Wednesday, you calmly share that the board has flagged concerns about the runway model and is reviewing whether the next milestone is achievable.

You phrase it carefully. You take questions. The engineers nod. The marketers ask intelligent questions about strategy. Everyone says they appreciate the transparency. You go home feeling like you've done the job.

For the next nine days, your engineering team ships absolutely nothing substantive.

They check TechCrunch more than they check the codebase. Two senior engineers quietly update their LinkedIn profiles. The lead designer asks her partner if maybe they should hold off on the kitchen renovation. Nobody mentions the all-hands. Nobody says they're worried.

You thought you did the responsible thing. You did the exact opposite.

The Cognitive Light Cone

There is a term from developmental biology that explains this perfectly. A Tufts biologist named Michael Levin talks about the cognitive light cone — the spatiotemporal size of the biggest goal an entity is capable of pursuing. Not the things it can physically touch, but the goals it can hold in its mind.

A single cell has a tiny cognitive light cone: its goals operate over micrometers and minutes. A dog's is bigger: the perimeter of its yard, the food bowl, yesterday's walk. A human's is enormous. In fact, Levin notes that humans might be the only species capable of holding goals that are structurally impossible for us to attain. World peace. What happens when the sun burns out. The welfare of strangers a continent away.

Levin flags this as more than just a biological curiosity. It produces a unique, crushing psychological pressure: the experience of holding a goal you cannot reach.

This is exactly what happens when you give your IC engineer the runway update.

The board's runway model is well within a founder's cognitive light cone. The founder can pursue it as a goal, act on it, and pull levers to fix it. But when you hand that same trajectory to an engineer, it becomes a goal she is forced to hold in her head without any levers to influence it. She's been handed a goal that is the wrong size for her position. The light cone expands, but her action range does not.

You didn't transfer agency. You transferred unresolvable anxiety.

Why "Awareness" Isn't Free

In 1908, psychologists Yerkes and Dodson mapped out a concept that sits in every undergrad psych textbook: performance on cognitive tasks is an inverted U-curve based on arousal. Too little arousal? You're bored, slow, and sloppy. Too much? You're anxious, frantic, and sloppy. Peak performance lives in the middle.

When you hand someone a goal they can act on, you raise arousal in a productive way. They point at the thing. They do the thing. Arousal drops. Performance holds.

But when you hand them a goal they can hold but cannot reach, you spike their arousal with nowhere to put it. They ruminate. They doomscroll Slack. They write overly long emails. They make trivial decisions worse. And because the goal is fundamentally unresolvable from their position on the org chart, the arousal never decays.

Fifty years ago, cognitive scientist Herb Simon said it cleanly: A wealth of information creates a poverty of attention. Telling your team things they cannot act upon costs them the attention they desperately need to do the things they can.

The EM as a Filter, Not a Conduit

Over twenty years of working at startups, I have come to the view that the single most vital job of an Engineering Manager is to be a filter.

Most companies run on the conduit model. Information enters the top, the EM relays it downward in the name of "alignment" or "transparency," and the team is left to metabolize the stress.

The filter model operates differently. Information hits the EM. The EM holds it. The EM decides what is strictly actionable, translates it, and eats the rest.

The Conduit says: "The board is reviewing our runway."
The Filter says: "Our absolute top priorities this sprint are these two specific epics."
The Conduit says: "The CEO is terrified about Q3 churn."
The Filter says: "We are heavily prioritizing the onboarding flow this month."

This is not lying to your team. It is load-balancing.

Spotting the Difference

You can always spot a conduit manager's team the week after major company news. They are distracted. Velocity plummets. Résumés get polished. A few ambitious ICs try to "help" by getting involved in strategic decisions wildly above their pay grade—which is the most expensive form of distraction, because it forces senior leadership to manage the help.

A filter manager's team is heads-down. When the dust settles, they are surprised to learn what was happening behind the scenes. Some might initially feel betrayed. Most, upon reflection, understand exactly why they were shielded.

Can the filter model be abused? Yes. Bad managers use it to hoard power, hide toxic behavior, or protect a fiefdom. But the right response to those failure modes isn't to abandon filtering for reckless disclosure. The response is to be a leader who filters with such high integrity that your team trusts your shield, even when they don't know what it's blocking.

The Executive Playbook

If you are an EM or an engineering leader, here is what filtering looks like in practice:

Default to absorbing, not forwarding: When you receive executive information, the first question isn't "who needs to hear this?" It's "is there anything in this my team can actually influence?"

Translate, don't quote: Convert anxiety-inducing inputs into action-shaped outputs.

Triage by action range: If they can act on it, share it. If they can't, you reroute it to the limited group who can or you carry it.

Resist the transparency flex: "Radical candor" means giving honest feedback. It does not mean telling everyone everything.

Schedule the bad news: When bad news must be shared, batch it and deliver it with the action items already mapped out. Surprise, drip-fed anxiety is the absolute worst kind.

Be honest about scope: You aren't lying when you say, "This is not something your role can act on, and I am not going to make you carry it."

The Truth

This job is incredibly hard. You will carry weight your team never sees. You will absorb worry that has no outlet. You will occasionally be accused of being closed-off when you are actively bleeding to protect them.

Some of your team will resent the filter. Others will figure it out and thank you years later. Both will happen, because that is the job.

"46% of developers distrust AI output" is not a "How do we get the team to believe?" problem. We are engineers. We're not in the business of managing vibes. The value of AI on a task = generation cost saved − verification cost incurred.

The Only Equation That Matters

Stop asking "Can AI do this?" Capability is the model vendor's problem and it is improving at warp speed. Start asking "How cheaply can we verify this?" That part is yours, and it's investable.

Property-based tests, strong typing, contract tests, canary deploys, shadow traffic, feature flags — these used to be "good engineering hygiene." Now they're leverage. Every dollar that makes correctness cheap to check expands the surface area where AI is allowed to touch the codebase without turning into a liability. Make verification so cheap that trust becomes irrelevant. Trust follows verifiability.

Your Trust Map Resets Every Model Release

Trust isn't a scalar. It's not "do we trust AI?" It's a map: which task types, which corners of the codebase, which failure modes. Build an eval suite over your tasks, your codebase, and rerun it on every model release. When the map lives in evals, a model upgrade is no big deal - you're ready.

Ownership of Trust

Juniors over-trust because they can't verify. Seniors under-trust for identity reasons. The dangerous middle is the people skilled enough to skim-review and not yet scarred enough to actually check. Give SME engineers authorship of the verification harness. Convert the identity stake from "I am the one who writes the correct version" to "I am the one who defines what correct looks like." Same value, better system.

Put Trust in the Pipeline, Not the Person

The end state the frontier has already reached looks like this: CI gates that AI-generated code must pass. Eval suites that mechanically define what the current model is allowed to touch. Sampled deep review at a rate set by measured defect rates. And increasingly the verification layer itself is AI — models reviewing models, adversarial passes — with humans auditing the checker rather than every single output.

AI models will continue to improve at an insane pace. Build solid quality checks today so your business can improve at the same insane pace tomorrow.

"AI code is 90% right. The last 10%—error handling, concurrency, security, performance under load—still requires human expertise." Bollocks.

What people call the irreducible last 10% is not some mystical engineering judgment that only a senior human can supply. It is just undocumented memory: tribal knowledge that lives in Slack threads, post-mortems, tribal conventions about how this system actually behaves under load, the quiet constraints that were decided in a meeting three years ago.

State-of-the-art models do not fail at engineering. They fail at your context. The size of the gap is a direct measurement of how much of the system's real specification still lives only in people's heads. What we romanticize as "irreducible human judgment" is, in the majority of cases, a simple writing backlog.

The Pattern Is Universal (and Slightly Humiliating)

Watch how people actually use AI:

• Non-specialists say the models are already good enough for most work.

• Specialists say the models are impressive… except in their domain, where the output is obviously incomplete, naïve, or dangerous.

The same person who trusts an LLM to draft legal memos, marketing copy, or infrastructure-as-code will insist that in their particular specialty the last 10% is sacred. This is not evidence of unique human genius. It is evidence that the specialist has more private context than everyone else—and has not yet externalized it.

Frontier teams treat the gap as a conversion problem, not a capability problem:

incident → written constraint → context repository → eval case

Yes, genuinely novel failure modes and required adversarial creativity against surfaces nobody has attacked yet still exist. That residual is real. It is also far smaller than the current narrative allows.

Same Model. Different Harness. Wildly Different Outcomes.

Two teams can run identical weights and get completely different production results. The difference is not the model. It is the scaffolding around it:

• Living context repositories that the model can actually read

• Eval suites that encode the real constraints of the system

• Incident feedback loops that turn every surprise into durable documentation

• Verification infrastructure that catches the remaining 10% before it ships

The model is the engine. The harness is the rest of the car.

Automating Context

Don't bother sitting down and writing a perfect knowledge base from scratch.

Instead, record most of your internal calls and conversations (with appropriate consent and policy). Feed the transcripts to an AI whose only job is to extract the relevant constraints, decisions, failure modes, and tribal conventions, then file them into a context repository organized the way your models prefer to consume information. Keep the structure flat, searchable, and versioned. Prefer short, declarative statements over narrative. Tag by system, severity, and last-verified date.

Within a few weeks the repository becomes the missing 10%. The model stops hallucinating the parts that used to live only in people's heads. The "human expertise" gap shrinks to the genuinely novel edge cases—the ones that actually deserve human attention.

This is not a theoretical future. Teams that treat context as a first-class engineering artifact already ship with far less drama. The rest of us are still arguing about the last 10% while the real work—writing the system down so the model can see it—remains undone.

The models are already good enough. The remaining gap is your documentation.

You've bought AI tools, scaffolded the system, onboarded the teams, but adoption is happening at a seemingly glacial pace. Here are a few ideas you might try to grease the wheels:

Loop in Finance

Finance has seen one hundred AI vision decks and zero P&L transition models. Help them see the future.

Engineer salaries on R&D work frequently get capitalized—turned into an asset and amortized—under software capitalization rules (and, in the U.S., mandatory R&D amortization under Section 174). Inference spend is plain opex. It hits the P&L immediately.

So when you replace $2M of capitalizable engineering labor with $300K of inference, current-year reported earnings can look worse even though the real cost just collapsed. Your CFO looks at the plan and sees an earnings dip in year one, a crossover, and then a structurally lower cost base. They're not wrong.

Write out your strategic plan to paper over the dip with harness development—evals, context repositories, agent infrastructure. That work is itself capitalizable as internally developed software. The accounting asymmetry between "engineer building features" and "engineer building the system that builds features" is mostly a categorization fight, and Finance owns the categories.

Agree on one non-GAAP metric to report alongside the official numbers—output per fully-loaded dollar—so the board can see the real trajectory while GAAP works through the hangover. Helping your CFO co-author the transition model ensures he feels comfortable defending it. If finance is on your side, no one can stop you.

Loop in HR

Legacy company metrics still assume output scales with humans. Promotions are largely based on scope, span, and the complexity of herding other humans. Leading six people through a multi-quarter migration is still more likely to get you promoted than shipping the same migration alone in three weeks with an agent fleet.

To the existing HR system, agents register as smaller scope, fewer dependencies, and no one coordinated. Until "span of agency"—how much output you can actually be accountable for—replaces "span of control" in the leveling rubric, AI adoption will keep stalling while everyone performs the old playbook.

If you want to move the needle this quarter, ask your friendly HR leader to add a "leverage case" packet to promotion evidence: output shipped, harness built, verification responsibility carried. Then actually promote one visibly AI-native engineer on that basis. Once someone actually gets paid for working the new way, people will start taking your strategy decks seriously.

Loop in Management

Let's be honest about what most managers actually do: aggregate information upward and disaggregate instructions downward. Management is a routing layer for context. That is exactly the function a well-maintained context repository plus agents performs.

The new senior roles—harness owner, context steward, verification lead—are the highest-leverage jobs in an AI-native org. Your best managers are the natural candidates because they are already the org's context-routing layer. Show them how writing down what they route turns their tribal knowledge into compounding momentum for the organization and builds their next role in the process.

You might also try running one reference team openly—small, AI-native, real production surface—and publishing their numbers internally. Envy is a change-management program that runs itself.

Don’t Forget Your Quietest Engineers

If you are already running an AI-native team, you know the secret: your best engineers are heavily AI-leveraged and they are hiding it from you.

If a task scoped at two weeks with the sanctioned tools takes two days with covert AI, revealing that fact gets them a policy violation and more work. So they deliver in nine days as expected and bank the margin. Why wouldn't they?

Consequently every internal pilot is corrupted. That 15% lift you're celebrating is not the delta between "No AI" and "AI." It is the delta between covert adoption and open adoption.

Give them a Scoping Amnesty. Don't punish the saved time with more work. Suspend judgment on the methods. Let them use the reclaimed time for harness investment—better evals, context repo work, tooling. Now the engineer who reveals a 5x speedup gets something for it instead of losing something.

Good Luck and Godspeed

The entire AI transition is a repricing exercise. Your organization currently prices coordination. You need it to price leverage.

Prices only move when someone is visibly paid the new way. Everything else is commentary, slide decks, and another pilot that won't turn into a funded project.

Fix the incentives before your next strategy offsite.

You've been handed the assignment: some version of: "Put together our long-term vision for AI agents."

And there's so much noise. Which model is best this week. What your competitors are claiming. Whether humans are even still relevant. How are you supposed to work out what's affordable, what's buildable with the team you already have, and what actually fits your business model — while the ground keeps shifting under your feet?

I'll tell you how I do it, which I mostly learned from Rhythm Systems — an incredible company who you should definitely call if you're ever trying to firm up your strategy, align your entire exec team and organization to it, and knock your goals out of the park quarter after quarter.

I just use Claude Sonnet for this exercise currently (we're not doing any rocket science here), but use whatever AI model you prefer. Fill in the [COMPANY] and [DATE] placeholders with your own data.

Prompt 1: Reconnaissance

Research [COMPANY] as of [DATE]. I'm building a long-term AI agent product vision and need to size up the company first. Answer five questions, citing sources and flagging anything you couldn't verify:

1. Funding position — who owns or funds them, and what does that structure imply about appetite for long-horizon bets? Estimate the investors' likely exit window.

2. Business model — how do they make money, precisely? Pricing, secondary revenue lines, customer count.

3. Scale — headcount, trajectory, recent executive hires or departures.

4. AI maturity — what have they actually shipped, native versus vendor-supplied? Do they employ ML engineers? What have direct competitors shipped?

5. Strategic moves — M&A, platform plays, ambitions stated on the record.

Keep it under 600 words.

The output from this prompt will help ensure that your vision is fundable and buildable. Doing unglamorous homework before having opinions is the difference between a junior employee and a senior one.

Prompt 2: Read the weather

From that research, derive the 4–6 constraints that should dictate any AI agent strategy for [COMPANY]. For each: the fact, then the strategic implication in one line. Cover at minimum — the investor clock, the AI capability gap (build versus buy posture), the revenue shape (which metrics an agent must move to matter at all), the proprietary data asset, and the competitive window.

Every project has constraints. Your company has no ML engineers? Your vision should not include training and deploying AI models this quarter. The difference between a junior employee and a senior one is knowing to identify the constraint and name the mitigation: Milestone 1 might be to partner with a model provider, and hire or upskill one employee to own the unit economics of that partnership.

Prompt 3: Draw the mountain

Build a summit map:

• The summit, 7–10 years out. One audacious, measurable end state. Big enough to organize a decade, concrete enough to be proven wrong.

• Three basecamps, working backward, 2–3 years apart. Each gets a name, a window, a one-line thesis, and an explicit link to the investor clock: which basecamp pays the current investors, and which ones are the acquirer's or next round's upside story.

• A "required to reach" list per basecamp — what must be shipped, hired, built, priced, and measured.

Route everything around the constraints. If a basecamp violates one, flag it. Don't smooth it over.

I use the @mirohq MCP to draw, but you can use Excalidraw or whatever you like. The important part here is "Don't smooth it over." Junior work hides tension to make the deck flow. Principal work diplomatically puts the tension on the slide — these are actual decisions to be made, and ignoring them will be the death of your plan.

Prompt 4: One click down — operations and cost

For each basecamp, specify agent-operations guidance across six dimensions: runtime placement, agent identity and licensing, cost economics (model cascading, prompt caching, unit-economics rules), security and data flow, measurement, and change management.

Name the two dimensions that are primary at each altitude. Estimate annual cost as a range and flag every assumption. Then state which cost-discipline decisions must be architected early because they cannot be retrofitted at scale.

This starts to turn the vision into a plan. Anyone can say "AI agents." Saying "roughly $2–4M a year by 2030, and here's the decision we have to make in Q1 or the margins never work" is what gets you in the room where budgets happen — a room you definitely want to be in if you desire authority over the work. The outputs here are just suggestions, but they will provide the shape of the decisions you're being asked to make. Just go ahead and get them on a page, and you can massage them from here.

Prompt 5: The picture

Create a minimalist flat-design vector illustration for a strategy slide (16:9). A single stylized mountain in your brand color, built from layered silhouettes. Three flat ledges on the ascending face, connected by a thin dashed accent-color trail to a small flag at the summit. Generous negative space above and beside the mountain for text overlay. Absolutely no text, letters, numbers, or labels anywhere in the image.

Ban text explicitly, in those words. Image models will cheerfully invent labels that say things like "BASECAMP TWO." Annoying. You layer the real ones on your the deck.

The output

I'm obsessed with this Rhythm Systems-style mountain graphic method for communicating high level strategy and how we'll get there, in a way that feels challenging yet achievable. Look at the density of information you get in one slide.

This first draft is never the final draft, but it takes under an hour to build, helps me organize the problem, surface challenges in bite-sized chunks, and reveals things that maybe I hadn't thought of yet. I love getting things out of my head and into Miro where I can collaborate on them with lots of stakeholders and advisors before finalizing our vision.

If this was helpful to you, let me know what improvements you end up making to the process. We're all learning together, no gatekeeping.

"How do I patent my product so nobody copies it?"

I've gotten this question a few times this month. Always from accomplished people with real careers and deep expertise, building software for the first time.

The short answer is you probably can't, and it probably wouldn't help. Alice v. CLS Bank (2014) killed the idea that you can patent "your idea on a computer." If you assembled your product from AI coding agents and big thoughts, there's likely nothing novel enough to file on.

But the deeper answer is the one I actually want to give, because what's common sense inside our little bubble isn't intuitive anywhere outside it.

Software Is Not a Thing You Build. It's a Thing You Feed.

A patent protects an artifact. In software, artifacts are short-lived.

Code rots even when you don't touch it. You don't have to change a thing for it to break. Upstream dependencies change. Certificates expire. API versions sunset. Software isn't a machine you build and walk away from; it's a garden you water or it dies. Sometimes far more spectacularly and expensively than you'd imagine.

The build is the cheap part. Most of what software costs, you spend after launch. Marketing. Distribution. Customer support. Security patching. Every feature you ship is a promise you now have to keep. Even shutting it down costs more than you expect - you have to migrate everyone off first.

Nothing in production is temporary. That "I'll ship it now and fix it later" decision will become the cornerstone of the house of cards. You can change it fast with a coding agent later, sure - and break 99 other things, and lose your night. Thoughtful architecture goes a long way.

Nobody Understands the Whole System

Nobody understands the whole system. You'll have many users, with many needs, so you'll build many features. Some will be "temporary." "Experimental." "Just this once." In time you won't remember why a thing exists, what it connects to, or why it works that way. Write documentation, because you-in-five-years will be very frustrated with you-right-now. This compounds with every additional person touching the codebase.

Legacy code is a term of contempt for software successful enough to still be running. Languages most people under 60 have never heard of are clearing your paycheck this weekend. You'll depend on things you can't live without, written in ways you can't stand. Embrace it. Legacy code isn't going anywhere.

Most of your product is other people's code. In 2016, a trademark complaint over a package name led a developer to delete eleven lines of code, and all kinds of software broke across the internet. Every problem in every package you depend on is now your problem. Every vulnerability in them is now yours. If you're handling sensitive data - and almost all customer data is sensitive - this should keep you up at night.

The Ground Moves, and You'll Pay for It

The ground moves, and you'll pay for it. Every few years the industry changes its mind about the right way to build things. Sometimes it's a genuinely better idea. More often it's money - interest rates move, or investors want a different revenue shape, and suddenly everyone's product has to work a different way. You can get everything 100% right today and you'll still have to rebuild it in 3-5 years anyway. Conserve enough cash for your inevitable rebuild or be prepared to sunset when the pendulum swings.

What actually holds: Copyright is automatic on your code. Trademark your name; that one's worth the $350. Trade secrets are free and last forever, so don't publish your edge. Get IP assignment agreements signed by every contractor and cofounder - more deals get complicated by a missing assignment than by anyone getting copied.

AI collapsed the cost of creating software. It did nothing to the cost of owning it.

Your moat is distribution, the data you accumulate, and the fact that when something breaks at 11pm, somebody picks up.

Those compound. Code only decays.

Welcome to software.

Terminus documents are the small set of source-of-truth artifacts that agents read to generate everything else. If something in these documents is wrong, everything your agents produce will be wrong.

Each of our terminus documents has an assigned code owner, and no one can make changes to those documents without the code owner's PR approval.

If your agents produce something that doesn't look right, it can almost always be traced to a terminus document. It is best practice to update the terminus document rather than manually changing the output of your agents. This improves the system for the entire team, keeps everything in alignment, and prevents future mistakes.

Here is a look at some of the terminus documents that our agentic system is built upon:

Market Intelligence

positioning-architecture.mdx: Core story, vision/mission, value pillars, and why-now narrative — the root everything aligns to.

messaging-framework.mdx: Message hierarchy (top-line → pillars → proof points) that operationalizes positioning.

ideal-customer-profile.mdx: Validated ICP grounded in firmographics and pain-point prioritization.

market-segmentation.mdx: Segment definitions, scoring criteria, and GTM filter logic.

buyer-personas.mdx: User and buyer persona profiles mapped to value pillars.

competitive-landscape.mdx: Competitive synthesis vs. Pinecone, Weaviate, Qdrant, Milvus, Chroma, and pgvector.

Brand

brand-voice-tone.mdx: Canonical writing rules — urgently pragmatic, blunt, declarative, no hedging.

voice-eval/rubric.mdx: 7-dimension pass/fail rubric for grading external copy.

voice-eval/golden-set.yaml: Human-labeled calibration cases for the voice grader.

Commercial

sales-playbook.mdx: Discovery framework, objection handling, and competitive traps.

deal-qualification.mdx: Qualification criteria, gating questions, and disqualifier rules.

pricing-architecture.mdx: Pricing model, tiers, and packaging. (Load-bearing: changes require a decision-log entry).

icp-filter-criteria.yaml: Machine-readable ICP filters used by the autonomous crawler agent.

suppression-schema.yaml: Suppression list schema. (Don't cold email if the company is the wrong size, the person has the wrong job title, direct competitors, EU prospects, etc.)

Marketing

claims-vetted.md: Canonical vetted claims with sources — all marketing copy must cite from here.

competitors.md: Competitor reference snapshot (updated monthly).

format-rules.md: Markdown and citation rules for content-ops artifacts.

taxonomy.md: Shared terminology across marketing deliverables.

Product & Technical

product-positioning-brief.mdx: The bridge: how product capabilities map to positioning.

technical-differentiators.mdx: What makes our products technically distinct

feature-buckets.mdx: Top-level taxonomy for roadmap epics — auto-tagged in every spec and ADR.

tablestakes.mdx: The "good enough to displace top competitors" threshold by feature bucket.

roadmap.mdx: Canonical milestone view (detailed scope lives on GitHub).

Operational

decision-log/: Chronological rationale files for every load-bearing change. Required on substantive edits to any terminus doc.

automation-overview.mdx: All GitHub Actions workflows: schedules, secrets, inputs, and outputs.

agent-ownership.md: Every agentic automation across repositories: cadence, owner, consumer, and state.

Engineering

architecture-decisions/: Significant technical choices (ADRs) with context, decision, alternatives, and consequences.

specs/mission.md: Engineering mission and foundational design principles.

specs/tech-stack.md: Canonical tech stack decision and rationale.

development/repos.md: All repositories and their specific purposes.

development/branching-strategy.md: Git branching model and PR workflow.

Team Culture

code-review.md: Review process, routing rules, and mode-tag scrutiny requirements.

coding-agents.md: Mode-tag framework (mode:requires-expertise, mode:claude-led, etc.) gating review depth.

definition-of-ready.md & definition-of-done.md: Acceptance gates for work entry and completion.

qa-philosophy.md: Quality approach and testing strategy.

The Golden Rule

Any substantive change to a load-bearing terminus doc (positioning, pricing, ICP, code-review rules) requires a new entry in the operational decision log. Downstream artifacts — drafts, specs, battlecards, PRs — read from these; they do not feed back into them.

Establishing a rigorous set of terminus documents is the bedrock of any successful agent-driven workflow. By defining a single, unbreakable source of truth, you eliminate drift and ensure every output- from engineering specs to marketing copy- stays perfectly aligned with your core strategy.

Now, I'd love to hear from you: What are the foundational "terminus documents" your team relies on to keep your workflows and agents on track? Drop your must-have artifacts in the comments.

In my 20-year career planning and executing corporate transformations, I have never seen a shift so overwhelmingly thorough and complete in such a short period of time.

In just one year, we went from zero AI agents to a fully agent-driven organization.

This wasn't just a superficial tooling update. It required becoming deeply, intimately familiar with the company, product, and codebase. It meant creating documented context for all of it from scratch, architecting new technologies, training teams, and rebuilding roadmaps.

The most surprising part has been the shift in my own day-to-day. My working hours used to be consumed by planning and execution. Now, my time is spent on team member education, account provisioning, scoping permissions, and PR reviews. The execution is handled by the swarm.

The AI Maturity Curve

We didn't get here overnight. If you are charting your own organization's path, this is the exact maturity progression we experienced:

Tab Complete ➔ Agent IDE ➔ Context Engineering ➔ Compound Engineering ➔ MCP & Skills ➔ Harness Engineering ➔ Background Agents ➔ Autonomous Agent Teams

As we reached those final stages, the nature of "work" fundamentally changed. Here is what is now handled entirely by agents rather than human employees across our organization:

Engineering & Development

Investigate production incidents and perform root-cause analysis

Review pull requests (assess risk levels and escalate only when needed)

Write and contribute code at scale (nearly 3× output per engineer)

Automate long-stalled migrations (e.g., CSS system, product localization)

Maintain and fix flaky tests

Debug complex/hard-to-solve bugs

Continuously improve the product itself (analyze user feedback → propose improvements → validate via benchmarks and A/B tests)

Operations & Infrastructure

Triage alerts and production incidents

Run automated penetration testing / security vulnerability discovery

Run automated IT asset inventory

Orchestrate swarms of agents for parallel, verifiable tasks ("loop engineering")

Knowledge & Internal Support

Answer employee questions by combining knowledge bases + live codebase state

Enable non-engineers to fix copy, documentation, or product details without waiting on engineering

Data & Business Intelligence

Answer business intelligence questions via a semantic layer over the data warehouse

Generate charts and presentations from live data

Perform complex launch analysis (joining events, customer data platform, and subscription states)

Author quarterly progress reports and investor letters against OKR's and KPI's

Sales

Find and enrich product-qualified leads using internal knowledge

Author and execute outbound sequences

Prepare for customer conversations (value received, active projects, credit usage vs. contract)

Auto-generate branded, account-specific slide decks

Marketing

Draft product specs from scratch using conversations and documents across engineering/product

Align ICPs and personas to real time feedback from prospect and customer conversations

Align messaging house to positioning architecture and customer journey

Monitor and remediate gaps in AEO, SEO, and GEO

Author and maintain the full content pipeline (blogs, tutorials, how-to guides, explanations, references)

Support / Customer Success

Investigate support tickets and follow standard playbooks

Draft responses in the company's standard voice or escalate to engineering with a summary

Close hard (human-escalated) tickets significantly faster

Meta / Organizational

Replace or outperform expensive external SaaS tools with superior internal agent-built alternatives

Spread agent usage organically across every function via simple interfaces (e.g., Slack)

The Real Challenge Isn't Technical

Because we've built solid internal, agent-driven tools, we are now routinely replacing expensive external SaaS platforms. And through simple interfaces like Slack, agent usage has spread organically across every single function.

None of this is complicated to do.

The technology is ready. The barrier to entry is entirely organizational. To achieve a transformation of this speed and magnitude, you absolutely must have three things:

Unwavering executive sponsorship.

Director-level ownership to drive the integration.

Dedicated, continuous maintenance of your systems and context.

The agentic enterprise isn't a future roadmap item. It's already here. If you aren't building the infrastructure for it yet, let's talk.

Last year, a 232-foot steel booster fell out of the sky and was caught by a pair of mechanical chopsticks. Catching a booster is a hard problem — but it's one problem, solved once, in a controlled environment, by an organization that could spend whatever it took.

Commercial robotics is the opposite problem: modest tasks, performed millions of times, in environments nobody controls, at a price somebody will actually pay. While there is a list of unsolved hard problems in robotics right now, it seems like the toughest problem is one of economics.

I spent today at MACHINA Summit in Paris listening to foundation model researchers, humanoid manufacturers, field robotics operators. What follows is my attempt to synthesize where the business of robotics actually stands, written for the software people who I suspect will be moving into this industry over the next decade — voluntarily or otherwise, as AI compresses the value of pure software work.

Robotics runs on two clocks

The bit clock governs everything made of information: models, simulation, learned behaviors. It runs at AI speed, and it's genuinely astonishing right now. The Rhoda AI team described post-training a robot foundation model with just 10–20 hours of real robot data on top of internet-scale video pretraining — and beating approaches that used far more robot-specific data. Behaviors that took years to hand-engineer now emerge in months.

The atom clock governs everything else: supply chains, certification, capital equipment, trust. It runs at industrial speed, and no amount of model capability accelerates it. You cannot prompt-engineer a harmonic drive into existence. You cannot A/B test your way past a safety certification.

Nearly every confusion about robotics — every overhyped demo, every mispriced deal, every failed pilot — comes from applying one clock's logic to the other clock's domain. Let me show you where.

Is this a hardware company, a software company, or both?

The humanoid companies are building their own actuators, their own supply chains. Software people might find this baffling. Why build commodity components when you could focus on the differentiating layer and just print money like every other pure software business?

Because nobody knows yet which layer will be the differentiating one.

The PC industry offers the famous cautionary tale: IBM outsourced the processor and the OS, keeping the "hard part" — the machine. Within a decade, the profits had migrated to Intel and Microsoft, and the machine was a commodity. The intuitive prediction for robotics: same story. Hardware commoditizes, profits pool in the foundation-model layer, owning both the hardware and the software is a trap.

The problem: that story only worked because every PC was basically the same. Intel could write one chip and it ran everything. A warehouse robot, a surgical robot, and a welding robot are not the same — they have different bodies, different motors, different physical limits. Software written for one can't just drop into another. Additionally, if hardware stays complicated and supply chains stay concentrated, the money may stay close to the hardware, not migrate to software.

When a robot company builds its own actuators, it isn't being naive about focus. It's refusing to pre-decide which layer wins. That's expensive optionality, but in a market where the profit pools haven't settled, optionality might be the only rational position.

Quality control: you can't git-revert a gearbox

Software ate the world on the strength of one economic miracle: the cost of shipping a fix is near zero. Bad deploy? Roll it back. The entire modern software methodology — CI/CD, move fast, iterate in production — is downstream of cheap reversibility.

Robotics has no rollback. AGIBOT described the brutal math of scale: a flaw invisible at 10 units becomes a statistical certainty at 10,000. And when it surfaces, you're not pushing a patch — you're dispatching technicians, recalling hardware, eating the cost of physical remediation across a fleet. The atom clock, presenting its bill.

It is worth mentioning that some classes of defect can be converted from hardware to software defects by training resilience into neural policies rather than in precision-machined tolerances. Skild AI (Fetch Robotics) made the case directly: a learned controller can adapt when a motor degrades, turning what used to be a service call into a non-event.

This is why architecture choices in robotics are secretly business-model choices. A company betting on end-to-end learned control is betting that most failures can be moved onto the fast clock. A company betting on modular, engineered systems is betting on auditability and certification.

And don't assume the learned approach wins by default. Safety regulators — who gate access to factories, hospitals, and public space — have historically favored systems whose behavior can be verified, not just observed. The fastest clock doesn't matter if the certification body runs on the slow one. This tension is unresolved, and whoever resolves it captures an enormous amount of value.

Systems integrators: scaffolding or distribution channel?

In enterprise software, systems integrators are a whole industry. Robotics doesn't have that yet. Not because the integration work isn't real — it's extremely real, every deployment requires significant site-specific adaptation — but because there aren't enough deployments to sustain a standalone integration business. The market is too thin and too early for a third party to build a practice around it.

So the robot companies are doing it themselves. They're showing up, configuring the system, training the staff, debugging the edge cases, and rebuilding the workflow around the machine. Boston Dynamics built integration, repair, and customer success teams in-house — in that order — because they had no choice. The infrastructure to support their products didn't exist, so they became it.

This is a hidden cost that gets underestimated in robotics business models. Integration isn't a one-time deployment fee — it's ongoing, it's labor-intensive, and it doesn't scale the way software does. Every new customer is a custom engagement. The margin profile looks more like a services business than a software business, at least for now.

Use cases: discovery is capital-rationed, and pricing is R&D strategy

Here is a sentence from the summit that deserves a plaque: "POCs become monuments." Pilots that impress everyone, get a press release, and never scale.

Software solved use-case discovery by making experimentation free — millions of users tried things, and the killer apps were found, not designed. Nobody at Xerox PARC predicted the spreadsheet. Robotics can't run this playbook, because every experiment costs real capital. A robot doing the wrong job isn't a failed A/B test; it's a depreciating asset and a burned customer.

This is the correct lens on Robots-as-a-Service. The charitable read: RaaS lowers the customer's cost of experimentation, buying the vendor more discovery cycles per dollar — a learning-rate intervention. The uncharitable read: it's desperation pricing that moves hardware risk onto the balance sheet of the party least able to bear it. WeWork also "bought learning rate." Notably, one humanoid company said onstage they're already rethinking the RaaS model. When the practitioners are ambivalent, you should be too.

What actually seems to work, per the operators in the room: embed with the customer until you find the use case they couldn't have specified and you couldn't have imagined. FieldAI described deployments of eleven heterogeneous robots operating with no prior maps — and the valuable use cases emerging only after the robots were on site. Discovery happens in deployment. Which means deployment economics are your R&D budget.

The money: robotics is being asked to run a marathon on sprint financing

As illustrated by Zenith Shipping Company Limited, demand side is not the problem, and the numbers are absurd: roughly two trillion hours of industrial labor performed annually — capture 1% at $50/hour and you're staring at a trillion-dollar market. A 2,800-ship maritime backlog. Welding backlogs measured in football fields. Demographic curves that guarantee the labor to do this work will not exist. Only ~6% of North American factories run robotics at scale.

The problem is translation. Venture capital is a machine calibrated by software: small checks, fast feedback, ARR as the universal legibility layer. Robotics returns arrive on the atom clock — 7 to 15 years — and the industry lacks its measurement layer. There is no agreed-upon metric that tells an investor whether a robotics company is compounding or dying. Until someone builds the ARR-equivalent for machines (utilization? autonomy hours? intervention rate per task-hour?), capital will systematically misprice the sector in both directions — froth for demos, famine for infrastructure.

You'll sometimes hear a proposed fix: split the software and hardware into separate business units with different capital — venture money on the fast clock, infrastructure money on the slow one. It's elegant on a whiteboard. I'd treat it as speculative: no one has actually run this structure at scale, and splitting the stack recreates exactly the coordination tax that the verticalized players are paying to avoid. The capital-structure innovation robotics needs probably hasn't been invented yet. That's not a throwaway line — for the finance-minded readers, it's an open opportunity.

The trillion-dollar open question: does fleet data compound, or commoditize?

Everything above has a reasonably confident answer. This one doesn't, and it's the single most important uncertainty in the industry.

The bull case for incumbents: deployed robots generate training data, data improves models, better models win deployments. One company reported collecting more data in two recent months than in their prior three years. If this flywheel is real, deployment is training, the analogy to software breaks entirely, and there may be no late winners — the companies embedding with customers now are compounding an unassailable lead.

The bear case, hiding in that same 10-20-hour result from earlier: if internet-scale video pretraining does the heavy lifting and robot data is just a thin adaptation layer, then fleet data is a garnish, not a moat. A late entrant with a better model leapfrogs a decade of incumbent data collection. We have already watched this movie once: Tesla spent ten years accumulating the largest driving dataset on Earth, and Waymo — tiny fleet, different architecture — leads where it matters.

Every strategic decision in robotics — verticalize or not, RaaS or not, deploy now or wait — is secretly a bet on which of these is true. Nobody knows. The people who tell you they know are selling something.

Machina 2026: That's a wrap

The stat to remember when the next rocket-catch clip goes viral: catching one booster with an unlimited budget and catching margin across ten thousand robots in ten thousand uncontrolled environments are different sports. One is a triumph of the atom clock, brilliantly funded. The other requires both clocks to strike at once, and nobody is currently positioned for both.

The engineers who move into this industry — and I think many reading this will — won't be the ones who assume software's lessons transfer. They'll be the ones who know which lessons transfer, which invert, and which questions remain genuinely open.

Demos live on the bit clock. Businesses are built on both.

A lot of robotics founders are brilliant at engineering and about to learn about money the hard way.

In my last post I argued that robotics runs on two clocks - the fast clock of software and the slow clock of physical things - and that venture capital, built entirely around the fast clock, keeps mispricing the industry. Several people asked the obvious follow-up: fine, so what do we do about it?

This is my attempt at an answer. It's written for founders who have never had to think about what money costs. That's not an insult. Nobody taught you this, because in software you never needed it. In robotics, how you fund the company is not the finance person's problem. It's a design constraint, like battery life. And parts of the answer are genuinely unsolved - I'll be honest about which parts.

One warning before we start: you will not build most of what's in this post for years. If you're pre-product, your only job is making the robot work. But three or four decisions you'll make in the next 18 months - how you write contracts, what you instrument, what you build in-house - quietly determine whether the cheap money ever becomes available to you. This post is about not locking those doors while you're not looking.

Lesson One: Money Has a Price Tag

Every dollar you raise comes with an expectation attached. A bank lending against something safe and predictable might expect 8% back per year. Big pension-style funds that finance bridges and power plants might want 10–15%. Venture capital, because most startups fail and the winners must pay for the losers, needs its successes to grow 30%+ per year. VC is the most expensive money on earth, and it should be: it's the only money willing to bet on unproven technology.

A robotics startup raises venture money and spends it building a fleet of robots that sit at customer sites earning monthly fees. But a deployed robot earning fees is not a moonshot - it's closer to a delivery truck. It's a machine with a maintenance schedule and a fairly predictable income.

Airlines figured this out generations ago. Airlines mostly don't own their planes. Separate leasing companies own the planes and rent them to airlines, and those companies borrow cheaply from banks, because a plane's rental income is steady enough that a bank can lend against it comfortably. Nobody funds airplanes with startup equity, because that would mean paying moonshot prices for truck-level risk.

Most robotics startups today are funding their airplanes with startup equity. Then they wonder why every fundraise hurts so much.

Lesson Two: Your Company Is Secretly Four Companies

Look at what your investors are actually betting on. In a robotics startup, it's four completely different bets stapled together:

Will the autonomy work? High risk, huge upside. This is what venture money is for.

Can you manufacture 10,000 units well? Hard, but a known kind of hard. Industrial companies solve this routinely.

Who owns the deployed robots? Machines earning predictable fees — truck territory, not moonshot territory.

Who installs and supports them? Steady, people-heavy service work.

When all four live in one company funded by one kind of money, investors have to price the whole package at the risk level of its scariest piece. Your steady service revenue gets treated like a moonshot. Your robot fleet gets funded like an experiment. You overpay for everything.

The fix isn't finding braver investors. The fix is separating the pieces so each one can be funded by money that matches its actual risk. And there's a historical pattern for how that happens — though I'll flag where robotics might break it.

Lesson Three: The Pattern That Has Repeated for 150 Years

Railroads were too expensive for investors' stock purchases alone; the modern bond market (lending at scale against future income) largely grew up to finance them. Aircraft became a leasing industry. Solar panels looked impossible to finance until insurers started guaranteeing their power output; once a bank could trust the income from a panel, it would lend against it, and the cost of building solar collapsed. Most recently, AI cloud companies borrowed billions against their GPUs, not because banks love GPUs, but because those GPUs came with signed customer contracts that made the income predictable.

The pattern, every time: an industry gets access to cheap money when its future income becomes predictable enough for a lender to trust. Not when investors get braver. When the risk gets legible.

Robotics hasn't done that work yet. Nobody can look at a robotics company and quickly tell whether it's compounding or dying. Demo videos are the current standard of evidence, which is exactly why demos get funded and everything else starves.

What Would Make Robot Income Trustworthy?

Software went through this. SaaS wasn't always fundable either - what changed was that "annual recurring revenue" became a standard, comparable number every investor understood. A whole lending ecosystem grew around that one convention.

What's robotics' version? Who knows, really. But here are the likely contenders:

A performance metric: something like reliable task-hours (hours of autonomous work, discounted by how often a human had to intervene, valued at the labor cost it replaces). Measurable straight from the robot's own logs.

Standardized contracts: Solar's real breakthrough arguably wasn't telemetry - it was a standard contract (the power purchase agreement) that let a bank read any solar deal in five minutes. And an hour of robot welding isn't really comparable to an hour of robot tote-picking anyway, while dollars are comparable to dollars. If I had to bet, robotics converges on plain old contracted recurring revenue, made trustworthy by standard contract terms - and the exotic metrics remain a footnote.

Either way, the practical advice is identical: instrument everything, report your reliability numbers to investors before anyone asks, and make your customer contracts as standard and readable as possible. You want to be the company a future lender can evaluate in an afternoon.

How to Eat an Elephant

Four kinds of risk, three companies - and you don't build them all at once. One bite at a time.

The technology company (venture-funded): owns the models, the IP, the customer relationships. High risk, high reward - correctly funded by expensive money. Early on this includes installation and support, not for financial reasons, but because every deployment and every failure is training data for your models. You can spin that part out into a separate company or partner ecosystem when you get to real scale.

Manufacturing (a separate entity): This is the playbook consumer electronics settled on decades ago: Apple designs iPhones but Foxconn builds them. And even if you decide to build your own hardware, treat manufacturing as its own company: separate books, separate management, and eventually separate walls - because a factory attracts different money, different risks, and different lawsuits than model development does. Paying venture prices for a solved industrial problem is the expensive way to learn this. (For parts unique to you, a wholly owned subsidiary may suffice for gen 1–2.)

The fleet company (a separate entity): owns the physical robots and rents them out, funded by cheaper loans against that steady rental income.

This is what would make robots-as-a-service genuinely work. RaaS today often looks like desperation pricing because startups are buying the robots with 30%-expectation money and renting them out at margins that can't support it. Put the fleet in a separate vehicle funded at 8%, and the same subscription suddenly makes sense.

Now the crack - and it's a big one: Fleet financing only works if robots hold their value. Planes stay useful for 25 years. Solar panels, 30. That longevity is why banks lend against them cheaply. But if robot capability keeps improving at AI speed (the whole premise of my last post) a 2026 robot may be functionally obsolete by 2029, like an old GPU. Machines that die in three years don't get cheap loans.

The two clocks cut against each other here: the faster the software improves, the worse the hardware-financing math gets. One possible way out: if capability lives mostly in the software, an older robot body might stay useful through updates alone - the way a Tesla improves overnight while sitting in the garage. Whether robot hardware ages like a plane or like a phone is, I think, one of the most important unanswered questions in the industry, and almost nobody is talking about it. Watch it closely. It determines whether this entire financing structure works.

Two more honest caveats. Insurance, the thing that made solar bankable, will be slower to arrive for robots than the analogy suggests. Solar panels fail independently, one at a time, which insurers can price with statistics. Robots running the same software fail together: one bad update can degrade an entire fleet in an hour. Insurers hate that pattern (they still struggle with it in cyber insurance). And don't expect government rescue: the loan program that funded Tesla's first factory was sellable as green jobs, but loans for automation read politically as subsidizing job displacement. If public money comes, it comes through defense, not a general program.

Who Funds the First Fleets, Then?

If banks need track records and insurers need failure data, someone has to go first. The candidates, with eyes open:

Your most desperate customers' industries: Shipbuilders with decade-long backlogs and manufacturers who can't hire welders at any price have survival-level reasons to help finance the fleets that serve them. But be careful: big corporate partners often demand exclusivity or control that quietly strangles a startup. Take their money for the fleet - the machines serving them - and guard the technology company jealously.

Infrastructure investors: the funds that finance ports and power plants. They have patient, decade-scale money and a growing automation thesis. They won't move until the trustworthiness problem above is solved, which is why that work comes first.

And time. Some of this simply cannot be rushed. Which brings me to the most honest caveat of all.

So When Does Any of This Apply to You?

This whole post assumes the robots work - that the main thing standing between robotics and cheap money is paperwork. If your intervention rates are still high, no financing structure saves you; there's nothing predictable to lend against yet. Clever structure around unreliable machines is just expensive theater.

So the real advice is sequenced. Before reliability: spend venture money on exactly one thing - making the autonomy work - and keep your structure boring. Don't create separate fleet entities for ten robots; at that stage, complexity scares investors more than it helps you. But start the habit that costs nothing: log everything. The intervention data you record this year is the credit history you'll borrow against in five. As reliability arrives: instrument everything, standardize your contracts, price against the labor cost you replace, and report reliability numbers nobody asked for. At scale: that's when the fleet separates from the technology company, and when the discipline pays off, because you'll have years of trustworthy history while your competitors have demo reels.

The Summary

Software founders got to ignore all of this because software barely needed capital. You don't get that luxury. In robotics, the balance sheet is part of the product.

Match every dollar to the risk it's actually buying. Moonshot money for the models. Truck money for the fleet - once the fleet deserves it. And keep one eye on the question that decides everything: does a robot age like an airplane, or like a phone?

The founders who can answer that honestly will outlast better-funded competitors who paid moonshot prices for everything.

Early in my career, I was frustrated. Maybe not constantly, but certainly frequently.

We were a software company. We had engineers. We had customers. Why weren't we moving faster? Why was leadership so allergic to risk? Why did every bold idea die in committee?

It took years to understand: I wasn't failing to read the room. I was failing to read the business model.

The Model Tells You the Rules

Not all software companies are the same. The code might look identical. The org charts might be similar. But the underlying business model dictates what "good decisions" actually means — and if you don't know which game you're in, you'll optimize for the wrong thing.

Here's a simple way to think about it:

Growth companies live and die by market capture. Risk is fuel. Moving fast and being wrong is acceptable — even expected. The model rewards bold bets because there's a massive upside if you're right and a fundable story if you're wrong.

Value companies (on-prem software, established SaaS, enterprise licenses) are optimized for margin protection and retention. Every customer you have is expensive to replace. Churn is existential. The model punishes risk because the downside is asymmetric.

All companies use growth language regardless of what they actually are. Find the most recent earnings call transcript. Ctrl+F for "growth" vs. "margin" vs. "efficiency." Count the ratio. Then read the analyst questions - sell-side analysts are paid to know exactly what kind of company they're covering, and their questions will tell you immediately what the market is holding your management accountable for.

Infrastructure and Regulated Players Play a Different Game

Infrastructure and ecosystem players (think Dell, distribution companies, platform integrators) have a different constraint entirely: reliability as the product. Their customers are buying dependability, not innovation. A Dell employee who pushes for wild product bets is misreading their entire value proposition. Their job is to be the stable backbone of an ecosystem that thousands of other companies depend on. Disruption is catastrophic. For innovation, they partner with companies whose model affords taking risks.

Regulated-industry companies (healthcare, fintech, defense, federal contractors) must accept compliance as the floor, not the ceiling. Risk is legally and reputationally catastrophic. A fast-moving bet that breaks a HIPAA boundary, trips an SOC 2 audit, or violates a FedRAMP requirement can end the business, trigger personal liability for executives, or harm the people the product serves. The "why are we moving so slow" frustration in these environments often comes from engineers who don't yet see that the legal and compliance surface area is the product. Customers in regulated industries are buying your ability to operate inside their risk framework without blowing a hole in it, not flashy innovative new features.

Before You Push, Ask

Before you push for a strategy, a roadmap, a hire, or a risk - ask yourself:

What does my company get paid for, really? Margin? Growth? Reliability? Compliance coverage?
What happens if this bet fails? Is it a learning, a write-off, or a company-ending event?
Who depends on us being boring? If the answer is "lots of people," bold is not your friend.
Who gets hurt if we're wrong? If the answer includes patients, financial accounts, or national security infrastructure - that's not a constraint to work around. Reliability is your entire business.

Find The Money, Pick It Up

The company I was frustrated with wasn't broken. It was rational. It was protecting margins in a low-growth market with sticky enterprise customers who paid predictable license fees. Any disruption to that - new pricing models, riskier product bets, faster release cycles - could erode the very thing customers were paying for: stability and trust.

I was trying to play growth-company chess on a value-company board.

Once I understood that, I stopped being frustrated. I started asking better questions: not "why won't we take this risk?" but "what risk profile does this business model actually support?"

That reframe made me a better engineer, a better leader, and eventually, a better strategist.

The takeaway: Your business model is the operating system. Everything else - culture, strategy, appetite for risk - is an application running on top of it. Learn the OS first.

In Part 1 of this series, I wrote about reading your business model archetype to understand what "good decisions" actually look like where you work.

But there's a second diagnostic that's just as important: Who really owns this company? And what do they need from it?

Ownership structure doesn't just set the financial rules. It sets the incentive structure for every leader above you. And if you don't understand what your owners are optimizing for, you'll spend years interpreting rational decisions as irrational ones.

The Same Company. Completely Different Rules.

Imagine two software companies. Similar size. Similar product. Similar engineering team.

One is VC-backed in year three. The other was acquired by private equity two years ago.

At the VC-backed company, the CEO says yes to a risky product bet that might 10x the addressable market — or fail entirely. At the PE-backed company, the CEO kills that same bet in the first five minutes.

Neither CEO is wrong. They're just playing different games.

The VC investor needs outlier outcomes. The fund model only works if some of the bets in their investment portfolio return 50x, so swinging big is the entire point, even knowing most swings miss. Saying no to bold bets is actually the failure mode.

The PE investor bought a cash-flowing business and needs to protect and expand EBITDA over a 3-5 year hold before selling. Every dollar of unnecessary risk is a dollar threatening the exit multiple. The CEO who chases moonshots at a PE-backed company is destroying the thing that was purchased.

Same industry. Same role. Opposite playbooks.

Where Am I?

Here's how to read the room based on who's holding the equity:

Publicly traded value stock: Earnings stability and margin defense are everything. The stock trades on predictability. Surprises, even good ones, can spook the market. Leadership is often (rightfully) more focused on not losing than on winning big.

Publicly traded growth stock: Revenue growth rate and TAM narrative dominate. Risk is acceptable if it supports the story investors are paying a premium multiple for. But the clock is always ticking - growth stocks that stop growing get re-rated brutally and fast.

Even publicly traded companies are still majority-owned by someone. Pull the most recent 13F filings and proxy statement. Look at who holds more than 5% (required disclosure), whether any of those holders have board seats (tells you if they're passive or active), what the CEO's comp structure rewards - and who designed it. Comp committees are controlled by the board. The board composition reflects who has real power. Follow that chain and you'll likely discover whose thesis your company is actually executing.

Private Capital Reads

VC-backed early stage: Existential risk tolerance. The entire thesis is that this company might be a category-defining outlier. Incremental wins are almost irrelevant. Swing hard or go home.

VC-backed late stage / growth equity: The moonshot phase is over. Now it's about cleaning up the metrics for an IPO or acquisition. You'll start seeing enterprise sales motions, compliance investments, and process formalization that felt foreign two years earlier. Get a feel for the various popular exit strategies and how to execute them.

PE-backed. EBITDA is king. Expect cost rationalization, margin expansion focus, and M&A used as a growth lever instead of organic product investment. Technical debt will get deferred because it doesn't show up in the metrics that drive the exit multiple. This is not a problem you're going to be rewarded for solving.

If you don't know who funded your company, check crunchbase.com - It will tell you who invested, when they invested, and maybe even how much they invested. Look at who else they've invested in. Read the discourse of their partners and LPs - the theses they publish, the deals they celebrate, and the language they use to describe wins will tell you exactly what a successful outcome looks like to the people who actually own your company.

Founder-owned / bootstrapped. Entirely dependent on the founder's personal psychology and risk tolerance. Can be the most innovative environment you've ever worked in, or the most stagnant. There's no external pressure to change and no external pressure to grow. Founder-owned means founder's rodeo - and you don't get to pick which bull.

Strategic subsidiary / acquired. You're now optimizing for your parent company's agenda, which may have nothing to do with your product's best interests. You might be a defensive acquisition (kill the threat), a talent acquisition (absorb the team), or a portfolio play (cross-sell into existing customers). Each implies a radically different mandate for your team. FAFO.

Ask Better Questions

When a leadership decision doesn't make sense to you, stop asking "why won't they take this risk?" and start asking:

What does a win look like for the people who own this company, and by when?

The answer to that question will explain almost everything: why the roadmap looks the way it does, why certain hires get approved and others don't, why "strategy" seems to shift every 18 months, why the thing that obviously needs investment keeps getting deprioritized.

It's (usually) not dysfunction, just math.

That Kimono Ain't Gonna Open Itself

I spent years frustrated by decisions that seemed to optimize for the wrong things. What I eventually understood is that I was the one misreading the objective function.

The leaders above me weren't morons. (Shocking!) They were executing precisely against what their owners needed, while telling the growth story they get paid to tell. I just hadn't done the work to understand what the real objective was.

Once you understand the capital structure, you can do one of three things: align your work to it, influence it from the inside, or decide it's not the environment where you'll do your best work.

All three are legitimate. Be smart. Have fun!

A few weeks ago, I wrote about cognitive light cones and why great engineering managers operate as filters, not conduits. A few folks asked, "Does this filter run the other direction?"

It absolutely does, and understanding how it applies is crucial to your longevity and effectiveness as a leader.

The Filter Has Two Edges

When you're filtering for your team, you're managing inflow. You decide what goals land in their awareness based on whether they have the action range to do anything about it. If a goal is too big for their position, you absorb it, carry it, and translate it into something that fits their actual leverage.

But as you move up from lead to director, director to VP, and into the rooms where the biggest decisions live... a different filtering problem emerges.

It's no longer just about what you know. It's about what you're named responsible for.

The higher you climb in a large organization, the more critical it becomes to understand a foundational rule of organizational physics: Authority is a wonderful tool to drive impact, but direct responsibility must be managed with care.

This isn't about being cynical or dodging responsibility. It's about learning how large companies are actually engineered so you can navigate them safely, sustainably, and successfully.

Pay Attention

Large corporations are engineered, deliberately, to diffuse individual liability downward while concentrating high-level decision-making authority upward.

Boards set direction, but they don't execute. Corporate officers hold deep fiduciary duties, but those duties are bounded by the Business Judgment Rule—a legal doctrine that beautifully protects executives from personal liability for good-faith decisions, even when things go wrong. General counsels spend entire careers constructing and maintaining this structural separation.

The further you are from daily implementation, the more the organization protects you as an individual. That distance isn't a side effect of seniority—it's a conscious design feature.

When a data breach happens, the CISO gets deposed. When a product harms a consumer, the VP of Engineering gets subpoenaed. The CEO gives a deposition; the board issues a statement. But financial exposure naturally flows to the entity, not the individual.

This might lead you to believe that leaders are safe from the consequences the business might face in the event that something goes wrong. However, "piercing the corporate veil" is a legal decision where courts set aside a corporation's protection, allowing plaintiffs or creditors to hold directors personally liable for the corporation's debts, acts, or legal obligations. Courts grant veil-piercing in roughly 27–40% of litigated US/EU cases nationally, and over 50% in China. Most veil-piercing protection is lost not through malice, but through sloppiness.

Strategic Compensation

You can see this exact same filtering dynamic in executive compensation architecture: heavy equity, deferred comp, indemnification clauses, and D&O (Directors and Officers) insurance.

These aren't just fancy perks. They are the organization explicitly pricing in the risks of seniority and engineering structures to limit personal downside while preserving strategic control. The organization is actually filtering for its senior leaders, whether those leaders realize it or not.

Think about how your ownership shifts at each stage:

IC level: You own outputs.
Director level: You own budgets.
VP level: You own P&L.
C-suite level: You own narrative.

Each transition naturally widens the gap between what you control and what you're personally responsible for. To ascend smoothly, you need to manage that gap deliberately instead of stumbling into it.

Authority AND Responsibility? Just Say No

Most dedicated, capable mid-level leaders plateau not because they lack competence, but because they never stop collecting tasks to prove their worth.

Early on, taking absolute, clear ownership is exactly the right move! From IC to director, you earn trust by being the person who raises their hand and says, "I've got this. Hold me responsible." You demonstrate that you can carry the goal, the timeline, and the outcome.

But somewhere around the transition to VP or SVP, the rules of the game change.

The leaders who stall are often the ones who became too valuable operationally—the single throat to choke, indispensable in execution, but permanently capped in their strategic trajectory. They kept absorbing accountability the way a conduit manager keeps forwarding bad news: reflexively, in the name of ownership, without asking whether that goal is the right size for where they're standing now.

The leaders who move up successfully start filtering their own exposure with the same care they give their teams:

They build bench strength: They delegate true ownership, not just tasks. They empower someone else to be directly responsible—not to dodge work, but to grow their people and create appropriate structural distance.

They operate through governance: They guide outcomes using frameworks, steering committees, and approved recommendations rather than trying to micromanage production deliverables.

They hold veto power without holding delivery timelines: They maintain high influence over the final outcome, without tying their personal name to a rigid deadline.

They recognize what they sign: They understand that at senior levels, an email authorization or an org-chart sign-off carries real legal weight. They communicate through healthy organizational structures, not paper trails.

Plan For The Unforeseen Deposition

When we protect our teams, the underlying principle is simple: the goals people carry should match the action range they actually have. Mismatching that—giving them all the visibility but none of the power—creates the painful feeling of being a witness to a fire you aren't allowed to put out.

The inversion is just as true for you.

Taking on massive, named responsibility without the corresponding structural protection or executive authority isn't just stressful—it risks your professional well-being. It is the executive equivalent of a founder handing a complex runway model to an IC engineer and asking her to carry the weight of it.

She can hold it in her mind. She just shouldn't have to carry it on her shoulders.

The cognitive light cone isn't just a tool for protecting your engineers from goals that are the wrong size for their position. It's the map of your own career.

As you grow, your authority should expand so you can do more good for your organization. But your responsibility and exposure—what bears your name, what you've signed, and what attaches to you personally—should be managed with the exact same intentionality you bring to filtering for your team.

The leaders who thrive build both deliberately, in parallel. Learning this balance doesn't make you less of a leader; it makes you a sustainable, resilient, and highly effective one. You owe it to yourself—and to the teams you protect—to look after your own career path with that same level of care.

57 Days Ago, I Had No Idea What I Was Doing.

I'm currently a product manager. Not an engineer. Not a marketer. Not a content strategist or a data analyst or a sales ops person. I'm one person at a 10-person startup trying to figure out how to go-to-market from scratch.

So I just started.

The On-Ramp: The Foundation You Can't Skip

Before day one, there were a few hours where I set up the foundation. I want to be honest about this because I've watched too many people try to skip it — and I've watched them end up frustrated, stuck, or building in the wrong direction entirely.

Here's what actually needs to exist before any of this works:

Claude CLI: Not the browser chat. The command-line tool that runs inside your terminal, beside your actual files, with your actual work. This is the thing that lets Claude not just answer questions but do things — read files, write files, version control, run automations. If you're talking to Claude in a browser window and copy-pasting results into Notion, you're not building a system. You're doing more work.

GitHub and the gh CLI: Everything lives in a GitHub repository. Not in Obsidian. Not in Notion. Not in a folder on your desktop. A git repo. This sounds scary if you've never used one, but here's all you need to know: it's a folder where everything has a history, everything is searchable, and both you and Claude can read it, write to it, and automate against it. Obsidian is great for notes. It's the wrong foundation for a team system that does things.

Structured Claude.md's plus a few hooks and rules: Small configuration files that tell Claude how to behave in your specific context. What to always do. What to never do. Where things live. How to format output. This is what makes Claude feel like your assistant rather than a generic one — and it's what makes the system get smarter over time instead of starting from scratch every session.

That's it. Three things. It takes two hours max if you're on a clean machine.

I know it sounds like setup cost. It is. But it's the only setup cost there is — after this, everything compounds.

A quick note: For anyone who's heard me say "just call me if you need help getting started" — I mean it. I've gotten dozens of people through this on-ramp in the last few months and every single one of them was off and running within two hours. The first session is the hardest. After that, you'll wonder what took you so long.

Days 1 & 2: The Power of the First Question

Day 1: I asked Claude to research our competitors.

That's it. Nothing fancy. I had a doc, Claude had the internet, and we filled it in together — who they were, what they offered, how they positioned themselves, what they charged.

One thing jumped out immediately: a capability gap. Something our product did that none of theirs did. That single finding — confirmed in about two hours on the first day — became the foundation of everything. Every piece of content. Every sales pitch. Every product decision. I didn't plan for that. I just started, and the problem revealed itself.

Day 2: I had a new problem.

Now that I knew what we had, I needed to make sure we could find out when that changed. What if a competitor closed that gap next month? I'd want to know immediately.

So Claude and I built a small automation. Every month, it checks competitor websites, reads their docs, and flags anything new. It opens a pull request with what changed. I review it. Done. That took maybe three hours.

Then I thought: what else changes in our market that I should be tracking? So we built another automation to monitor that too — pulling from sources I'd never have time to check manually, surfacing only what was relevant.

I didn't know I needed either of those things when I woke up that morning. The day before's work revealed them.

How It Actually Goes (The Compound Effect)

You don't start with a plan for an 18-workflow automated system. You start with one question. The answer to that question reveals the next question. And slowly, almost without noticing, you've built something real.

By Day 5: We had automated competitor monitoring, a content gap tracker, a market intelligence feed, and a CRM integration that turned sales call recordings into engineering tickets.

By Day 14: We had a brand system, a pitch deck framework, a 12-cohort customer research map, and account dossiers for our most important customer relationships.

By Day 41: We had a weekly intelligence digest that landed in Slack every Friday — competitive signals, regulatory news, market updates, conference opportunities — synthesized from eight different data sources, automatically.

By Day 57: We had 18 scheduled automations, a full outbound sales sequence for every customer segment, a blog content pipeline, and an automated image generator.

I did not know on day one that any of that was possible. I just knew what question I needed to answer that day.

What This Is (And Isn't)

What this is NOT:

A story about being technical: I did not write the code. I did not set up a server. The automations are workflows — Claude wrote them. I described what I wanted in plain English and we figured it out together.

A story about having a strategy: I didn't have a strategy on day one. I had a competitor doc and a question.

A story about scale: We're 10 people. My Claude Teams plan and I are the entire GTM function. There is no agency, no budget for a full marketing stack, no RevOps team.

What it IS a story about:

It's about the fact that the gap between "I have no idea what I'm doing" and "I have a system that compounds" is smaller than you think — and the bridge is just starting.

If you're an engineer who's never thought about marketing: you already know how to break a problem into smaller pieces. That's the whole skill.

If you're a marketer who's never touched code: you don't need to touch code. You need to describe what you want. Claude handles the rest.

If you're early in your career and wondering how people build these things: they build them one day at a time, surprised by the next problem, and then solve that one too.

If you're later in your career and wondering if you have the chops for this new world: the new world rewards people who can identify problems and communicate clearly. You've been doing that for years.

The Real Secret: Don't Stop

The system I have now has taken 57 days to build.

Not 57 full days. 57 calendar days, where most of the time I was doing my actual job — running sprints, talking to customers, writing specs, sitting in meetings. The GTM system got built in the margins. An hour here, an afternoon there.

The thing that made it compound wasn't intelligence or experience or a plan.

It was just not stopping.

Every day I'd look at what we'd built the day before, notice one thing that was missing or broken, and fix it. Claude and I would solve it together. Then I'd stop and do my job. The next day, same thing.

By day 57, I looked back and couldn't believe what we'd built.

Your First Step

If you want to start, start with the on-ramp. Two hours. Claude CLI, a GitHub repo, a few configuration files. If you're not sure how, reach out — I'll walk you through it. I've done it enough times now that I can get anyone set up in a single call.

Then ask your first question. Not a big strategic question. Just: What's one thing I need to know right now?

See what the answer reveals. Come back tomorrow.

That's the whole playbook.

There's a fascinating business model emerging right now that doesn't quite have a clean name yet. For now, let's call it "Professional Services to Product."

The classic template here is Palantir. The playbook looks like this:

Go incredibly deep into a specific vertical.

Do the hard, hands-on implementation work that most software companies aren't ready to tackle themselves.

Let early customers help fund the discovery of what the final product actually needs to be.

Generalize those hard-earned learnings into scalable software.

While that journey took Palantir 17 years, AI is compressing that timeline down to just 3–5 years.

How to Spot This Model in the Wild

High-touch onboarding: The best customers can't quite use the product without the team's help yet (and that's a feature, not a bug!).

Services = R&D: The "services" or "implementation" team is functioning as the actual R&D engine.

Evolving margins: Gross margins might sit at 40-50% today, but every implementation makes the next one faster and more efficient.

Repetition before scale: The team is building the same custom solutions repeatedly until they understand the problem well enough to generalize it.

Relationship-driven retention: Retention is exceptionally high despite early product maturity because the team's dedicated support is doing the heavy lifting.

Hybrid roles: Job descriptions beautifully blend engineering with customer-facing work.

Consultative demos: The product demo feels a bit more like a consulting pitch than a standard software walkthrough.

Why Confusing This with Traditional SaaS Can Be Tricky

SaaS investors typically underwrite 70%+ gross margins, compounding net revenue retention, and hyper-efficient customer acquisition. But in year one of a "Services to Product" model, those metrics just aren't reality yet. If a deal is priced on SaaS multiples too early, the math gets tough the moment you hire your next implementation engineer.

The trap for founders: Raising traditional SaaS money and feeling pressured to skip the crucial deployment phase. It's tempting to hire product managers to build a generalized platform immediately, but jumping the gun rarely works out.

You can't abstract what you haven't learned yet. It takes time and deep, hands-on work to set a product team up for success.

The Takeaway

This is a highly fundable, scalable, and exciting model! It simply needs capital that understands and underwrites the trajectory—moving from 40% margins today to 75% in year four—rather than capital that expects you to already be at the finish line.

Eventually, this category will get its own dedicated investors. Until then: if your services team is your product team right now, you might be building something far more durable than a traditional consulting firm, and much more defensible than standard SaaS.

Definitely worth understanding before signing that term sheet!