Lessons from a first-time founder/CTO

From 2018 to 2023, I was building and overseeing engineering at rebank. We developed an international banking and payments product that integrated with banks, financial data sources and payment services across the world to create a "financial source-of-truth" for international companies. Rebank processed $100m+ in payment volume for our customers across 55 countries and 17 currencies, before we eventually sunset it to focus on our pivot.

Building "rebank v1" was the most challenging and rewarding project I've worked on in my career. This is partly because as a first-time founder/CTO of a startup, you are inherently not qualified for the job when starting out. You can be the best software engineer or engineering manager, but this means little when transitioning into the role of CTO in a company that is without a product and default-dead. There are simply some things that cannot be taught, and they must be learned by action. Trial and error, regular mistakes and relying on your ability to learn quickly and course-correct your way to continuing competence that keeps pace with the speed of your company's growth.

From my own experience, and speaking to several founder CTOs from both successful and unsuccessful companies, I've refined a list of what I think are the most important themes to understand in order to be successful as a founder/CTO.

Each of these deserves it's own post so let me know which you're most interested in hearing more about.

Success comes from understanding your customers, not technology

When you're at pre-seed/seed, the only thing that really matters is answering two questions before you run out of money:

• Does my product solve a problem that customers care about? and;
• Will my customers pay to have this problem solved?

Your success in answering these questions will depend on how well you understand your customers, and how quickly you can prove that your hypothesis is correct. Your deep knowledge of technology and the technical implementation details of your product are largely irrelevant at this stage of the company.

Therefore, don't be confused by your title. "CTO" doesn't mean that you're the "tech" person that just builds what you're told, and the other founder is the "business" person feeding you requirements. The CEO and CTO roles early in your company's life are very similar. You are responsible for answering the two questions above. The only real difference is that you lean on your previous skills and problem-solver mindset to optimise how quickly you can answer them.

Optimise for speed

One of the worst mistakes a founder/CTO can make is assuming that you already know what your product will do, it's just a matter of prioritising a roadmap.

Starting a startup is testing a market hypothesis. You and your co-founder(s) believe that your product solves a problem that your target customers care about, and you think that they'll pay for it, but you do not yet know if this is true.

To find out, you will have to build, test with customers, get their feedback, and repeat. You're going to have to do this many times to find signs of product-market fit (PMF) before you run out of money.

Here's a calculation (albeit oversimplified) that might help illustrate the importance of this concept, assuming that it takes 100 product iterations to find PMF:

Cash at bank = $1,000,000
Monthly net burn = $50,000
Runway = 20 months

Scenario 1 (2 weeks per product iteration):

Time-to-traction = 100 iterations x time per iteration (2 weeks) = 46 months

Runway (20 months) - time-to-traction (46 months) = -26 months

❌ Company is dead

Scenario 2 (3 days per product iteration):

Time-to-traction = 100 iterations x time per iteration (3 days) = 10 months

Runway (20 months) - time-to-traction (10 months) = +10 months

✅ Company is alive

Therefore, as the engineering lead you need to optimise for speed of iteration. Technical cleanliness and scalability come after you have validated that customers actually want what you're building.

To use an analogy...

Investing in tech scalability pre-PMF is like renovating your kitchen while your house is burning down.

"Do it right the first time" is a common misnomer in software engineering usually espoused by inexperienced or incompetent engineers. You don't really know what you're building yet, and that's OK. Keep things simple, flexible, and optimise for learning from your customers as quickly as possible.

The tactical use of tech is a powerful tool to this end. I wrote about this in more detail here.

Keep everything as simple as you can, for as long as you can

One of the most effective ways you can optimise for speed is by keeping your tech stack and systems as simple as you can for as long as you can.

Keeping your tech stack and systems simple means you can maximise the time your team is spending on product iterations that increase customer value. Every hour you and your engineers spend building and maintaining complex architecture, infrastructure and tooling increases the risk of running out of money before you get product traction.

So what does "good" generally look like here?

✅ Good

