Contrary to the popular stereotype of college drop-out founders, research shows start-ups with older founders are more likely to succeed, and build more valuable companies too.

It’s clear that when it comes to building companies, experience really does matter. And recently, speaking with friends considering starting companies, I’ve been considering what type of experience is ideal to best prepare you to succeed in your own start-up.

I believe if you want the best chance of succeeding as a founder, first join an existing high-growth start-up where you can learn what good looks like, before you start something yourself.

I’m biased from my own experience, but I’ve seen talented friends spin their wheels founding companies that never gained traction, and others who cut their teeth in big-cos just to flounder when they went smaller. In both cases I think experience of scaling a company with an existing team might’ve made a difference, and it may be useful to others if I can explain why.

This post shares the learnings I think are most relevant when starting your own company, with anecdotes drawn from my personal experience working at GoCardless as it grew from 40 to 700 people.

I often come across young big tech employees who tell me their dream is to start or join a startup.

I tell them to GTFO before they learn too many big company habits and become deadweight at startups. https://t.co/HIa6oeWodQ

— Karthik Hariharan (@hkarthik) August 28, 2022

Highs and lows

When I rejoined GoCardless after my internship the company was nearing the end of a chapter, having completed an exhausting migration that had taken a high toll on the entire engineering team.

Almost immediately after I arrived, I learned our VP of Engineering – who I hugely respected – was leaving. Disappointing, but nothing like the shock one month later when, at a Friday debrief, it was announced that our CTO and the two other most senior engineers had also resigned.

I remember that meeting, where I and two others remained at the table after everyone else had left the boardroom. “Shit” and “well this is fucked” was all we managed to say into the shocked silence, and I began to worry that I’d made a terrible mistake.

Had I just rejoined a company about to drive off a ledge? How on earth were things going to be ok after this?

As it turned out, everything was pretty much fine. Different for sure, but people step up and companies evolve, and while it was challenging to fill the gap made by those who had left, it happened faster than you might expect.

Companies go through stages of growth which are felt by their employees as highs and lows. The smaller the company, the more frequent these cycles, and at an early stage start-up you can expect an intense rollercoaster.

This experience, where you lose almost all your senior talent and a good chunk of the total engineering team with it, can happen. And if not that exact situation, you’re bound to hit something else that feels just as existentially threatening.

Knowing you’ve been there before is what allows you to respond with “I know this will be ok” instead of overreacting, or allowing the situation to impact you too harshly. It’s what gives you the confidence to know that when things get tough, it’s only temporary, and you can make it to the other side.

That can be useful for whatever position you may hold, but if you’re a founder with a huge emotional investment in your company, it can be crucial that you have that perspective.

Agency, remit and responsibility

At big companies, process and red-tape enforce limits on the way you behave, occasionally for good reason.

But start-ups don’t work like this. The prime directive of an early-stage company is to move fast, and employees are given substantial agency to tackle the work they believe is most important in order to further their objectives.

Unless you’ve worked in an environment like this, you’re likely to assume limits on your behaviour that don’t actually exist. And if you’re founding a company with those preconceptions, you may create a culture that fails to foster the agency you need to compete against established companies with more resources.

I ran into this headfirst when I joined GoCardless as an intern. I was working on a project to understand Swedish IBANs, the international format for bank accounts that can help route money transfers across borders.

As we were about to start serving Autogiro (Swedish Direct Debit) we needed to translate between national bank details – like a branch code and account number – into the IBAN. But unlike most other IBAN formats, Swedish IBANs have an incomplete and very special-cased view on how to produce an IBAN from national details, and I began to suspect it may not even be possible.

Mentioning this to a colleague and explaining I was stuck, he said that we could sort this out, no problem. Gesturing for me to join him in a meeting room, still with no idea what was going on, we proceeded to phone a number of Swedish bank directors until one of them could point us at an expert or reference that would unblock the work.

I was 19 at the time, and there was no way these directors knew that. It felt like an insane way to get to our answer, but within an hour we did find one. It was a great lesson in how even as the most junior engineer at the company, there was an expectation that I’d walk through walls to achieve my goals.

Beyond agency though, early-stage companies grow fast and provide opportunities to experience problems through the lens of varying sizes of company. Put simply, as the company matures, so does the work that falls into your remit: and you can benefit from the breadth of experience available over different stages of the company’s life.

Case in point: several years later, GoCardless was acquiring a small company in order to absorb its product into our own. As one of the senior SREs, I became involved in the process while it was still confidential, and was sent to the smaller company’s office to work with their engineering team on a plan for migrating their system into our own.

While being the smallest of acquisitions, it was still an experience of how these things are run, and gave me a first-hand view into how something like this is executed. I came away with opinions on how much technical detail should be worked into a legal document (almost none), and some red flags to look for when trying to integrate a totally foreign system into your own, or work with a team outside of your organisation.

I’m unlikely to find myself doing exactly this again, but having real experience of this process – however small – means I have a good idea of what this should look like, the red flags to look out for. That gives me a much better chance of success if I was ever to do this again in a different position, either more senior, or perhaps from the other side of the table.

Perspective and timing

An accepted fact of start-up life is that any process you introduce will break by the time you double the headcount. In general, this is a pain in the ass. But for someone who wants to learn how to apply process at the right time in a company’s life, and in the right way, it’s a golden opportunity.

One challenge in growing companies is the transition from no levels, titles or explicit career path, into an organisation with a clear framework for progression. Fresh founders and managers beware, as screwing this up can cost you dearly, both in your personal credibility and serious attrition if it goes wrong.

