Between 2020 and 2023 I spent three years at NetApp as a senior fullstack IC. The team I joined was a startup NetApp had acquired, and they had kept operating as a startup inside the larger company. Twenty people, their own roadmap, their own repo, their own deploy pipeline, a Flask backend and React frontend they owned end to end.

The product sat as one tab inside a much larger multi-module system. Each module had its own team, its own deployment cadence, and its own release cycle. The only thing shared across the modules at a technical level was the look-and-feel of the top-level chrome, which had to stay aligned with the rest of the system. Everything below that line was ours.

It was the first time in a long stretch that I was not VP R&D or a co-founder. I was a senior IC on someone else’s roadmap, inside a 10,000-person company that mostly left our tab alone. Most of what I found there was what you would expect from that specific shape of setup. The surprising part is the two things that were not what I expected, and that are now the two things I try to carry into every startup I work with.

What Ran As Expected

Not all of the standard BigCo friction landed on the team, because of how the team was structured. Our deploy pipeline was our own, our planning cycle was ours, our standup was ours. We shipped on our own cadence, not NetApp’s.

Where the enterprise did show up, it showed up at specific seams:

  • Hiring took longer than at a true startup. Opening a req, running the loop, getting the hire approved and onboarded ran through corporate HR and took weeks, not days.
  • Security review on anything touching customer data was thorough and slow. In a storage product, that is roughly everything.
  • The top-level chrome had to align with the rest of the system. If NetApp’s design language changed, our tab’s shell changed with it. We did not own that layer.
  • Cross-team sync lived at the module boundary. The other tabs had their own teams and their own cadences, and the integration seams between our tab and theirs needed coordination that no one tab could do alone.

None of that was crushing. Most of what I did day to day felt like startup work: our own repo, our own tests, our own deploys, our own on-call. The two surprises below happened inside that mostly-startup-shaped bubble.

Surprise #1: Detailed PR Reviews

I had worked in review cultures before. Most of them were polite rubber stamps. “LGTM.” “Looks fine, approved.” The second reviewer skimmed the diff, hit approve, and got back to their own work. Everyone did it. Everyone knew that was what was happening. The reviews were a checkbox on the way to merge, not a mechanism for making the code better.

NetApp was not that. The reviews were careful. A senior engineer would read the diff, actually read it, and come back with specific pushback: a thing that would race, a case the tests did not cover, a naming choice that would be confusing in two months, a schema change that would make the next migration harder. The comments were substantive. The author was expected to respond to each one with either a code change or a reason the reviewer’s concern did not apply. A PR that merged without the reviewer being satisfied was a cultural red flag, not a Tuesday.

What made this work was not a process document. It was a shared expectation. Senior engineers believed the review was part of their job, not an interruption to it. The author expected their diff to come back with substantive comments and planned the week around that happening. The time it took to get a PR through review was longer than at any startup I had been at, and the code that landed was better by a factor that was easy to feel and hard to measure.

Three years of that habit changed how I think about the review step entirely. I no longer think of a PR as “almost merged” when I open it. I think of it as a conversation that will produce the version of the code that actually belongs in production, and the first version I wrote is just the opening offer in that conversation.

Surprise #2: End-to-End Ownership, 0 to Production

The second surprise was ownership. In most of the mid-size orgs I had seen before, features were handed off between layers. A product manager wrote the spec and threw it at engineering. A senior engineer broke it into tasks and handed those to the implementers. The implementers wrote the code and handed it to QA. QA passed it to ops to deploy. Ops passed it to the on-call rotation to monitor. Six people had touched the feature. None of them owned it end-to-end.

At NetApp, inside a 10,000-person company, the engineer who picked up a feature owned it from spec to production monitoring. They wrote the design doc. They talked to the PM to pressure-test the requirements. They did the implementation. They wrote the tests. They set up the metrics and the alerts. They handled the rollout. They watched the dashboards for the first week after launch. If the feature misbehaved in production, they were the one who got the context first, because they were the one who had held the thing in their head the whole time.

This was not solo work. The design review happened with other engineers. The PR review happened with the senior review culture described above. The on-call rotation was still a rotation. But the thread of ownership did not get handed off between phases, and that single piece of continuity changed the quality of every phase.

