Beginnings

You've incorporated your startup and raised the money. You have an idea you believe in, perhaps a prototype, and the chance to hire people to help you build it. What do you actually do next?

I haven't been involved in raising money, so I don't have firsthand fundraising experience to share. This chapter assumes the funding is already in place.

Before turning the idea into a hiring plan and months of engineering, sit down with the other founders and work out what the funding gives you time to do. How many people can you hire? What do you need to learn or build before the next funding decision? Which assumptions depend on a customer moving as quickly as you hope?

When I chose to build again, our plan allowed for at least three years with a full team. I wanted that time to build with the people we intended to hire. Having lived through funding rounds followed by layoffs, I also knew the assumptions could change. The first commitments needed to make sense against that plan: a hire, an integration or a promise to a customer would all take some of the time we had available.

Start with a customer's work

Suppose someone likes the idea and wants to see more. Before planning around their interest, find out what working with them would involve. There is a difference between someone enjoying a demo and a team making its data and time available to you.

Pick a piece of their actual work and follow it through together. Who does it today? What do they use? Where does it become difficult? Ask what they could show you and who could try what you build. Those answers give the engineers something to work from, and give you a way to agree what you and the customer are each committing to.

We had design partners and sales channels in place when we started. That gave us people to build with, though we still had to discover how the product would fit their work. I had seen that happen at my first startup too: customer conversations gave the engineering work direction as well as helping the company raise money.

Keep the buying conversation going while you work through the technical one. Selling to HR taught me that someone could want the product and still lack the budget or authority to buy it. I expected finance to offer a different opportunity, but that expectation still needed testing with actual buyers. Find out who would pay, which budget it would come from and who else would need to agree. A good demo cannot answer that for you.

Put the first team together

Now you have a clearer idea of the work, you can ask who you need to do it. Start with the problems in front of you and the knowledge you are missing. Some work you can take on yourself; some needs someone who already knows the subject well.

I chose a small, experienced team and expected AI to multiply what we could do. That part held up. I wanted people who could frame a problem and recognise when an approach needed changing. The mix of experience you need depends on the product and what you still have to learn.

“Know your talent, hire your weaknesses” is a line from our values that fits this decision. I hired specialists because they knew things I did not. The People chapter goes into how to approach the hiring itself.

Shared history only takes you so far once people join. They still need to know what they can decide, when to involve you and where to find the context behind the work. Some of those responsibilities were still unstated. Making decision ownership explicit gave us a way to discuss those responsibilities instead of relying on everyone having the same understanding of them.

Share the work of getting started

While you are hiring and building, the company needs to function. Someone has to arrange payroll, answer a customer's security questions and deal with the work that has no specialist yet. Expect to take on things beyond your own speciality, and divide them between the founders so that each responsibility has an owner.

With the other founders in Germany and me in the UK, I took responsibility for setting up and running the UK entity. I was happy to do that work and learned the parts that were new to me. Operations covers the recurring administration and how I want to make it easier to hand over.

Include this work in the plan alongside the engineering. Payroll and a customer deadline can both fall in the same week. A shared list of responsibilities lets you see who is doing what and where someone needs help. Review it alongside the engineering work, especially as customers start asking more of you.

For us, building for finance meant deciding in the first year to pursue SOC 2 and ISO 27001. Some controls I wrote down described what I wanted us to have rather than what we were already doing. I describe that gap in Compliance. Be clear about what is in place, what you have promised and who will do the remaining work; writing a policy does not finish the task it describes.

Get something into use

With a customer willing to work with you and people who can build, choose a part of the customer's workflow to try together. Write down what you still need to find out. A prototype can show whether a screen makes sense while leaving the incoming data, the exceptions and the fit with existing tools largely unexplored.

Real data from our design partners changed the plan we had made around a vibe-coded prototype. We shortened the planning cycle to learn sooner. Delivery covers how we now choose and shape the next goals.

Let what you don't know guide the next piece of work. If the data is the difficult part, spend time with the data. The engineers need to see what arrives, what fails and what the customer does when it fails. You can then write the specification with that experience behind it, instead of treating an untested assumption as a settled decision.

There are engineering foundations I want in place early: service ownership, configuration, tests and a way to release changes. The first customer gives those choices a practical setting. Someone needs to look after the part they are using, and the team needs a way to change it safely.

As people build, keep them involved in what you are learning. A partner may ask for something unexpected, an integration may take longer, or two engineers may make sensible choices that turn out not to fit together. Bring that back to the team and decide what it changes. If new information stays in founder conversations, the engineers will carry on working from an older picture.

I initially set the architecture, hired people for its parts and delegated the rest. I wanted a knowledge graph at the centre, with agents, interfaces and integrations reading from and writing to it. That gave us a place to start. As the work developed, some decisions drifted apart and the team needed clearer priorities from me. I wrote about that experience in Imposter Syndrome Is Real.

As the company grows

Some of the work you take on at the start will move to people you hire. The responsibility and authority need to move together. Habits covers how I track work to hand over and work that comes back; Operations covers checking that the next person can carry it.

The people who join early need room to grow with the company. Talk about what they want to do next while there is time to help them prepare, and make developing them part of an incoming manager's job. People covers what I saw when early colleagues could not see that future, and how I approach their development now.

As more people take responsibility, revisit the arrangements you made when the team was small: who now owns the work, what they can decide and what still comes back to the founders. I have seen that transition in a growing company, but I have not yet made it as CTO beyond the first ten engineers.

Still to write

• Working with co-founders: how we divide decisions between us.
• Scaling: what changes after the first ten engineers, once I have more experience of that transition as CTO.