5 Things I’ve Learnt Since Leaving a Corporate Job (and Starting a Startup)

Since quitting my job at an investment bank over a year ago, I’ve been living the startup dream: travelling the world and launching products (JournoRequests, ProfileHopper, Hey.Press, ProductFriends and others). Some have worked and while most have failed, I feel like I’ve picked up some knowledge along the way.

Here are five important things I’ve learnt:

1. Nothing is out of bounds

Corporate firms have rules, procedures, a certain way of doing things. Although a these are often there for a reason (thousands of employees need some sort of order to function efficiently), boundaries confine innovation.

One of the hardest transitions for me was coming from a culture of “we’ve always done it this way” to having to try new things in order to learn what works and what doesn’t. As a startup founder crafting your own product, pushing the boundaries is key to building a wide and stable foundation.

2. Move fast but keep the target in mind

Working without bureaucracy is great — you can ship stuff faster, respond to users quicker and nudge your company strategy to avoid incoming threats.

“Move fast and break things” right? Right. Except imagine your startup journey as a dart travelling through the air. You can adjust its path mid-air and you do this, many times a week. However, it doesn’t matter how finely or how often you adjust, if you don’t know or haven’t fully considered what the target is. Short term, you’re killing it — but long term, you’re just never going to hit that target.

3. Just keep learning

Many people in corporate jobs hit a learning wall after a few years. This is when they’ve acquired the majority of the knowledge they need in order to operate in their day job to a high standard. As a result, work quickly becomes boring and people move to other roles in search for new challenges.

I think the same thing happens when you’re working for yourself, albeit at a faster pace. In contrast to a corporate job where the specifications of a role are predefined, in a startup, you are responsible for defining them yourself. As a result, it becomes easy to learn only the minimum amount required for a role. This means you limit your ability to respond effectively to customer feedback (“we can’t build this, it’s too tricky”) and to innovate.

Technology is an incredibly fast moving sector. If you don’t keep up, you’ll fall by the wayside.

4. Filter out the noise

Perhaps as a testament to the growing startup community, meetups, events and hackathons are everywhere. In cities (and remote locations) across the world, you can attend gatherings focused on topics ranging from “pitching” to “growth hacking” to “hiring”.

What’s useful to bear in mind, however, is how much value these events are for you. It’s easy to get lost in the sea of meetups and forget about the reason why you have the luxury of attending an SEO seminar at 1pm on a Tuesday afternoon. Communities and events can be extremely useful, but focus on the ones that matter to you.

5. Code quality, Code Shmuality

As I’d developed most of the code base for our products, I had the choice of deciding how to write the code. All of a sudden, I didn’t have to write unit tests, integration tests, or even bother with opening issue trackers. There were no code reviews and there was no pressure to properly document what I’d written. As a result, we shipped things extremely quickly – features that had taken me 2 weeks to complete at my old job were now taking me a day. This was great, until things went wrong (which they often did).

Very quickly, I found myself spending the same amount of time writing makeshift scripts to test functionality as I would actually writing unit tests, whilst development had slowed down as I tried to make sense of lines of code that I had (not-so-elegantly) previously written.

In short, writing code is a trade-off — it might be tempting to trade quality for speed when building an MVP, but at some point, those corners you cut will come back to bite you. As an MVP transitions into a full product, it’s important to dedicate time in order to make sure the code base is maintained and written well. Otherwise, you’ll be looking at some major (and costly) headaches down the line.

—

If you’ve liked what you’ve read, please hit the heart below so other people can stumble across this.

For more thoughts, follow me below or get in touch via twitter.