Moving From a Big Company to a Startup, and Back

Scope at a large company and scope at a small one are different shapes. One gives you depth in a narrow slice and a great deal of surrounding infrastructure; the other gives you breadth and no infrastructure at all. Both are real engineering experience.

The problem is that each side reads the other’s resume for the thing it doesn’t have. A ten-person team looks at a big-company resume and wonders whether anything got built without a platform team underneath it. A large organisation looks at a startup resume and wonders whether anything was ever done to a standard. Neither doubt is unreasonable, and both are answerable on the page.

What the size of your employer changes

It changes what a bullet is evidence of, which is why the same sentence lands differently in the two directions.

“Owned the deployment pipeline for our services” at a company with a platform organisation means you configured and extended something substantial that already existed. At a company of eight, it means you chose it, built it, and are the reason it works. Both are worth having. They are not the same claim, and a reader who mis-infers which one you mean will either overrate or underrate you.

The fix is the same in every case in this post: make the environment explicit and let the reader calibrate. One clause of context is enough.

Illustration: Northwind (payments infrastructure, roughly nine hundred engineers) — Owned the fraud-decision service inside a platform with a dedicated deploy, observability, and on-call tooling org.

Illustration: Larkspur (seed-stage logistics, six engineers) — Owned the fraud-decision service, its Terraform, its alerting, and its on-call, because there was nobody else to own them.

More on that construction in the context line above your bullets.

Big company to small: what they are actually worried about

Three specific doubts, and they are worth naming because most big-company resumes accidentally confirm all three.

That your scope was narrow. A resume listing one service across four years at a large employer is entirely normal there and reads as thin to a small team who need someone to cover four things at once. Counter it with the breadth you genuinely had: adjacent systems you debugged, the migration that took you into another team’s code, the time you owned the database as well as the service.

That you needed the scaffolding. This is the real one. If everything you shipped went out through a pipeline someone else built, onto clusters someone else ran, with dashboards someone else configured, a small team cannot tell whether you can operate without them. The evidence they want is anything you built from nothing: a tool, a test harness, an internal service that had no template, a project where you set up your own monitoring.

That you work at a large company’s pace. Design review, staged rollouts, and quarterly planning are the correct behaviour in a big system and read as slow in a small one. Don’t pretend otherwise — instead show a piece of work with a short cycle: the prototype in a week, the incident fixed the same day, the thing you shipped alone.

What not to do is deflate your actual scope in an attempt to sound scrappy. Depth is the thing you have that they don’t, and a bullet showing that you have been inside a database or a scheduler at a level of detail their whole team has never needed is a strong argument for hiring you.

Small company to big: the mirror image

The doubts invert.

That the scale wasn’t there. A system handling modest traffic teaches you the same engineering as one handling large traffic, but the resume can’t say “high scale” without inviting a question. Say the real numbers where they’re interesting and describe the difficulty where they aren’t: a small system with a hard correctness requirement, a tricky concurrency problem, or an integration with a payment provider is more persuasive than an inflated volume claim. When the numbers belong to another team covers which figures survive questioning.

That the breadth is a centimetre deep. The honest hazard of small-company work: you did everything and none of it for long. Pick one or two areas and go deep on the page even though your job was broad. A resume that reads “I touched all of it” gives a reviewer nothing to interview you about; one that says “I touched all of it and here is the part I know properly” gives them a conversation.

That you have never worked inside anyone else’s standards. Large organisations are mostly about operating within constraints set elsewhere — review processes, shared libraries, deprecation timelines, other teams’ interfaces. If your evidence for that is thin, open-source contribution is the cheapest place to get some, because it is precisely the experience of getting a change through someone else’s review process. That argument is in side projects, open source, and what counts.

The breadth trap, and how to write around it

The characteristic small-company bullet is a list of everything:

Too broad: Built and maintained the backend, frontend, infrastructure, CI, and data pipeline.

That is probably accurate and it reads as no ownership of anything, because there is no unit in it. The stronger version keeps the breadth as context and puts one real thing in the foreground:

Better: Sole backend engineer for the first two years — built the API, the Postgres schema, and the Terraform that ran them. The part I’d point at is the ingest path: it had to accept duplicate webhook deliveries from three carriers, so it was keyed on carrier event IDs with a reconciliation job that caught the gaps.

Breadth in the first sentence, depth in the second. That pattern works for almost every small-company resume.

Where the trade-off is genuinely a trade-off

It’s worth being honest that neither background is strictly better and both have a real cost.

Big-company experience buys depth, exposure to scale, and the habits of a mature engineering process, at the cost of surface area and of knowing how much of your effectiveness was the environment. Small-company experience buys ownership, speed, and end-to-end understanding, at the cost of depth and of ever having seen a system with a serious operational floor under it.

Stating your side of that trade-off explicitly is more credible than papering over it. A clause like three engineers total, so I owned the deploy pipeline and the database as well as the service tells a reader more than any adjective, and it is the naming-the-constraint move recommended in scope, not years.

The one edit for either direction

Find the doubt your resume creates about you and answer it in one bullet, near the top.

For a big-company engineer applying small, that bullet is something you built with no support underneath it. For a small-company engineer applying large, it is something you did to someone else’s standard, or one piece of your system you understand far past the level your job required. Neither takes an invented number, and either one changes what the rest of the page is read against.