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

Just a semi-warning: be wary of falling into a &quot;well, we&#x27;re at stage X, so now we have to do the <i>things you&#x27;re supposed to do</i>. Most of the stuff you listed sounds reasonable and warranted, but it&#x27;s very easy for &quot;we needed to some basic office space&quot; to turn into &quot;we needed fancy chairs, an espresso machine, and a foosball table.&quot; Remember that you&#x27;re still just a 3-person startup, even if you technically increased staff by 50%.<p>An analog in personal life would be &quot;I&#x27;m 35, I&#x27;ve been dating the same guy&#x2F;gal for 5 years, so I should get married and have kids, because <i>that&#x27;s what you&#x27;re supposed to do.</i>&quot;

&quot;team grew by 50% overnight&quot;<p>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&#x2F;entrepreneurial ambitions even though he is really really good at what he does.<p>I would say don&#x27;t over think this. Yes, you will ultimately need more systems&#x2F;process&#x2F;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.<p>I highly recommend getting some type of office space asap even if co=working&#x2F;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.

You&#x27;re doing fine. Writing down all communications is a solid step. Don&#x27;t get caught up in process this early because you&#x27;re going to burn up valuable time and effort.<p>Worry about your customers, your product and the end goal, whatever that is for the ML&#x2F;hardware you&#x27;re making. Make sure everybody understands that and things will work out until you get to &gt;10 people.<p>Also remember that culture is something that grows bottom up. You don&#x27;t set it by decree, rather it&#x27;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.

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.<p>- Check ins. - Clear goals, and task ownership. - Why do you need an office space?

Overengineering is harder to fix than underengineering.<p>The startup I&#x27;m in is at 5 people, not including managers. We didn&#x27;t use Trello or Slack, but after enough nagging from the CEO, we did. It&#x27;s easy to fix.<p>We still don&#x27;t have daily stand ups or 1-on-1s. The team is small enough that we&#x27;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&#x27;t lose that advantage.

Not all 50% increases are equal. 2 --&gt; 3 isn&#x27;t much.<p>&gt; Actual scheduled planning meetings instead of random thoughts about business at the kitchen table<p>By all means don&#x27;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&#x27;t worry about editing, just dump all you&#x27;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&#x27;t the same thing.<p>Attitude:<p>- Model U.N., also known as playing house, is better avoided.<p>- CEO, COO, CTO are titles that bow down to getting shit done.<p>Work:<p>It is useful to write down things and dump everyone&#x27;s knowledge.<p>- Carrying a pen and sketching (projects parts interactions, functionality, interface, etc.)<p>- Writing the product description as if it existed. Continuously edit for conciseness and clarity<p>- Meeting users<p>- A versioned design document describing different parts and how they interact<p>- Code versioning<p>- 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 &quot;blank page&quot; and guide the contributor into writing a good one.<p>- If you&#x27;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.<p>- All bugs or features or ideas go to issues<p>- Writing unit&#x2F;integration tests &amp; tracking coverage without becoming a slave<p>- CI tests. You _should_ get an email if the build fails.<p>- Modular architecture: you don&#x27;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&#x27;t too tied. Plugins that can be added or removed<p>- Write a short documentation about your very easy to use library and then write the code to make it true<p>- 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<p>- Documenting code<p>- Good commit messages with root cause analysis when you fix a bug: assumptions that led to the bug. When you do that, bugs don&#x27;t become a one off thing and _patterns_ start to emerge which will help you eliminate the problem. In other words, a &quot;family&quot; of bugs becomes clear and then you&#x27;ll develop a solution that makes such bugs impossible to happen again. Also, write tests for bugs so they don&#x27;t creep back.<p>- A versioned wiki (for the project) with a page for all the resources you stumble upon that could help your ship:<p><pre><code> - 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&#x27;re relevant and what they&#x27;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 </code></pre> - A versioned handbook (for the company) on how to do things split in cross referenced themes (Markdown):<p><pre><code> - Technical: - Onboarding document - one page -: describing workflow, stack, books to read. Won&#x27;t need it now. - How you set up a certain software stack - Mini tutorials on a tool&#x2F;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&#x2F;monthly&#x2F;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 </code></pre> These things will help you speed up your work, make it consistent, and help get an additional member up to speed really fast.