The best way to learn the nuance of introducing such a framework is to watch it happen, ideally more than once, within an organisation you know. Personal connections and understanding of the social dynamics mean you’re well positioned to catch both positive and negatives as it lands, as well as a first-hand view as you’re enrolled into the framework too.

My experience at GoCardless included the launch of two separate levelling systems, one more successful than the other. The first introduced engineering levels as L1, L2 and L3, and started the painful process of discussing with each person exactly where they lay on that framework, and resolving any disagreements.

Not being involved in the management process myself, from what I saw the backfilling seemed fairly painless. But launching ‘levels’ hadn’t been a total success, for a few reasons.

Firstly, there was moderate skepticism among engineers that we needed this thing, and it wasn’t fully addressed by the time it was launched. The verbiage of the levelling framework was somewhat to blame – it was written in different tone of voice than the rest of GoCardless’ internal docs, just to start – but even then, the specifics about how to delineate between levels were sparse.

This lead to a subtle but significant rejection of the level system by the engineers within it, visible in several ways but no more clearly than how people spoke about promotions. The phrase ‘levelling up’ came with some confusion, sarcasm and a fair number of Pokemon jokes. I recall the rest of the business being equally amused by the euphemistic nature of moving to the ‘next level’, with my friends in ops teasing me when my promotion email went out.

So not the best, but remember how everything eventually breaks? It means you get to try it again, and so we did.

This time the person leading the work made sure to consult many people across product development on how we’d build the framework. The levels were picked to match the wider industry, and the rest of the organisation were primed to understand what each level meant in terms of relative seniority. And the result was a polished competencies website that was even GoCardless branded, helping it feel like a real part of the company culture.

The framework gave detailed answers about how you’d move between levels and what was expected of you, which was becoming a pain-point as people within the team became increasingly aware of career progression as a thing they should care about, and wanted to engage with.

While seeing just one attempt at launching a levelling framework would have been valuable, I’d argue it’s more than twice as useful to have seen both and make clear comparisons between them. There’s a lot you can learn about the organisation from seeing how things didn’t work, and some important lessons in understanding how ready an organisation is for change, especially in the attempts that didn’t go so well.

I’ve used introducing a levelling framework as an example of how repeated takes at a problem can be a great teacher, and because the idea of introducing a levelling framework without seeing it done before terrifies me.

But you can make the same argument for a lot of engineering work you’d do at different company sizes: you’ll need to solve the same problem many times at different scales, and a second go around the wheel can teach you more nuance than a single shot ever can.

Again, high-growth companies being places where these opportunities are most commonly found.

Hiring

As a founder, it’s your job to build the team around you. If you can’t hire exceptional people then you shouldn’t expect exceptional outcomes: e.g, the outcomes most VCs expect.

One way to find early stage employees is through your network, which – no surprises here – is likely to be stronger if you’ve already completed a stint at a previous start-up. Experience working with someone in a similar context is the gold standard for recruiting.

But past your immediate network, you’ll need to build a recruitment process that can scale with your company and the talent you wish to hire. Again, there are serious benefits to having seen this done before, and seeing what does and doesn’t work.

GoCardless redesigned its engineering interview process three times while I worked there. Initially we’d used technical problems like building Game of Life or answering “how would you build a web crawler” to assess candidates, but found they performed poorly as hiring picked up pace.

Firstly, you’ll find consistency reduces as you broaden your interviewer pool, and you’ll want more rigour in how people are evaluated. And when you start hiring for more specific roles, you may find tailoring the interview process for the discipline – frontend, backend, SRE – might be a better signal for good candidates than putting everyone through the same process.

Learning how to adapt to this data and design new interview formats is a key skill, and one you can develop over time as the company’s hiring needs evolve.

With your experience of designing interviews helping you to establish a process, it’s equally important to become great at interviewing. Interviewing well, by which I mean giving candidates their best chance of success, requires skill that you win through practice.

If you’ve joined a growing start-up, hiring needs are so significant you can’t avoid getting that practice: I’d run almost 1000 interviews by the time I’d left GoCardless, after five years working there.

Provided you have senior peers also involved in interviewing (which you should) then it can be an ideal learning process. You get to try running a similar problem over and over, with the only changing variables being your own skill and the candidates you’re interviewing.

Most interview processes end with a decision meeting, where interviewers regroup and share feedback on the process. This is where you can calibrate yourself with others, and learn a load from those around you. There are a number of decision meetings I remember even now, where I saw senior leadership make hard decisions with conviction, and share their reasoning.

Seeing them draw their own lines helped me decide my own. And if you’re the person building a company, it’s important you’re clear on where you draw them.

You don’t have to, but it can really help

It is clearly not the case that you must have experience working at an existing start-up before you found your own. But if you go into the experience already knowing what ‘good’ looks like for each company stage, it might make the difference between you getting things right first time vs never quite nailing it.

For this reason, I really believe picking a fast growing start-up and staying for several stages of growth can be the best preparation. Riding that wave is a form of career compression, packing several jobs worth of lessons into a few years of intense growth, and is a fast-track to developing skills that will help you found a company of your own.

While not a founder, I’ve been close enough to be grateful I didn’t jump in as soon as I left university. It might’ve worked out, but I wouldn’t have had a clue what I was doing: at least now, if I ever try it, I’ll have a good idea of where to start.

Discuss this post on Hackernews. If you liked this post and want to see more, follow me at @lawrjones.