You Don't Have to Quit Your Job to Start Building Something

The more I read about entrepreneurship, the more I notice something funny: most of the best innovations didn't start in a garage. They started inside a company, by someone who didn't quit their day job.

Post-it Notes came from a 3M engineer who couldn't get anyone to approve his idea for years. IBM's personal computer was built by a small renegade team that had to work around the company's own bureaucracy. The Ford Mustang? An intrapreneur named Lee Iacocca who pitched it from inside Ford.

The romantic story is "quit your job and follow your dream." The realistic story is: most people who build great things do it while still employed — using the resources, network, and salary that come with their position.

That's the thread I found running through four very different books I've been reading. One is about innovation inside large organizations. Another is about why human judgment still matters in the age of ChatGPT and Claude. A third maps the entire planetary-scale infrastructure of software as a new form of sovereignty. And the fourth teaches algorithms through drawings and intuition.

They don't seem related at first. But they converge on a question I keep thinking about: what does it actually take for a software engineer to start building something meaningful — without burning everything down first?

The intrapreneur advantage: why you might be better off staying

Gifford Pinchot III coined the word "intrapreneur" back in 1985, and the core idea is still sharp: an intrapreneur is someone who takes entrepreneurial risk inside a large organization, turning ideas into real products without leaving.

What struck me about his book Intrapreneuring is how clearly it explains why most innovators leave companies. It's not the money. Most entrepreneurs leave because they feel frustrated — blocked by bureaucracy, unable to act on ideas they know are good.

Most leave corporations not primarily because they find their pay and benefits insufficient but because they feel frustrated in their attempts to innovate. They need empowerment to act as much as they need material compensation.

That resonated with me. I've written before about how your compensation is more than just a number — but Pinchot takes it further. He says the real currency for innovators isn't money. It's freedom to act.

There's a stat from the book that stayed with me. When Texas Instruments studied around fifty of their new product introductions — both successes and failures — a startling pattern emerged: every single failed product lacked a zealous volunteer champion. Not a manager who was assigned to it. A person who genuinely cared.

That's the intrapreneur. Not the person with the best plan, but the person who refuses to let the idea die.

Innovation never follows the plan

Here's where Pinchot's argument gets really practical. Venture capitalists, whose entire business is betting on innovation, discovered something counterintuitive:

"I'd rather have a Class A entrepreneur with a Class B idea than a Class A idea with a Class B entrepreneur."

They bet on people, not plans. Because business plans become obsolete the moment they're written. The path of any real innovation looks nothing like the neat line from goal → plan → execution that we're taught in business school.

Scotch tape was invented to seal insulation in refrigerated railroad cars. Nobody bought it for that. Then they tried selling it to seal cellophane packages — that worked, until DuPont made heat-sealing possible and killed that market too. But by then, Depression-era families had started using it to fix everything — books, falling plaster, torn pages. The product found its real market through a series of failures.

The lesson isn't "don't plan." It's that the plan is just the starting point for a conversation with reality. And the person who survives that conversation is the intrapreneur — someone stubborn enough to keep iterating, with enough organizational support to try.

This connects directly to what I've been thinking about with product development. The best engineers aren't the ones who complete the most tasks. They're the ones who can own a meaningful chunk of work so well that other people stop worrying about it.

Think in algorithms: patterns for career decisions

Here's where Grokking Algorithms comes in — not for coding, but as a thinking tool.

Aditya Bhargava's book teaches algorithms through drawings and examples instead of math proofs. What I find valuable isn't just the technical knowledge — it's that algorithmic thinking gives you a framework for making better decisions about your career and your side projects.

Let me unpack a few of these.

Binary search: find your niche

Binary search works by cutting the search space in half with each step. Instead of checking every item one by one, you ask: "Is it in the top half or the bottom half?" And then you repeat.

Career decisions work the same way. Don't try to evaluate every possible path. Start with big filters: What do I actually care about? What can I realistically build with my current skills? Is there a real need? Can I explore this inside my current role? Each filter cuts the space in half. By the end, you're left with a focused bet.

Greedy algorithms: ship the MVP

A greedy algorithm makes the locally optimal choice at each step. It doesn't look ahead or plan globally — it just picks the best available option right now.

That's exactly how you should build an MVP. Don't try to design the perfect product. Pick the highest-value feature you can ship this week. Then the next one. Then the next.

Pinchot would agree. Innovation inside organizations works the same way — you don't get a 50-page business plan approved. You ship something small, prove it works, and earn the right to do more.

BFS: map your influence network

Breadth-first search explores a graph level by level. First your direct connections, then their connections, then their connections' connections.

