I have found that there are inflection points whenever things double. That could be people, revenue, office space, customers, etc. When this happens, "debt" affects the company. You're probably much more familiar with tech debt, and probably architectural debt. Maybe less familiar with organizational and cultural debt. You simply can't do things the way you always have, they don't scale.
Change is inevitable and required. If not managed, it could sink you. Some people will quit regardless, they were probably not the right people for the next phase. At first you don't need teams (you have 1 team), then you need to have 2 teams, them more. This change is disruptive and affects productivity and morale. Read up on team maturity models (not CMM), it will help knowing what phases you will be going through.
I presented the team maturity models too my devs the last time we restructured the teams. Multiple people came to me proudly stating they were in the "storming" phase, which essentially is when you argue a lot. They knew it was a phase, and frustration was reduced.
You do need leadership as you grow. A leader is not your best developer. The HR manager may scare you because they are a "manager", not a "leader". Good managers and leader can toggle between both roles. Too many people are great managers and not leaders. Know the difference between a manager and leader, know which ones you are missing.
This time around I am purely a leader and the one primarily in charge of tech. My almost exclusive focus from the start is the people. I have to start over on most things that I evolved through previously.
- I've taken on the responsibility to create and define our culture. My last job I assisted in this area.
- Make sure developers have the tools to be productive. This includes reliable wifi, internet, good coffee, software, furniture, TVs for monitoring, AV system for presenting, conference rooms.
- I've had to earn the trust of the existing people. Previously almost everyone was new on my teams and I hired them, so there was largely trust from the beginning.
- there is churn, like you are going through. I had almost no churn on my teams previously that was not purposeful. I have to explain why the churn is ok and expected.
- I have to teach developers to focus first on "why" they are building a feature, rather than "what" they are building and "how". This helps dev and product see eye to eye.
- I have to teach how to interview, run meetings, do agile right, communicate. Focus on building the right things over building things right. Teach people when to be tactical and when to be strategic.
Ultimately, I have to step up and fill the gaps until I can hire and/or train people to assist in that area. Before I had help all along. For example, I've interviewed about 200 candidates in 6 months for many different roles (developer, DBA, sysadmin, product, data). Mainly because interviewing was probably the most important thing I could be doing for the company and the developers.
I'd be happy to go into more detail offline.