• Programming language and database you're already proficient in
• Monolith architecture + mono-repo
• Managed infrastructure and databases e.g. Heroku, Encore, Vercel
• Automated CI/CD pipeline
• Ephemeral preview environments + database schema versioning

❌ Bad

• Microservices architecture*
• Kubernetes (especially self-managed)
• Custom-built ancillary systems (auth, storage, notifications, logging)
• Complex network architecture
• Self-managed infrastructure

* Microservice architectures solve organisational problems far more than they do technical problems. You have neither yet, so the management overhead and complexity are difficult to justify. However, managed infrastructure products like Encore are making this far more achievable if you feel strongly about microservices from day one.

Yes, I realise there are exceptions here, but they're mostly related to deep tech workloads, or legal, regulatory and privacy requirements.

Remember, complex architectures and infrastructure are one of the most prolific silent killers of startups.

Tech stack is more than just personal preference

Choosing your tech stack will have a material impact on your chances of success, but not in the way you might think.

Engineers have an unfortunate habit of gravitating towards new technology trends (e.g. graphQL, noSQL, blockchain) while ignoring the second and third-order effects of these decisions.

Your tech stack is not just about what will scale technically or what tool is "right for the job". You need to think about how it aligns with your growth goals, including speed of development, cost of maintenance, ease of hiring, security, documentation and support.

Here's how I think you should prioritise selecting your tech stack (in order):

