Your First 90 Days at a Startup Will Make or Break You. Here's the Playbook.

He's a great engineer. Consistently strong performer at Google for four years. But he spent his first month at the startup doing what had always worked at Google: reading documentation, attending meetings, building context slowly, asking permission before making changes.

At a startup, that looks like doing nothing.

His manager told him, candidly, during the PIP conversation: "We hired you to move fast. You spent six weeks asking questions and two weeks writing a design doc for something that should have shipped in a week."

This story isn't unusual. The transition from big tech to startup — or from school to startup, or from any structured environment to a chaotic one — breaks people who are genuinely talented but don't adapt their operating model fast enough.

Why startups are different (and it's not what you think)

The standard advice about startup culture focuses on the wrong things. "Move fast and break things." "Wear many hats." "Be comfortable with ambiguity." These are platitudes that don't tell you what to actually do differently on Monday morning.

Here's what's actually different, in concrete terms:

Feedback loops are shorter and harsher. At a large company, you might get a formal review every 6 months. At a startup, your manager is forming opinions about you every single day. By week 3, most startup managers have already mentally categorized new hires as "this is going to work" or "I'm worried." You don't get a 6-month runway to prove yourself. You get 6 weeks, maybe less.

Nobody will tell you what to do. This sounds obvious, but the practical implications are brutal for people coming from structured environments. There's no onboarding curriculum. There's no mentor assigned to you. There's often no documentation for the codebase, the product strategy, or the customer base. You're expected to figure it out by doing, not by reading.

Visible output is the only currency. At a big company, being thoughtful, asking good questions, and building relationships are valued activities. At a startup, they're invisible. The only thing that registers is shipping — code merged, designs delivered, campaigns launched, deals closed. Everything else is overhead.

The 30-60-90 framework that actually works

Days 1-30: Ship something small, fast

Your only goal in the first month is to prove you can produce output in this environment. Not impressive output. Not strategic output. Just output.

For engineers: find the smallest possible bug or feature request, fix it, and get it merged. Ideally within your first week. I've seen new hires spend their entire first month "getting up to speed" and not shipping a single line of code. That's a death sentence at a startup.

For designers: pick one screen or flow that's obviously broken, redesign it, and present it. Don't wait for a formal project assignment. The act of identifying a problem and proposing a solution — without being asked — is the single strongest signal you can send.

For PMs: write a one-page analysis of something you noticed in the product that doesn't make sense. Not a 20-page strategy doc. One page, with data if you can find it, and a specific recommendation.

For anyone: the first thing you ship doesn't need to be good. It needs to be done. You're establishing a pattern — "this person produces things" — and that pattern matters more than the quality of any individual deliverable in month one.

Days 30-60: Find the burning problem nobody owns

Every startup has problems that everyone knows about but nobody is working on. A customer segment that's churning and nobody's analyzed why. A deployment process that takes 4 hours and everyone just lives with it. A feature that customers keep asking for but never makes it onto the roadmap.

These unowned problems are your opportunity. Pick one, make it yours, and start making visible progress on it. You don't need permission. You don't need a project plan. You need to start showing results.

The key word is "visible." At a big company, you can do great work quietly and trust that the system will eventually recognize it. At a startup, if your manager doesn't see it, it didn't happen. Send updates. Show your work. Demo things in team meetings. This isn't self-promotion — it's communication, and it's a survival skill.

Days 60-90: Have an opinion about the future

By day 60, you've shipped things and solved a real problem. Now you need to demonstrate strategic thinking. This is where you transition from "reliable executor" to "someone we want to keep long-term."

Write down your perspective on what the team or company should do differently. Not a vague "we should improve our processes" statement — a specific, opinionated take. "We're losing deals to Competitor X because our onboarding takes 3 weeks and theirs takes 3 days. Here's how we could cut it to 5 days."

Share it with your manager. Not in a meeting — in writing, so they can think about it. The goal isn't to be right. The goal is to show that you're thinking beyond your immediate tasks about the broader business.

The five mistakes that get people fired

I've watched enough startup flame-outs to identify the patterns. These are the behaviors that consistently lead to early departures:

1. Waiting to be told what to do. This is the number one killer. If you're sitting in your second week waiting for your manager to assign you a task, you're already behind. At a startup, the expectation is that you'll find work, not wait for it.

2. Over-engineering the first project. Your first project is not the time to introduce a new framework, refactor the architecture, or write comprehensive tests for untested code. Ship the simplest possible solution. You can improve it later, after you've earned credibility.

3. Criticizing without contributing. It's easy to see what's wrong at a startup — everything is messy. But pointing out problems without offering solutions makes you a liability, not an asset. Every critique should come with a proposed fix, even if the fix is imperfect.

4. Treating 1:1s as status updates. Your weekly 1:1 with your manager is the most important meeting on your calendar. Don't waste it reciting what you did this week. Use it to align on priorities, surface blockers, and get feedback. Ask directly: "What's the most important thing I could be doing right now that I'm not?"

5. Not asking for feedback early enough. Don't wait for your first formal review to find out how you're doing. By then, opinions are already formed. Ask for feedback in week 2, week 4, and week 8. Specific questions work better than "how am I doing?" — try "what's one thing I should do differently?"

The meta-skill nobody mentions

There's one skill that predicts startup success better than technical ability, domain expertise, or years of experience: the ability to operate with incomplete information and still make progress.

At a big company, you can usually find the answer to any question by asking the right person or reading the right document. At a startup, the answer often doesn't exist yet. The product strategy is half-formed. The customer data is incomplete. The technical architecture has undocumented assumptions.

The people who thrive in this environment are the ones who can make reasonable decisions with 60% of the information and course-correct as they learn more. The people who struggle are the ones who need 90% certainty before they'll act.

If you're joining a startup, practice this: when you encounter a question you can't answer, make your best guess, act on it, and see what happens. You'll be wrong sometimes. That's fine. Being wrong and learning quickly is infinitely better than being paralyzed and learning nothing.

Your first 90 days aren't an extended interview. They're a compressed version of your entire career at the company. The patterns you establish — how fast you ship, how you handle ambiguity, whether you find problems or wait for assignments — will follow you for as long as you're there. Get them right early.