I happened to work with a lot of earlier-stage startups recently. It seems clear that a major cause of issues for tech executives at these companies revolves around the initial steps to “scale” the team. For some reason, even experienced founders make mistakes in installing the company’s first managers. Especially given the current market climate, you don’t have time or runway to waste. Here are some typical pitfalls for you to avoid.

Sometimes, you shouldn’t promote anyone to management. I don’t think I’ve ever come across a company where the founders didn’t strongly prefer to “promote someone organically” from the team. I get that. After all, working with someone should give you more confidence about cultural fit and the advantages of a manager with a deeper relationship with the product. Nevertheless, the vast majority of first-hires tend to be chosen for their technical skills and not their managerial background. Whenever I see founders decide to put a first-timer in charge of their R&D—the most important and costly department—I think it is needlessly deciding to play on hard mode.

I’m not saying you should never promote someone based on potential. You can do that, given that you are very aware of the need for extra coaching and mentoring for this to succeed. And it just might make sense to wait for the second manager to do so.

Creating hierarchy too early is stupid. So many founders think they must create a hierarchy fast to free up their time (to do what, exactly? But that’s for a different article). When done prematurely, it ends up with a company with a high manager-to-employee ratio. In the early stages, founders have to remain very connected with what’s happening. Doing so is hard with an extra level of abstraction. You’ll naturally want to give your manager room so you won’t be micro-managing or undermining their authority. It is better to wait till the team justifies it. My rule of thumb is that the first manager should be in charge of at least five people.

Avoid contorting the organization to accommodate the first promotions. We’ve all seen startups where, at the point of creating the first teams, one of the first employees gets promoted, and then there’s the problem of taking care of the other founding team members. When you create a team but still manage a couple of those first employees because they need to feel special, you’re often creating a sick organizational structure. Do you have to manage them when it comes to daily tasks? Are they part of the sprint or not? Who’s accountable for their personal growth? As hard as it is, don’t do this merely to retain talent. If people still report to you, it should only be as a temporary measure before creating yet another team down the road, and that should be clear to everyone involved.

Similarly, avoid creating too many teams to placate your first employees. There are startups around that haven’t even completed their MVP yet but felt it was essential to have two team leads, each in charge of 2-3 people. That’s an insane manager-to-coder ratio that feels more like a few young boys playing in the sandbox and deciding who’s “the commander,” not like a real business.

Lastly, create viable teams. You can help your managers succeed by ensuring that the teams you hand them are self-sustainable and are in charge of an area with long-term significance. Self-sustainability refers to setting up teams that are as end-to-end as possible. Otherwise, the team will be dependent on others to accomplish most of its tasks, which can critically harm efficiency. A long-term horizon for a team means that it is not in charge of something likely to change completely within a quarter. For example, spinning up a team to handle a specific client’s POC is not usually the right “theme” for a team.

I recommend creating teams around business aspects that are known to always be relevant or end-to-end teams that then get assigned different objectives every quarter. The alternatives are to keep shuffling people back and forth between teams or have teams focus on things that are not the top priorities. Both are not good ideas, especially during a startup’s formative years.