On recruiting a small mobile team

I wanted to write about a situation that I see a lot: small companies starting their mobile team. Naturally, they do it in a similar way they started with their backend team: trying to hire best people possible. However, I think a lot of them don’t realise the potential problems they may face when doing so and what the alternatives might be.

So, let’s talk about those.

Recruiting is hard

We all know recruiting is hard. Experienced programmers get contacted all the time on LinkedIn with yet another offer to switch away from their current job. On conferences every other talk gets “and we’re hiring” thrown in at the end. But it’s especially visible when you’re the one trying to hire a new person for your team.

Recruiting for a small startup is twice as hard. You don’t have a big name that the candidates can use to boost their egos. You don’t have a team of potential colleagues that would provide a nice environment for knowledge sharing. Finally, the budget is probably tight, so you can’t just throw money at the problem and offer a salary significantly higher than the market average.

Recruiting for a mobile team in a small startup is thrice as hard. How big this team usually is? Ideally, a unicorn developer who can code for both the usual platforms and knows enough user experience to help the graphic designer create something nice. If they have a bigger budget, they’d go for one iOS and another Android developer. That’s not an environment for knowledge sharing.

Rare image of an HR representative in search for that Principle Mobile Architect for their startup.

Teams matter

Having a real team instead of a single developer brings a lot of benefits. It’s easier to convince somebody to join a team of peers, then it is to convince them to start a project by themselves with nobody to consult it with.

Debugging is easier when you have somebody to run your ideas by. We’ve all encountered problems that we haven’t seen before, but the chances are — our teammates did and they can help.

When working in a team environment with code reviews and pair-programming it’s much easier to pick up new tools and techniques. We’re constantly exposed to other people’s work, which a lot of times is a great opportunity to learn something new for our own private tool belt.

One last risk of employing a single do-it-all developer is that when they’re switching hats all the time, they tend to learn a lot of different things, but just on a basic level. Such a chaotic environment when somebody is expected to know everything is stressful and doesn’t doesn’t give them time for a deep dive into anything.

Alternative

A lot of founders assume there’s no real alternative to building your own team. And in a lot of cases, they’d be right. I completely agree that if you run a technical company, you need a strong technical in-house team. However, you don’t need every set of skills.

Currently, a typical technical stack for a mobile-first product covers a lot of specialties. You need backend developers, to handle your data and APIs, you need operations to keep your servers up (or handle your “serverless” infrastructure), you need web developers to create the web face of your business (along with any special landing pages that your marketing department might need) and finally you need mobile devs to create the application(s). That’s a lot of different hats to wear, you might want to outsource some of that.

In my experience, the easiest one would be the mobile development. Not only there’s a lot of different experience needed there, but also all the other parts are pretty tightly coupled together.

Advantages

It’s much easier to hire a company to help you out than it is too hire a unicorn developer. Of course, you’ll still need to vet them, because you’ll be trusting them with a vital piece of your infrastructure, but that’s a normal hiring thing to do. You need to have confidence in such an important partner for your business.

You don’t just buy a developer, you get access to a whole team of different specialists. Even if you just get one person working on your project, you can be sure that whenever they’re stuck they’ll ask their colleagues for help. That’s a much better position than when your only colleague is Stack Overflow.

Depending on where you’re based, it might be more cost-effective. If you’re in Switzerland, or San Francisco, finding a local developer will probably cost you much more than offloading this effort to a remote team.

Disadvantages

The first one is obvious, you’re trusting somebody else with a vital part of your company. That is completely true and a valid concern. Keep in mind, though, that when the alternative is hiring a single developer to do the job, it’s not really that much different, is it? You’re still hanging on this one thread.

Usually, companies are more reliable partners. They can provide you substitute developers in case of prolonged illness, or holidays. They standardise their codebase, so that different developers can easily pick up the code, they write documentation, etc. That’s rarely a priority for in-house employees.

Amount of documentation written when it’s not a number one priority.

Another thing is communication, you need to put a bit more effort to keep them in the loop on what’s going on inside your company. They need to know what your strategy and plans are to make sure what they’re building aligns with what you want. In practise it just means you’ll need regular planning sessions — like the agile backlog grooming or sprint planning meetings — and that’s it.

Finally, the remote thing. You might be used to having everybody in-house and being able just to come to somebody’s desk to discuss things. With help from outside it’s not possible anymore. But that doesn’t have to be a bad thing — running a project asynchronously leads to better infrastructure documentation (because you can’t rely on just asking at will) and code that’s more obvious (because it has to pass a remote code review). Usually, all it takes is a little more planning upfront and some over-communication and everything runs smoothly. A lot of (even in-house) projects would benefit from some more structure.

Conclusion

So, summing up the whole thing:

• If you only want to hire one or two mobile developers and have them working solo on their applications, you’ll find yourself in trouble that you might not expect. Knowledge sharing, single point off failure, making technical decisions — they all are a problem when you have de facto a solo developer, not a team.
• Instead of keeping a tiny in-house team you might hire an outside team to do this work instead. They’ll come with established standards and workflows, shared knowledge, documentation patterns, etc.
• Make sure you hire somebody you can trust, communicate with clearly and plan what exactly you want to achieve.