This is exactly how you find sponsors inside a company. Pinchot talks about this extensively — every intrapreneur needs a sponsor, someone higher up who protects the idea from being killed by bureaucracy.

Start with your direct network. Who do they know? Who has budget authority? Who has a track record of supporting risky projects? You're doing BFS on your organization graph, looking for the shortest path to someone who can say "yes, go build that."

The machine's decision is not final

I first heard Bratton lecture in VIS 133 (Speculative Design) at UCSD, where he introduced Machine Decision Is Not Final through a scenario-planning exercise: pick two critical uncertainties about the future, plot them as axes, build out a world in one quadrant.

In class, the matrix was just a scaffold: two critical uncertainties crossing into four possible worlds, with one point in each quadrant standing in for a different scenario. The point of the exercise wasn't to predict the future correctly. It was to set a few different futures side by side, then ask what kind of person, product, or institution would thrive in each one. That's speculative design at its best: fiction used as a prototype for strategy.

Bratton framed this through what he called H.A.I. — Human Artificial Intelligence Interactions. The core idea is simple: people can use systems well long before they fully understand them. We drive cars without mastering combustion physics. We use AI without really knowing how transformers work. What we actually carry around are mental models — simplified, partly wrong stories about how a system behaves. Those imperfect models shape what we try, what we trust, and what we imagine the tool can do. Deep technical understanding and creative use are not the same thing. Someone can know GPT's architecture cold and still make boring things with it. Someone else can misunderstand half of it and still discover an unexpectedly powerful use.

That's what makes the book's title land. Machine Decision Is Not Final opens with a machine-translated sign on a claw machine in China: "Machine's Decision is Final." A machine mistranslating a claim about machine finality is almost too perfect. In one image, the whole argument is there.

At a moment when tools like ChatGPT, Claude, and Grok can write code, draft strategy, generate marketing copy, and even build prototypes, the natural question is: if the machine can do this much, what exactly is left for the human?

The answer, according to this book, is everything that matters.

One of the book's key themes is that decisions which appear to come from machines often turn out to be products of human labor, carrying all the familiar human flaws with them. The fiction writer Xia Jia describes the COVID lockdowns as a moment when the "naive illusion that all submitted information entered some omnipotent system to be automatically processed in good order" dissolved. People realized the system was really just... other people, filling out forms, making mistakes, and interpreting rules inconsistently.

This matters for intrapreneurs because the companies that will win in the GenAI era aren't the ones that automate everything. They're the ones that figure out where human judgment actually creates value — and empower people to exercise it.

That's exactly where the intrapreneur fits. The machine can generate ten product ideas. But someone has to choose which one to build, convince the organization to fund it, navigate the politics, and persist through the inevitable failures. No LLM does that.

DeepSeek's lesson: small teams can challenge giants

There's a parallel in the book that I found striking. DeepSeek — a relatively unknown Chinese AI lab — managed to produce a model that rivaled much larger, better-funded American competitors. Not through brute force, but through efficiency. They used older hardware, optimized their algorithms, and shipped something remarkable at a fraction of the cost.

That's the intrapreneur's playbook too. You don't need the biggest budget. You need the best use of the resources you already have. As Pinchot puts it, the venture capital system beats corporate innovation not because it has more money — but because it empowers individual people to act decisively.

Understand the stack you're building on

Benjamin Bratton's The Stack is the most ambitious of the four books. It proposes that all of planetary-scale computation — from undersea cables to cloud infrastructure to the app on your phone — forms a single, accidental megastructure organized in six layers.

Why does this matter for a software engineer thinking about entrepreneurship?

Because most engineers only think about one or two layers. They write code (Interface/Address) and deploy to the Cloud. But the real value — and the real power — comes from understanding how all the layers connect.

I wrote about this from a different angle in Every App You Use Is Really Just a Conversation. The client-server pattern is just one layer of a much deeper stack. Understanding the full picture changes what you decide to build and how you think about leverage.

Bratton makes a point that hit me hard: "We become what we are by making that which in turn makes us." The tools you build shape the organization that employs you. If you build only what you're told, you're shaped by someone else's vision. If you build what you believe matters — even from inside — you start shaping the organization back.

That's intrapreneurship in one sentence.

Platform sovereignty: who controls the stack controls the future

Bratton introduces the concept of "platform sovereignty" — the idea that whoever controls a platform layer controls the governance of everything built on top of it.

Think about it: Apple controls the Interface layer for iOS. AWS controls the Cloud layer for millions of startups. Google controls the Address layer for how most people find information.

For intrapreneurs, the lesson is: don't just build on platforms. Build the platform. Or at least, understand which layer of the stack your work occupies and how the power dynamics flow.

