Interview: Unomy’s CTO on how to run an effective offshore development team

Unomy is a unique sales and marketing intelligence platform which allows its users to create comprehensive lists of targeted prospects, use valuable business information to enrich their leads, and keep track of companies they care about.

When I joined, Unomy had already developed an alpha product that was good enough to show investors, and my main task was to build a tech team that could further develop our software.

I started with the analysis of how the product functioned and what we had to add to it. Based on our budget, it was clear that looking for local talent didn’t make sense as the salaries of Israeli developers with the level of big data expertise we required were way beyond our means.

We decided to look for tech talent in Ukraine since we knew that we’d be able to find the right people much faster there and that the salaries of Ukrainian developers were approximately twice lower than those of local specialists.

We also knew that a partnership with a company like Grid Dynamics Team Augmentation (former Grid Dynamics) would allow us to save on workstation setup, parking space, insurance, and other administrative expenses related to hiring a new employee in Israel.

I had a clear vision of the product architecture in mind so I knew exactly what skills our first candidate had to have. I made a list of requirements and contacted about 20 Ukrainian companies that provided custom recruitment services as well as further team support.

Some of them reached back, some didn’t. I interviewed a lot of developers until I finally met Vladimir through Grid Dynamics. He had just the type of experience I’d been looking for, and I was very happy to have found him. We said no to all the other companies and signed a contract with Grid Dynamics.

From then on, we’ve added new people to our offshore team only through Grid Dynamics Team Augmentation (former Grid Dynamics), and I think we’ve got a great partnership.

I’d say 30 to 60 minutes are enough for me to figure out if the person is going to be a good fit for the job.

I always give candidates code writing tasks to understand their coding style and way of thinking. I use a number of small tasks that might seem somewhat simple, but they do a pretty good job at revealing the level of that developer’s expertise.

I invite my candidates to a collaborative online code editor and watch them solve these tasks. Once they’re done, I ask them to change something in their code or think about how they could improve it, and see how they react to that. I want to know how well they understand what I need them to do, so it’s a communication test as much as a coding test. After that, I usually move on to the architectural and algorithmic plane.

As a startup, we need people whose knowledge we can fully trust. We can’t afford to hire someone capable of a mistake that could seriously undermine our progress.

Viktor, our Senior Python Developer, left us a few months after he’d joined because we didn’t exactly meet his expectations. He thought he’d have more opportunities for professional development through working with new technologies. Unfortunately, at the time, we couldn’t provide him with those opportunities.

A couple of months later, Oleksii (Unomy’s HR/Account Manager at Grid Dynamics) told me that Viktor was available again. I knew how difficult it was to find a specialist of his level, and he was already familiar with our code and our architecture, so I decided to coax him back and promise that he’d get a chance to work with the tech he wanted. I’m happy he’s back on the team now.

We follow the Agile methodology, but it’s more the feel of Agile that we stick to than the exact procedures. We do daily stand-up meetings and try to keep our sprints within two weeks.

Communication is key to running a remote team – you have to understand what’s going on on the other side.

My team and I call each other multiple times per day. The daily standup meeting keeps everyone on the same page, and then during the day we do one-on-one calls to discuss smaller technical questions. I find that talking things through works much better than typing endless messages.

You can’t expect a high quality product if this ongoing communication isn’t there, which is exactly why project outsourcing often doesn’t work out that well.

And it’s not just about the product quality. The more you communicate with your team, the better you get at sensing their moods and expectations, and the faster you deal with their concerns. This is very important to us because I literally handpicked each member of the team and I wouldn’t want to lose any of them.

Oleksii helps me a lot when it comes to sustaining a healthy working relationship with the team. Being in the same office with my developers, he can solve a lot of problems locally, and brings me in only if my involvement is necessary.

We use Jira for issue tracking and project management. As for communication, we used to mostly rely on Skype, but now we’re transitioning to Slack. It’s much more efficient if you use it right.

The first thing to consider is whether you have enough of a technical background to manage the team yourself. Quite often, business owners who hire developers in Ukraine are well-versed in large-scale business processes, but they lack the hands-on technical experience enabling them to run the team efficiently.

My technical background has allowed me to manage my developers successfully. Otherwise, I’d seriously consider hiring a team lead who could not only run the team, but also take part in the actual coding.

In fact, we’ve recently added a team lead, Yaroslav, to our team in Ukraine so that I could free up my hands for other things.

Another important thing to keep in mind is that you have to hire independent employees, motivated to work hard without any pressure from your side.

I’ve found that, as a rule, seasoned developers show a much higher level of dedication than their less experienced peers. They’ll stay at work late or work from home just because they’re genuinely invested in the project.

And now that Yaroslav has joined us, I’m sure the team will get even more self-reliant.

First and foremost, it depends on the budget. If the budget doesn’t allow you to hire a high quality specialist, it’s better to keep the team as is. If you hire someone who can’t add much value, the productivity will only drop because other team members will have to spend their working hours teaching the new employee or cleaning up after them instead of focusing on their core functions.

We use our product ourselves and constantly think about new features that could make Unomy better. Our competitors are all large and well-established, which means that whenever they want to add something new to their software, they need to go through countless rounds of red tape before even starting the development process. As a result, the new feature comes out in 6 months at best.

We’re still pretty small, and that’s a huge advantage enabling us to react to customer feedback and add improvements fast.

When we tell people how small our team is, they have a hard time believing us as, normally, it takes two, or even three times more people to achieve as much as we have.