I left a well-paying, intellectually interesting job at a large financial institution to join a company with fewer than twenty people and less than a year of runway. My colleagues thought I’d lost perspective. My family was diplomatically concerned. Here’s the honest version of the reasoning.

What Was Good About Where I Was

The previous role wasn’t bad. I want to be clear about that, because “I left for a startup” can imply the previous situation was intolerable. It wasn’t.

The problems were interesting — distributed systems at real scale, correctness requirements that couldn’t be hand-waved, data volumes that forced genuine architectural thought. The compensation was good. The job security was excellent. I was learning.

But three years in, I noticed something: the learning rate had dropped sharply. The problems were still interesting, but they were the same interesting problems, in the same domains, with the same constraints. I was becoming expert at navigating the firm’s specific environment — its processes, its politics, its particular flavour of Java enterprise — rather than becoming a better engineer.

The distinction matters. One compounds generally; the other compounds locally and transfers poorly.

The Pace Problem

The thing that eroded the most: pace of decision-making. Not pace of execution — plenty of smart people worked hard there. But from “we should build X” to “X is in production” the timeline was rarely under six months and often closer to two years.

Some of this is rational (regulated environment, change management, blast radius). Some of it is organisational sediment — processes accumulated over decades that no one actively wanted but no one had mandate to remove.

For someone who cares about the feedback loop between idea and production reality, this pace is an anti-learning environment in a specific way. You couldn’t run experiments quickly. You couldn’t fail fast. The iteration cycle was too long to build strong intuitions about what worked.

The Startup Proposition

The new company was in financial data infrastructure — close enough to what I knew that the domain knowledge was immediately applicable, but different enough that I’d be solving new problems.

The offer was equity, a salary cut, and a title that meant very little. What it actually represented: I’d be one of the first engineers, building a system from scratch, with real ownership of technical decisions.

Full ownership is the thing that’s hard to replicate in a large organisation. You can influence decisions, advocate for approaches, sometimes win. But you don’t own them. Someone else has the final say, and you spend energy on internal alignment that at a small company you spend on building things.

The Fears (Honest)

  • Runway: under a year isn’t much. I had a family and a mortgage.
  • Upside uncertainty: equity at an early-stage startup is mostly lottery tickets dressed in a spreadsheet
  • Technology risk: the codebase was in Go, which I barely knew at the time
  • Founder risk: I’d be betting on founders I’d known for a few months

The runway fear was the legitimate one. I negotiated a slightly higher starting salary to extend my personal runway if things went badly.

The Go risk turned out to be the best thing about the decision. More on that separately.

Two Months In

The feedback loop shock was immediate. In the first week I pushed five significant changes to production. In my last six months at the institution I’d pushed two. The debugging cycle shrank from days (reproduce in test environment, change management, staging, etc.) to hours (it’s in the logs, fix it, deploy).

The scope shock was also immediate — in a different direction. Previously I’d owned a component. Now I owned the infrastructure, the data pipeline, the API, and intermittently the CI setup and the on-call rotation. Breadth that specialisation had never forced.

Whether it was the right call: I think so. But I’m aware that’s easy to say when it worked out.