Ask HN: Startup grew from 2 to 3 people. What should CEO be paying attention to?

[hapanin]

CEO of a basement ML/hardware company. My CTO/brother is primarily on algorithm and firmware right now and we just brought on a long time friend and occasional coworker as COO / product lead. I fill all over the place. So far things have been going fine, but they're fine until they're not and I'd like to know what you all have had to do when your team grew by 50% overnight. Some things we've had to change already are:

> Use actual task tracking software instead of personal to-do lists

> Actual scheduled planning meetings instead of random thoughts about business at the kitchen table

> Converting to a Delaware C Corp instead of WA LLC

> Compiling a list of mentors, advisors, and other network connections

> Daily standup (5 minute)

> Actual office space

> Deliberate company culture initiatives instead of decades of established family values

Hit me with your war stories and advice.

[keiferski]

Just a semi-warning: be wary of falling into a "well, we're at stage X, so now we have to do the things you're supposed to do. Most of the stuff you listed sounds reasonable and warranted, but it's very easy for "we needed to some basic office space" to turn into "we needed fancy chairs, an espresso machine, and a foosball table." Remember that you're still just a 3-person startup, even if you technically increased staff by 50%.

An analog in personal life would be "I'm 35, I've been dating the same guy/gal for 5 years, so I should get married and have kids, because that's what you're supposed to do."

[codegeek]

"team grew by 50% overnight"

Technically yes but you only went from 2 to 3. That is not a huge change. I grew our team (2 brothers as well) to 12 and that has been a tremendous challenge being bootstrapped without any help. My brother is also the CTO but he has no strategic/entrepreneurial ambitions even though he is really really good at what he does.

I would say don't over think this. Yes, you will ultimately need more systems/process/planning but with 3 people, its not a whole lot yet. In my personal experience, I started realizing the need for some of these when we went past 10 of us but it all depends on where the team is and if everyone works in the same office.

I highly recommend getting some type of office space asap even if co=working/shared. I am a big believer in people getting together in person specially for startups. Even if it is not all the time but you need a place where the team can get together. If you do get an office space, plan to stay there at least 2 years before you can outgrow it unless you really hit the home run. Baby Steps, one thing at a time. Good luck.

[manigandham]

You're doing fine. Writing down all communications is a solid step. Don't get caught up in process this early because you're going to burn up valuable time and effort.

Worry about your customers, your product and the end goal, whatever that is for the ML/hardware you're making. Make sure everybody understands that and things will work out until you get to >10 people.

Also remember that culture is something that grows bottom up. You don't set it by decree, rather it's something that forms from the shared values and motivations of the people you hire. Keep that in mind when forming your team because those early employees will have a massively outsized impact on the company going forward.

[hapanin]

Yeah. No plans for any hires in the next 2 months at least, maybe longer. I think in general I'm actually too passive about culture and process since I assume everyone is as proactive as I am. Too little decree results in anarchy or weak leadership.

[manigandham]

You're way too early to be thinking about this now. Seriously. Strong leadership doesn't come from setting rules, it comes from being the example so that others willingly follow you.

Just focus on making the best product you can and taking care of your customers, and make sure the others are doing the same. You'll find that people either understand and copy the behavior or they'll start wavering, at which point you can figure out why and if they should stay with the company.

[apotheosis-neko]

With three people, not much should change. You can formalize more things, but at this stage keeping your team engaged is probably more important than adding a bunch of processes.

- Check ins. - Clear goals, and task ownership. - Why do you need an office space?

[hapanin]

For sure. I'm a fan of organic culture and process but if something is not working it often takes someone to fix it.

Office space is because the new guy specifically needs somewhere outside of home to be productive. It's one wework hot desk between the three of us.

[apotheosis-neko]

Makes sense! Keep up the good work!! I think as the other poster said, business results are #1 internal processes #2.

[hapanin]