1. Previous knowledge (i.e you're already highly proficient in the language or tool and can build fast with it)
2. Stability (favour stable, well supported and battle-tested technologies unless there's a very good reason not to. Postgres, Java, React, Go are all good examples)
3. Community support (the quality of documentation and maintenance)
4. Hiring market (market is abundant with engineers and their salary expectations are reasonable)
5. Use case suitability/scalability (how well it will technically and operationally scale based on your use case)

Now you might be asking "How can you justify putting use case suitability last?!", and my answer is that at this stage of the company, it is the least important factor. You don't have scale yet, and if you don't reach PMF you never will, so don't optimise for it. When you do you'll have highly skilled, dedicated teams supported by a healthy revenue stream able to migrate to new languages and tools if required.

Remember Facebook, one of the largest tech companies in the world, was built on and still runs primarily on PHP, a language that many an engineer says "doesn't scale".

Hiring is your most important job, treat it as such

Once you step into the role of founder, your technical skills become far less important than your ability to build a world-class team, and your success or failure as a CTO is ultimately going to be measured by whether you can hire and retain great engineers.

Hiring is the most important responsibility you have because your team will make or break the company, and if everything goes well and your company is growing rapidly, you're going to be spending 80%+ of your time on hiring for long periods.

This is not only because you need to have an effective and thorough hiring process, but because the best engineers are in high demand and usually not actively looking for a new role. You simply aren't going to be able to hire great people by posting on job boards or hiring a recruiter, so get ready to spend a lot of time headhunting on Linkedin and Github.

I won't cover hiring processes in this post, but traits you should optimise for when hiring engineers for early-stage startups are:

• Steep career trajectory (vs years experience)
• Asks for forgiveness, not permission
• Pragmatic (keeps things simple)
• Openly and constructively challenges your decisions
• Accepts and adjusts to constructive criticism
• Intellectually creative and curious

You'll notice I haven't mentioned anything to do with technical skillset, and this is because I think you should always optimise hiring for behaviours over skills.

It's a lot easier to teach an engineer with positive behaviours new skills than it is to manage a technically skilled engineer with negative or toxic behaviours.

Fire bad hires quickly

It doesn't matter how good you are at hiring or how thorough your process is, you're going to make some bad hires. It's simply unavoidable.

Due to the time and effort required to hire, and the fact that you've personally vouched for this person enough for the company to invest in them, it can be tempting to "see how it goes" or put the issue on the back-burner.

Unfortunately, you're probably grossly underestimating the negative effect this is having on the company. Why you ask?

• Keeping a bad hire communicates the standards you accept to the rest of the company. A-grade players won't stick around if they sense you're running a B-grade company. Taking swift action reinforces your company culture and standards.
• Bad hires spread bad behaviours through company culture like a cancer. Poor performance, negative attitude, gossiping and gaslighting spread through a company like wildfire because new hires tend to end up modelling the behaviours of your existing team.
• Managing bad hires is expensive and time-consuming. You cannot afford to waste time and energy on negative-value resources.

Buy vs build: only build where you can provide unique value

In order to optimise for the velocity of product development, you and your engineering team need to spend as much time and energy as possible on user-facing features and functionality that will move you closer to PMF.

Building to solve problems that are already solved by other products or companies is an effective way to destroy your product development velocity and kill your startup.

🚨 Rule: only build where you can deliver unique value and the functionality is core to what your product does 🚨

Building anything outside of this is generally a waste of time and will slow your engineering team down with not only the initial build, but the ongoing maintenance as well. So many libraries, products and companies have been created because engineers tried to build something in-house and realised it was unexpectedly difficult so they've productised it. Learn from their mistakes and use their products!

Good examples of things you should generally never build yourself (without a very good reason) include, but are not limited to:

• Authentication
• Authorisation
• Anything that works with timezones: scheduling, calendars etc
• Notifications
• Internal tooling
• Real-time client-side updates (e.g. websocket implementations)

Protect your engineers' focus

To operate at full capacity, your engineers need uninterrupted periods of deep work. Software engineering relies heavily on working memory, and any interruption of focus can result in a delay of returning to productivity of almost half an hour, and slow down completion of pull requests by up to 225%.

Asynchronous-first communication

Asynchronous communication not only reduces disruption to focused work but also drives standards in the efficiency of communication and documentation.

Asynchronous communication generally results in company information being stored in written, or transcribable form. The benefits of which include:

• Reduced need to repeat conversations
• Reduced risk of information being lost or misinterpreted
• Reduced need for expensive meetings and ad-hoc conversations
• Increased capacity for deep work
• Increased productivity bandwidth
• Increased velocity of new hire onboarding
• Increased employee satisfaction

Habitually scheduling calls and meetings for every discussion or exchange of information creates several problems, including:

• High cost of communication i.e. you're preventing (n) colleagues from delivering value by forcing them to consume the information that you want to communicate, when it suits you (or vice-versa)
• Volatile information retention i.e. information that is spoken and/or recorded in private notes is siloed to a small number of individuals, gets lost and/or misinterpreted
• Forced context switching i.e. everyone has to stop what they're doing to engage in the discussion
• Culture issues i.e. creates a culture of laziness and inefficiency in communication. Employees start to resent individuals or teams that are either regularly requesting meetings or "a few minutes to sync up", or on the other hand blocking others from making progress because they have some information that others need.

Meeting criteria

You should set strict criteria for what necessitates a call or meeting, and the onus should be on the person scheduling the meeting to satisfy these criteria. These criteria should be agreed upon and communicated publicly, with each attendee given the autonomy to reject the meeting if the criteria are not met.

An example of these might be:

• Must be time sensitive
• Must have an agenda with notes for attendees to review prior to the meeting
• Must have clearly defined objective
• Must have actions items for individuals by the end of the meeting

Obvious exceptions to these criteria are sensitive conversations, relationship building (new hire onboarding etc) and customer conversations.

Note: it's natural that your communication early in the company's life will be more synchronous and ad-hoc, just keep an eye on it once you introduce multiple communication nodes as you grow the team.

Meeting blackouts

You should have set times during the day when no internal meetings are to be scheduled. This helps with deep work and forces your team to be efficient and organised with scheduled meetings.

At rebank, we enforced an internal meeting blackout between 11am and 4pm, so the team had several hours per day, uninterrupted, to focus on deep work.

Communication accountability

Every individual in your team is responsible for how they communicate. Just like any other aspect of their performance, if they're not operating at the standard required, then it's your responsibility to ensure that it's corrected.

Let me know your thoughts in the comments or on Twitter, and which areas you'd like to hear more about in future posts.