The startup had been good. We’d grown from twelve people to forty, shipped something real, and the technical foundations were solid. But the Series B had brought in a new leadership layer, the founding team’s velocity calculus had changed, and I found myself doing more coordination than building. I’d been at this inflection point before — at the institution, actually — and I recognised what came next.
The new role was at a well-established European financial technology firm. Structured, profitable, engineering-first culture, around 400 people. Not a startup. Deliberately not a startup.
What I Expected to Miss and Didn’t
Moving fast without friction. At the startup, I could redesign a service, get a second opinion from one person, and deploy by end of day. I expected to miss this badly. I did miss it, but less than expected — because a lot of what felt like “moving fast” was actually incurring invisible debt. Systems I’d built in a day had subtle failure modes we were still chasing two years later. Friction that forces a second opinion is often friction that catches a mistake.
Full ownership. At a startup you own a lot of surface area. The infrastructure, the pipeline, the API, the on-call rotation. At the new firm, ownership was more bounded — I owned a domain, not a stack. Initially frustrating. Eventually freeing: you can go deep without also being responsible for the Kubernetes cluster upgrade.
What Surprised Me
Engineering quality was higher than expected. There’s a persistent narrative that large organisations have worse engineering than startups. It’s sometimes true. In this case, the engineering culture was more disciplined — formal design review, ADRs (architecture decision records), structured incident retrospectives, a real test pyramid. The code was less exciting than the startup (no bleeding-edge tech) but more reliable.
Decisions were faster than the previous institution. This was the real surprise. The firm had grown from a startup itself relatively recently, and had kept some of that culture. A technical decision that would have taken six months at the institution took two weeks here. Not startup speed, but not bureaucratic purgatory either.
Specialisation pressure. At forty engineers you’re a generalist by necessity. At four hundred, the organisation has enough depth that you can go very deep in one area. I spent six months doing almost nothing but redesigning the data ingestion pipeline. That depth produced better work than the breadth I’d been forced into at the startup.
The Adjustment Period
The first two months were uncomfortable. I’d internalised startup instincts — move, decide, ship — that misfired in a context where decisions affected more people. I reviewed a significant architecture proposal in thirty minutes, marked it approved, and found out a week later that it affected three other teams who hadn’t been consulted. At the startup, “three other teams” was the rest of the company; I’d have known in passing. Here it was a genuinely different coordination surface.
The adjustment: spending more time in the “understanding the context” phase before the “deciding” phase. Understanding who is affected by a change before proposing it. This sounds obvious; developing the instinct took longer than it should have.
Why the Stability Mattered
There’s a non-trivial argument for working at a financially stable, profitable firm at certain career stages. The startup years were high-growth in technical breadth; the larger firm let me develop depth and systems-thinking at a scale I couldn’t have accessed otherwise. The lower existential risk also meant I could think on longer timescales — invest in foundational improvements that paid off in a year rather than optimising for next sprint’s demo.
I’m not making a general “large firms are better” argument — context determines everything. But the framing of “startup = good, large org = bad” is as wrong as its inverse. Different environments develop different skills. Both compound.