A few weeks ago, I spoke in front of a group of founders of early-stage startups. The conversation centered on the difference between how startups “looked like” during their careers so far and how different things are for them now. What they “learned” earlier seems no longer relevant, given the disappearance of “cheap money.” I told them we are back to saner times where startups needn’t scale up before reaching product-market fit (or at least nearing it). Here are the guidelines I laid out to embrace the grow-slow logic and make the most out of it

Note: Workshop Palooza! I’ve just announced two workshops, the Engineer Excellence Accelerator and the Executive Evolution workshop. Triple impact-per-engineer and become the leader your team deserves. Early bird pricing is available till August 31st.

Set a Reasonable Growth Goal

Gone are the days when startups would bring in a dozen engineers in their first couple of months. I recommend aiming for a more “organic” growth rate of about one engineer per month—amortized. That means that you might hire a few at a time, but over your first 12-18 months, unless business really is booming and you’ve “figured it out,” I wouldn’t attempt to grow any faster. Sometimes, even that would be too much.

This rate makes it easier to focus on bringing in high-quality people, investing in their onboarding, and letting the team gel. Furthermore, when a company is focused on growth, founders and executives often find themselves spending 50% of their time in interviews and meetings. Getting all that time back means you’ll be able to move faster and reach the point where faster growth makes sense.

Don’t Rush Forming Teams

I’ve seen my fair share of startups with 2-3 micro teams, each with 1-2 engineers. That creates crazy amounts of managerial overhead and makes everything more cumbersome than it should be at an early stage. Many teams keep going in the wrong direction because changing the entire org structure has become a tough move. When you’ve already made someone you really like a team lead, it’s harder to tell them the product direction doesn’t make sense, and there’s no need for a proper team for the time being.

Ideally, teams should have about six people in them. You can allow the team to grow even bigger if they’re more toward the senior end of the spectrum. Considering our previous guideline, you probably won’t need to have another “manager” except yourself before getting to the 9-12 month mark.

Don’t Crown Anyone Prematurely

Relatedly, waiting before bringing in someone to take the VP Engineering responsibility or promising it to someone on your founding team is often better. Unless you vehemently object to managing people or can see how you’ll be able to provide a lot of value elsewhere (but for real, don’t just wave your hands because you’re lazy), you would do better to hold the position yourself for a while.

It will make it easier for you to understand what the role requires in your company and find the right person to replace you when the time comes. It also simplifies things and avoids adding “abstraction layers” before they’re needed. For small companies, having too many managers—especially when they aren’t founders—often reduces the general sense of urgency.

Treat Management as a Profession

When you reach the point where bringing in managers makes sense, remember that management is a proper profession. I don’t object to having first-timers, but they have to be treated as such. That senior engineer you’ve promoted to a manager has spent years and years honing engineering skills. One does not usually spontaneously become adept at management.

That means that you should plan to invest in the growth of your managers and in forming a solid leadership team, or you’ll essentially be attempting to run with sandbags strapped to you. Coach them, spend time learning together, whatever it takes.

Be Scrappy

There are two related situations I see in young teams. One is that we allow everyone to niche down way too early. That way, we end up having engineers who only touch a small subset of the code base or employees with micro-responsibilities that don’t make sense. I likened this to Downton Abbey, where the nobility would have a different servant for each utensil. I don’t think that’s how one creates a strong team.

The second is about the overuse of zero-sum titles. I get that early employees often want titles that show their seniority and allow them to demonstrate their experience. However, when you do something like bequeath one the “Frontend Lead” title and the other the “Backend Lead” responsibility, all of a sudden, there’s not much else to hand out. What’s your third engineer to aspire to?

Plant the Seeds of Impact

Lastly, always keep in mind that your young organization will turn into the foundation of a much larger company. Any early deviation might become costly later on. That’s why it is imperative to provide every single person on the team with product mastery. They have to understand the business, the users, and the market. When you’re small, the business people can answer questions quickly, but as the team grows, that will get harder. When a team learns to work with an impact mindset early on, it usually retains that for much longer and with a smaller effort to maintain it as it grows.

Go forth and grow—slow.