Why working at a startup made me a better engineer

Just before I joined an early-stage startup as a Founding Engineer I was a Software Engineer at a large corporate company. I had no real experience working in a small fast-paced startup environment; it was all quite new to me. It turned out to be a great place to thrive and learn, and wildly effective in making me a better engineer. Which is why I'm writing this blog, because I think every engineer should spend at least a couple of years at a startup.

You own things e2e

At a big company it's often the case that you spend X amount of months optimising a micro-service which is heavily abstracted, infrastructure and security are done for you and you don't really have to worry about it all. But at a startup you own the entire product from start to finish. From designing the project spec, roadmap, architecture, sitting in client meetings, writing migration strategies, support tickets and pushing fixes to dev/prod daily.

The constant true agile feedback loop is where I think a lot of the critical learning foundations for an engineer really happen. For me I stopped thinking of my contributions as just a small part in a big system and more about the consequences of the design decisions or architectural patterns. (Imo the best kind of feedback loop you can have).

Scope forces breadth

No one at any startup says "that's not my job". One day I was tuning database queries, the next I was debugging a production issue, a couple of hours after I was having a client sprint retrospective clearing up all the tickets we progressed through as a team and new architectural changes. All of this is valuable context which you can take with you forward if you were to specialise in a certain area. Because of that context you start to uncover the why something matters and you'll have horrid sweats and flashbacks to production breaking at 15:59 on a Friday afternoon.

You learn to make decisions with incomplete information

Startups don't have the luxury a lot of the time of six-week design reviews or even half a day making design docs with architectural diagrams and flowcharts, because if a contract is on a tight deadline it might not be necessary to spend the time writing a flowchart that's going to be seen once and forgotten about and more focus on the bug fix or feature request which progresses towards a decommission of a legacy system.

That kind of judgement of knowing when "good enough" is actually properly good enough is a really hard skill in engineering, specifically for me. I really like to get things perfect but time isn't always on our side! Being in a startup has given me this skill and sharpened it.

Proximity to the business changes how you think

When you are in the initial client calls, listening to use cases, your mind switches from "I'm building this because this is what the customer wants" to "I'm building this because this is what the customer needs". The difference being, that shift in focus helps you to understand the business case and focus on building out the MVPs that are gonna hit those key targets quicker. In a world of AI (cough cough Claude), having experienced engineers who can understand the business is a lot more valuable than those who don't.

Speed becomes a habit

In startups shipping weekly (or in my case daily) rewires your instincts. You learn to work on small contained deployable pieces because a feature in production always beats a feature sat waiting for review. At least for me I developed a healthy discomfort with being able to push out features fast (WITHOUT losing any quality ;) ). Smooth is fast or whatever the saying is. Point being at a startup you become a white monster and custard cream fuelled Lightning McQueen (if Lightning McQueen was a full stack engineer and loved caffeine).

You see the consequences of tech debt

Startups are great because they teach you both failure modes. You can very nicely inherit a 2 year old module written in a caffeinated weekend a year and a half ago, and you'll also watch the architecture of a system just completely change to better suit the design or security of a product. This is an awesome lesson because you were there when the tech debt was written but again at the time it made more business sense to do X thing and worry about Y later, it just so happens that a year or so later Y comes around and you think oh no.

Your work is visible

In a small startup there is no ceiling on impact. At least for me, being client facing you get to see how happy and impactful the features, bug fixes or small little changes are and how they help improve so many people's day to day jobs. That kind of visibility is great and helps to remind me why I'm working on what I am and how my job helps others. I'm not just pairing up with Claude to push some code into a repo and never see the use-case.

Caveats

A long winded list… only joking. Working in a startup is great, it might not be for everyone, sometimes it can be chaotic, learning curves can be steep and for me impostor syndrome ROCKETED to an all time high. But there is no better way (at least for me) to learn and develop.

Conclusion

A startup won't make you a better "10x Super Staff++" engineer because the tech stack is fancier. It makes you better because it removes any buffers held between you and reality (real users, real outages, real trade-offs, consequences) all of which you have to decide on. TLDR startups are awesome, pretty cool and you should definitely work for one!