The engineer who knows they will be the one monitoring the feature in production thinks differently about which metrics are worth adding. The engineer who knows they will be the one answering the customer-support follow-up thinks differently about error messages. The engineer who knows they will be the one writing the migration thinks differently about the schema. Every decision has a feedback loop closed by the same brain, and that is a huge amount of alignment that does not need to be managed through meetings.

Why Those Two Habits Reinforce Each Other

Deep PR reviews and end-to-end ownership are not two separate habits. They are a pair that only works together.

If reviews are careful but ownership is handed off, the review is the only quality gate and it has to catch everything. That is too much to ask of a review.

If ownership is end-to-end but the review is a rubber stamp, the owner has no second brain to catch their blind spots, and the quality of the code degrades to the quality of what the owner alone can see.

The pair, together, puts two senior brains on every change: one holding the thread from spec to production, one specifically looking for what the first brain missed. That is the mechanism. It is why the output of NetApp’s twenty-person squad was in the same universe as what some of the most mature startup teams I had been on produced, despite the surrounding BigCo friction.

The 2026 Version: AI Closes The Gap

For most of the 2010s, deep PR reviews and end-to-end ownership were things you got by being on a well-staffed senior team inside a mature company. A three-engineer seed-stage startup could not have them, structurally. There was no senior reviewer to spare, because every senior was shipping their own features. End-to-end ownership was already the default, but it existed without the review half of the pair, so the quality floor was lower.

In 2026, the economics have changed, and the two habits are suddenly within reach of a three-engineer team.

On the review side, AI is now the second reviewer that a three-person startup did not have. A modern code-review agent reads every diff, flags the race conditions, the uncovered edge cases, the schema concerns, the naming regressions. It catches a very large fraction of what a senior human reviewer would catch, and it does so in seconds. The human still reviews the hard twenty percent, the parts that need judgment and context the model does not have, but the raw rate of “a careful second pass happens on every PR” is now achievable at any team size.

On the ownership side, AI is the force multiplier that makes end-to-end realistic for one person. A single engineer with AI support can draft the design doc, generate the migration, write the test skeleton, set up the metrics, draft the runbook, write the customer-facing release note. The parts that used to require either seniority or helpers from adjacent functions are now one prompt away. The engineer still owns the thinking. The mechanical weight of “doing all the phases of a feature yourself” has dropped by a factor that makes the pattern feasible for teams that could not sustain it before.

The gap closes. The two things I used to envy at NetApp are now, finally, patterns a seed-stage team can adopt from day one. The old tradeoff of “either you ship fast or you ship with mature-team quality controls” dissolves. In 2026 you can have both, and the teams that figure out how to run both will be the ones producing enterprise-grade output at startup cost structures.

What I Would Tell A Founder Right Now

Three things, in order.

Set up the AI code reviewer before the team is big enough to need a human one. Treat its comments the way senior engineers at NetApp treated each other’s: you respond with either a change or a reason. The culture is set in the first ten PRs. Rubber-stamping the AI’s output is as bad as rubber-stamping a human’s.

Make end-to-end ownership the default from the first hire. “You picked it up, you own it from spec to monitoring” is a cultural choice, not a process one. Write it down early. It is harder to introduce later than it is to assume from the start.

Keep the parts of BigCo discipline that are now cheap because of AI, and skip the ones that are still expensive at scale. The quarterly planning cycle is still expensive. The deep review and the end-to-end ownership are not. Steal the two things that work. Leave the rest.

The Short Version

I spent three years at NetApp expecting to find a lesson about why startup speed beats BigCo discipline, and I found something different. The parts of BigCo discipline that cost real time (planning cycles, approvals, cross-team sync) are the parts a startup can skip. The parts that cost almost nothing and produce most of the quality (deep PR review, end-to-end ownership) are the parts a startup should adopt as early as possible.

In 2026, AI makes both of those cheap enough that any team can run them. The teams that do will produce output that is hard to tell apart from a mature twenty-person squad, with a fraction of the headcount.

Let’s Talk

If you are a founder trying to decide which engineering habits to adopt early and which to defer, or you are a CTO at a growing startup trying to lift the quality floor without doubling the team, that is exactly the kind of thing I work through with founders. No pitch. Happy to look at your current review culture and ownership model and tell you what I would change. Reach out.