One of the most common killers of early-stage startups today, besides not managing financial risks properly, is not understanding how to properly scale a development team. Funded founders generally take the “throwing more money at the problem“ approach and start hiring like crazy. This can potentially hurt a startup in multiple ways.
Here are four things to keep in mind that can help out:
CTO
CTO, chief technology officer, is a pretty popular title in the startup world today. Founders generally come in pairs of two developers; one technical developer and the other, a business developer. Both roles are crucial to the success of the company. Once the product has been validated in the market, growth happens, and with it, the development team grows.
Having a CTO that has been around the block a couple of times and scaled a dev team before will save you and your company a lot of time and money. She/he will usually be able to think a couple of steps ahead in terms of people and their skills. Now, a lot of startups are made up of first-time leaders that have not scaled teams before. That’s fine; however, I would highly suggest finding an advisor that has scaled a team before.
Hire People That Know Your Tech Stack
Try to hire engineers who know your technology stack. Now, this might sound obvious, but far too many times I’ve watched founders hiring engineers for the sake of hiring them since the pressure of building and shipping features is high. Suppress the urge to hire a C# developer if you have a Ruby stack.
Culture
Be aware of culture. As soon as you add an engineer to a team, and the team is now made up of five people, you inevitably have to be compatible on a cultural level to make it all work. A little trick that has worked well for me before, was to have a potential hire spend a week or two just hanging around the team and having fun.
It’s a great sign if everybody is able to connect, collaborate, and function with one other without friction.
Single Gatekeeper Syndrome
When a business is growing and scaling, it usually has one or two technical people that are in charge of tech. That’s completely fine at the start, but once you have 10 plus developers on the team, having one or two people in charge of the final code review and deployment becomes an issue. If only one to two people have to review code every single time it needs to be deployed, it can get fairly slow. It’s hard to give the “keys” to other developers, but you need to trust that they will do exceptional work. It doesn’t mean there won’t be code reviews, it just means that anybody could make a final decision that feature is good enough for deployment.