Definitely. I'd be asking about product and algorithms if I thought I'd get a good answer here but alas those I have to do myself.

[muzani]

Overengineering is harder to fix than underengineering.

The startup I'm in is at 5 people, not including managers. We didn't use Trello or Slack, but after enough nagging from the CEO, we did. It's easy to fix.

We still don't have daily stand ups or 1-on-1s. The team is small enough that we're synced, and a good PM can usually keep up. A small team can often move faster than a big one because of the lack of processes. Don't lose that advantage.

[Jugurtha]

Not all 50% increases are equal. 2 --> 3 isn't much.

> Actual scheduled planning meetings instead of random thoughts about business at the kitchen table

By all means don't go Model U.N. or play house. These random thoughts about business at the kitchen table are some of the most valuable you will ever have. These are collisions that engender sparks. What you can do is write down what has been discussed immediately _after_ it has been discussed to capture that. Don't worry about editing, just dump all you've got and structure after you downloaded your brains. This will be raw material of your marketing, your user stories, and your features. Formal and diligent aren't the same thing.

Attitude:

- Model U.N., also known as playing house, is better avoided.

- CEO, COO, CTO are titles that bow down to getting shit done.

Work:

It is useful to write down things and dump everyone's knowledge.

- Carrying a pen and sketching (projects parts interactions, functionality, interface, etc.)

- Writing the product description as if it existed. Continuously edit for conciseness and clarity

- Meeting users

- A versioned design document describing different parts and how they interact

- Code versioning

- Issue templates for bugs and features to reduce friction to write a good issue: anyone who reads your issue should know what you were talking about and have a preliminary action plan. Writing good issues takes a bit of practice, and templates help in avoiding "blank page" and guide the contributor into writing a good one.

- If you've deployed something to users, having a link setup with your ticketing system so they can write an email and an issue is created can help.

- All bugs or features or ideas go to issues

- Writing unit/integration tests & tracking coverage without becoming a slave

- CI tests. You _should_ get an email if the build fails.

- Modular architecture: you don't have to go crazy and read too much from people who design perfect software that only lives in their mind or Medium posts, but features shouldn't too tied. Plugins that can be added or removed

- Write a short documentation about your very easy to use library and then write the code to make it true

- When you get an idea, write it down and get back to work. Explore later. No Wikipedia effect where you wander too much. It has a time and place

- Documenting code

- Good commit messages with root cause analysis when you fix a bug: assumptions that led to the bug. When you do that, bugs don't become a one off thing and _patterns_ start to emerge which will help you eliminate the problem. In other words, a "family" of bugs becomes clear and then you'll develop a solution that makes such bugs impossible to happen again. Also, write tests for bugs so they don't creep back.

- A versioned wiki (for the project) with a page for all the resources you stumble upon that could help your ship:

  - Book titles, what the book is about, where you heard of it, why it matters and what will it solve

  - Open source tools you can use, where you heard of them, why they're relevant and what they'll solve

  - Libraries, you catch my drift.

  - Video talks that describe an aspect of one of your problems

  - Blog posts that describe solutions to parts of your problem

  - Research papers you might want to implement

- A versioned handbook (for the company) on how to do things split in cross referenced themes (Markdown):

  - Technical:

    - Onboarding document - one page -: describing workflow, stack, books to read. Won't need it now.

    - How you set up a certain software stack

    - Mini tutorials on a tool/library you played with on the week-end to get someone started

    - How you use a certain API

  - Paperwork (anyone who reads this should be able to operate the company):

    - What are the things to take care of (weekly/monthly/quarterly) like bank, IRS, etc.

    - Company information (bank accounts if any, legal documents, etc.)

    - Necessary employees information

    - How to pay taxes, step by step, form by form, with images and where to sign and where to pay

    - How to convert from WA LLC to a Delaware C Corp

    - How to setup a WA LLC

These things will help you speed up your work, make it consistent, and help get an additional member up to speed really fast.