Increasingly, I've become sceptical of businesses looking to "rapidly scale" their technical teams. All businesses seem to get a certain amount in their backlog, or an urgent request from a large would-be customer, or just too much money and decided that the only solution is to hire at a tremendous scale.
I'm going to argue that perhaps you don't need to hire at all. And doing so would be counter productive.
Why startups need to hire
Hiring is driven by demand for product features. Shareholders within the business get requests for certain things. "Can we add this quickly?", "I need this urgently for X", "Our competitor has Y so we need Y". These are all common phrases that I'm sure we've all heard. These requests are understandable. These shareholders are trying to do their job by making the company (and by-proxy the product) more profitable. I don't blame them for these requests. But, they stem from an environment of their own making.
These businesses start, like many, with few resources. They build an MVP, sell it to a few customers and start to make money.
But they have a problem - they want to grow, and don't have the money to hire a full time team. So, they get funding. That funding puts them into 6th gear.
Because they are now at the mercy of investors, they need to get more customers, which means more features, which means more developers.
And more developers means they need more money. So, they raise more money and agree to add more features to get customers. And on and on.
Unfortunately, this cycle never stops.
So what's so bad about this?
The cycle I've described above is what some would call "growing a business". Whilst that might be largely true, it's not the only solution. One problem with this approach is hiring.
Hiring is viewed as a task that can simply be checked off. Recruitment agencies can help you feel like this. But the fact is that hiring is extremely difficult and time consuming. From initial resume review, to interview, to code challenge, whatever your recruitment process, it takes time on your part.
And after the contracts are signed, the process isn't over. You've got to onboard, educate and give a lead time before those developers get productive (in my experience, even the most senior developers aren't truly productive until at least 2 months after starting).
The silent killer
The silent killer of many of these business is they start creating work for the sake of it.
When a carpenter creates a chair, they skilfully sculpt the wood, attach the parts together and sand, oil and paint it before declaring it finally finished. Software is similar, but we miss the finish. How many pieces of software have you worked on where it was declared "finished"?
In hiring a huge army of developers, eventually these features from customer peter out. What then fills the void is an endless game of optimizations, minor pivots of existing features and "reckons" about things people think are good ideas (without validating them). Evernote and Dropbox are classic examples of this at play. They created a great piece of software, but continue to annoy its customers and create meaningless changes that get killed. Without the pressure of continuous growth, it would be more acceptable to put software into "maintenance mode".
The Alternative(s)
Increasingly, "indie makers" are building out products in their spare time and waiting for them to become profitable before making the leap full time (or hiring staff). This means there is not the huge impetus to continue growing at all costs.
Others, in the wake of the pandemic, are building out remote, part-time teams. Gumroad has done this to great success after suffering from many of the failings described above.
In another case, I had a non-technical founder approach me to build out an MVP for him. He was a reasonable chap, had a savings pot to pay me, a specific scope and a clear market. But, rather than investing all that money, I advised him to build out a prototype using Nocode tools like Bubble and Webflow. Even if you are not technical, the barriers to entry for building products is lower than ever.
These approaches are not foolproof, they have their own issues. For example, for many products, it isn't possible to "build it in your spare time". Still others may not have spare time to build a product in. But, don't be afraid to break the mould and do things the non-traditional way. Think of creative solutions to the problems you have. Resist the rush to build lots of new features, seek to please customers at all costs, and compromise your product. Your product and customers will thank you.
In summary:
- Relax your requirements about the pace of work. It will lead to better quality product as a result.
- Don't get sucked into the investment strategy grind. You'll eventually have an army of developers with nothing to do.
- Seek alternative solutions. The barriers to create are lower than ever, use Nocode tools or build the project on the side.