I spent my first six years in a multinational manufacturing company. The kind of place where changing a production server meant a 12-person change advisory board meeting and three signatures from people you'd never met. I was perpetually frustrated. Everything felt slow and political. But what I didn't realize then was that I was absorbing something rare: how to design systems that can't fail, how to communicate risk to non-technical stakeholders, and how to document decisions well enough that someone three years later could understand them. Those skills didn't feel exciting at the time. They felt like busywork. Now they're the foundation of every architecture decision I make.
When I eventually jumped to a 30-person fintech startup, I thought I was escaping into a world of speed and freedom. And I was, at first. Our standups were five minutes. We shipped multiple times a day. I loved it. But then came the first major incident. A database migration went sideways on a Friday night because we had no staging environment that matched production, no rollback procedure, and no on-call rotation. I was the only person who knew the schema well enough to fix it, so I spent 16 hours straight rewinding a transaction log by hand. My enterprise experience had made me assume someone else had thought about these things. In a startup, nobody has—unless you do.
That night taught me something I still carry. In a big company, your career grows by deepening your expertise in a narrow domain and learning to navigate organizational complexity. You become the person who understands the four-way tradeoff between bandwidth, latency, compliance, and cost for a specific data pipeline. In a startup, growth looks entirely different. It's about breadth. You might debug a JavaScript error in the morning, negotiate a vendor contract at lunch, and design a Kubernetes cluster by evening. The learning curve is steeper, but the lessons are often shallower. You know a little about a lot, enough to keep the ship afloat, but maybe not enough to avoid the next iceberg.
The biggest mistake I made—and I made it twice—was trying to transplant practices from one world to the other. In the startup, I attempted to introduce ITIL change management. I built ticket templates and wrote a five-page process document. The CTO pulled me aside and said, "We need to ship code, not tickets." I'd become so institutionalized that I confused process with stability. In the enterprise, I once tried to bypass a security review to get a feature out faster, and got a very polite but very firm email from a compliance director reminding me that SOX audits don't care about my sprint deadlines. Both failures stung because they revealed I wasn't adapting—I was just reacting.
What I've realized since, working as a consultant across both worlds, is that career growth doesn't belong to one environment or the other. It belongs to the person who shows up with curiosity and asks what this place can teach them that the last one couldn't. If you're early in your career, the question isn't "startup or enterprise?" It's "what do I want to be bad at for a while?" Because that's where the growth actually happens. I'm still bad at plenty of things. But now I know which ones I want to work on.