Ask HN: Build in-house engineering team or keep it remote?

Interested in your perspective on this. We currently have a ten person overseas engineering team: SCRUM master, technical architect, QA engineer, FE engineer, and backend engineers.

I'm facing an organizational decision about whether or not to start building an in-house team. I'm looking for guidance on the following aspects of the problem

1. Division of labor between in-house and remote: If we do go in this direction, how would you recommend apportioning the work? Would you recommend a separate SCRUM master for an in person team? What if that team was only a couple of people?

2. Incremental or All at Once: One option would be to do this incrementally, and hire a couple of people in-house. Another would be to wait until we have a budget available to fully transition the development of our product to an in-house team. This would likely take some time (a year or more?), as hiring in-house for the talent needed would likely cost 3x our current budget.

3. Floor Engineering Size: From a morale perspective, I'm wondering if it would be valuable to start with a minimum amount of technical talent. E.g., one engineer and one designer.

4. Starting Talent: Curious if you all have thoughts about starting w/ a lead engineer/tech arch type vs someone who's more of a solid contributor. I recognize this decision is heavily influenced by what they're working on.

Current thoughts on how to move forward: 1. Hire a smallish team internally: 1 FE eng, 1 BE eng, maybe 1 designer 2. Focus in-house team on new feature development 3. Focus remote team on QA and product optimization 4. Pay for in-house team through additional budget I'm getting in 2019 and by cutting into the remote team's budget a bit

Would love yall's reaction and advice.

1. I believe you should focus on finding the most talented people no matter where they are. Pre-planning a division of labor ignores an organic movement to the way that the team works best together.

2. Always incrementally. Theres a reason we develop this way now.

3. See above.

4. Let people grow into their level of responsibility. Leaders lead first and then pick up things like titles, raises, etc

So here's my $0.02: Having talented hardworking people that work well together is a priority over where they reside. In the most recent Stack overflow survey the top perk that Devs would like is Remote opportunities - so I would consider "in-house" to be a hinderance more than a benefit for the business. Additionally, (inferring here) you already have a system that works well for remote work, meaning there is no additional overhead to keeping the system the way it currently exists

From a management standpoint you always want to incrementally grow responsibilities, and grow your team. Ask any high growth company that has to hire fast. A lot of mistakes are made in hiring when you have to hire, or when you have to give responsibilities away to soon. Reducing these mistakes goes straight to the bottom line. Leaders emerge naturally and they will be better at leading the team if you allow them to emerge naturally. Additionally the number one reason that people leave a job is a bad boss (https://www.linkedin.com/pulse/employees-dont-leave-companie...) so handing it over to a Lead/ Architect type before they prove themselves is a dangerous proposal.

On the flip side you seem to be giving these things thought... so a feather in your cap for being conservative, and waiting to pick a strategy.

My closing thought => your priority should be to find the single best person that you've ever worked with or ever will, hire them first and now... and if you are able to do that... then the next person you hire should be even better than that person.