
Ask HN: Startup grew from 2 to 3 people. What should CEO be paying attention to? - hapanin
CEO of a basement ML&#x2F;hardware company. My CTO&#x2F;brother is primarily on algorithm and firmware right now and we just brought on a long time friend and occasional coworker as COO &#x2F; product lead. I fill all over the place. So far things have been going fine, but they&#x27;re fine until they&#x27;re not and I&#x27;d like to know what you all have had to do when your team grew by 50% overnight. Some things we&#x27;ve had to change already are:<p>&gt; Use actual task tracking software instead of personal to-do lists<p>&gt; Actual scheduled planning meetings instead of random thoughts about business at the kitchen table<p>&gt; Converting to a Delaware C Corp instead of WA LLC<p>&gt; Compiling a list of mentors, advisors, and other network connections<p>&gt; Daily standup (5 minute)<p>&gt; Actual office space<p>&gt; Deliberate company culture initiatives instead of decades of established family values<p>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.