This is what separates an engineer who ships features from an engineer who shapes products. It's the same distinction Pinchot draws between an inventor (who has the idea) and an intrapreneur (who turns the idea into a business reality).

When delivery speed becomes your marketing

There's a real-world example of all this coming together that I explored in a recent post. Blinkit and Zomato in India transformed a logistics capability — 10-minute delivery — into an entire brand identity. They didn't just build a faster delivery system. They turned speed itself into a marketing message, using memes, cultural timing, and co-branded campaigns.

That's intrapreneurship in action. Someone inside those companies saw that operational capability could become emotional connection. They didn't need to start a new company to do it. They needed the freedom to experiment, a sponsor who believed in the approach, and the persistence to execute.

A framework for Monday morning

Here's my attempt to synthesize all four books into something you can actually use.

Step 1: Find your idea using binary search

Don't brainstorm 100 ideas. Start with filters. What problems do you see every day? What are customers complaining about? What internal tools are embarrassingly bad? Cut the space in half, then in half again.

Step 2: Map your sponsor network using BFS

Every intrapreneur needs a sponsor. Don't go straight to the CEO. Start with your direct network. Who is one hop away who has budget authority or a reputation for backing risky ideas?

Step 3: Ship an MVP using the greedy approach

Build the smallest thing that proves the concept. Don't ask for permission to build a new product. Build a prototype that solves one problem, show it to five people, and let the results speak.

Step 4: Use GenAI for speed, but make the decisions yourself

Let Claude or GPT help you draft, prototype, code, and research. But the judgment calls — what to build, who to build it for, when to pivot, when to persist — those are yours. The machine's decision is not final.

Step 5: Understand which layer of the stack you're working on

Are you building an Interface? Controlling an Address system? Working at the Cloud layer? The more layers you understand, the better you can identify where real leverage and value live.

Step 6: Iterate through failure like dynamic programming

Dynamic programming breaks big problems into overlapping sub-problems and stores the results. Your career works the same way. Each failed experiment gives you knowledge you can reuse. Each small win compounds. Don't try to solve the whole problem at once — solve the sub-problems, cache what you learn, and build up.

Step 7: Earn your intracapital

Pinchot's most radical idea is "intracapital" — an internal fund that a successful intrapreneur earns to fund their next venture. Even if your company doesn't formally offer this, the principle holds: every successful internal project earns you political capital, credibility, and freedom to take on the next one.

A few things I'm taking away

• Most innovators leave companies not because of pay, but because of frustration — they can't act on their ideas
• The venture capital system works because it bets on people, not plans — and your company should too
• Every failed product at Texas Instruments lacked a passionate champion; every successful one had one
• GenAI can generate options, but only humans can judge context, navigate politics, and persist through ambiguity
• The "machine's decision" is never final — the mistranslated sign on a claw machine captures our entire era
• Understanding the full stack — from Earth to User — gives you leverage that coding alone never will
• Binary search, greedy algorithms, BFS, and dynamic programming aren't just interview prep — they're mental models for career decisions
• Your job gives you resources, network, salary, and a real user base — that's a startup advantage most founders would kill for
• Intracapital is real even when it's informal — every successful project earns you the freedom and trust to try the next one
• The question isn't "should I quit my job?" — it's "am I using my position to build something that matters?"

That last one is what all four books are really about, in different languages and different contexts. Pinchot says it through the lens of corporate innovation. Bratton says it through the lens of planetary-scale infrastructure. The authors of Machine Decision Is Not Final say it through the question of what humans contribute when machines can do so much. And Bhargava says it through the simple, elegant idea that complex problems become manageable when you break them into the right sub-problems.

You don't need to quit your job to start building something. You just need to start thinking like someone who builds — even when nobody asked you to.

Sources

• Gifford Pinchot III, Intrapreneuring: Why You Don't Have to Leave the Corporation to Become an Entrepreneur (1985) — the intrapreneurship framework, freedom factors, intracapital, Texas Instruments case study, and the "Class A entrepreneur" principle
• Benjamin H. Bratton, Anna Greenspan, Amy Ireland, Bogna Konior (eds.), Machine Decision Is Not Final (2025) — why human judgment still matters in the GenAI era, the irony of machine-translated finality, DeepSeek's efficiency lesson, and Xia Jia's COVID lockdown fiction
• Benjamin H. Bratton, The Stack: On Software and Sovereignty (2015) — the six-layer model of planetary-scale computation (Earth, Cloud, City, Address, Interface, User), platform sovereignty, and "we become what we are by making that which in turn makes us"
• Aditya Y. Bhargava, Grokking Algorithms, Second Edition (2024) — binary search, greedy algorithms, BFS, dynamic programming, and hash tables as mental models for career and entrepreneurial decision-making