For growing startups it is crucial to build and scale high-performing tech teams that can deliver scalable and reliable software solutions.
At Stryber, we launched many startups over the years and thus went through the same challenge:
- To build dedicated (= no freelancers but in-house hires) and high-performing tech teams for our startups from day 1, and
- to be able to set up and grow those teams super fast.
In the following I will share exactly how we achieved that, and why we chose a near-shoring strategy for it.
Strategy
Initially we needed to decide on our overall strategy. Tech leaders can typically choose between the following 5 options:
- to work with an agency
- to work with freelancers
- to hire talent in their own country
- to hire talent from abroad and relocating them
- to outsource (offshoring or near-shoring)
Let’s evaluate all options briefly:
- Working with an agency: At first this might be a tempting idea as it would allow us to immediately start writing the first line of code. For a certain independent project this might be fine, too. However, as we planned to build a team and strategy for the long-term, we considered:
- Agencies are rarely as committed to our projects like our own workforce is
- In case we would plan to just work with an agency initially to get our projects started and later switch to our own internal team, the initial 2–3 months we could start faster compared to hiring our own developers could become a bottleneck later on: code and infrastructure migrations, code our new team wants/needs to refactor, or we could be “forced” to stick to the chosen tech stack of the agency, etc.
- Working with freelancers: Composing a team of individuals who might not know each other, live at different places and work on several projects in parallel? Why not. Providers like MVP Match are offering this and it can be a good and fast solution, but for us it was not in line with our ‘in-house team’ principle.
- Hiring talent in our home base: As we were located in Germany and Switzerland, hiring a large local tech team (5+) fast was unrealistic, especially without using headhunting services. Of course it would have been awesome to have our tech team in the same office, but the reality is: talent is rare, the hiring market is competitive, and hiring cycles are long.
- Hiring talent from abroad and relocating them: Relocating people from tech talent hubspots like India could do the job, but we might run into cultural issues and have lots of administration to handle, which we don’t have time for as a startup.
- Offshoring: To hire our team in countries known for a large pool of tech talent, such as India, is a common strategy if we wanted to keep tech costs low and our tasks tend to be routine, e.g. maintenance. For building innovative startup solutions, however, this option is probably not be the best to build our core tech team with (just as team extension this option could be valid).
- Near-shoring: Compared to offshoring, this strategy has the advantage of not having huge time differences between our main office and tech team, as it targets countries in Eastern Europe or Spanish regions mainly (for European companies). However, there would be no significant cost savings compared to hiring in a country like Germany.
Choosing the right strategy depended a lot on our hiring principles and what capabilities we already had inside our organization. We wanted to build a team which is fully integrated into our company, and we had a CTO in-house. Thus, we decided to nearshore, which is basically the fastest option to build a dedicated tech team.
Having our own CTO in-house was vital for choosing a near-shoring strategy: While near-shoring allowed us to hire much faster than in our home base Germany/Switzerland, we made sure we had technical architects and leads in our core organization that ensured the code written by our near-shoring teams is scalable, reliable, and secure. Outsourcing key topics like defining a state-of-the-art tech architecture, defining deployment and testing guidelines, or defining coding standards is from my experience rarely a good idea.