How to Manage a Team of 43 Developers in Different Time Zones

In this interview, CTO of Scentbird Andrei Rebrov told us why leaving large, successful companies for the sake of uncertainty could be a good idea, how to attract 43 serious IT specialists to a beauty project and going about organizing the work of a remote team scattered from Belarus to Hong Kong across time zones.

At 6nomads, we help IT talents to get a remote job in the best companies and select interesting projects for their professional growth. We decided to launch a series of interviews with the CEO's and CTO's of international companies about hiring and managing distributed teams to talk about their successful experiences with remote work, although it still remains unpopular.

The first interview with Andrei Rebrov, CTO of Scentbird — a service selling perfume by subscription. This curious New York startup with Russian roots grew from 400 subscribers to 250 thousand and received $24.4 million of investments with 43 employees from nine countries in Scentbird's IT department today.

— Andrei, tell us first about yourself and how you got involved in Scentbird?

— A pretty popular question: how after Aerospace University, did I start pouring perfume samples. The story is simple. I lived in Samara, where I graduated from University with a degree in Applied Mathematics and Computer Science.

In my third year, I started working in IT companies. I worked in Magenta Development, where I dealt with logistics services for taxis in England, collectors in Russia, and trucks in the United States. I was developing, and I really liked it, but I wanted something more.

I've always been lucky, surrounded by smart, talented people, and I was looking for those with whom it would be possible to grow. My first boss introduced me to Habr, the second introduced me to open source and Linux, and I wanted to keep going.

Therefore, when I graduated from University in 2011, I began working in Moscow at Luxoft two weeks later. While there, we dealt with a giant bank named UBS. Again, I was with a good team and project managers.

But, when you work in a big company, you realize that you can be as cool as you want, do cool things, and still, somewhere five levels above you sits another "Director of something", who decides how the product will look in the end. As a result, there is no feeling that you benefit people.

We did corporate-level projects for the bank's employees, so, there was never a goal to make a successful commercial product. This created certain questions; I wanted something different, I wanted to work on a faster team.

I had already become interested in Agile technologies when I was living in Samara. I met the guys from Scrumtrek, they invited me to join their team, said there were two big contracts, and I needed to decide if I was ready or not. I said, "Yes", and I have never regretted it.

When I left Luxoft and joined Scrumtrek, it felt like I got to "Star Wars", like supersonic speed was turned on and I could only see the flashing lights around me. The team was small, all decisions were made very quickly. But, what I liked most was the opportunity to make mistakes that were helping you learn, to understand what was wrong.

We were engaged in consulting, implementation, audits… At one point, I was naturally beginning to get questions like, "If you teach people how to develop software, why don't you do it yourself, start your own startup?" Quite a reasonable question. I began to study what was happening in this arena, incidentally got to the hackathon, the organizer of which turned out to be my future co-founder, Sergey Gusev.

Two months later, he wrote me a letter: "We are looking for a technical founder for our recommendations-based startup that will sell perfumes online. We need a mathematician-programmer who will be able to do both— write the algorithm and support the development."

These were huge options to weigh: on the one hand — a stable job in Moscow, a good salary, the opportunity to become a Junior partner, on the other — an unknown startup in the States about perfume. I chose the latter. I didn't look back.

That was more than five years ago, and since that point, all have been moving forward.

— How fast did you start growing?

— For about a year, we tried to start but had not yet been registered as a legal entity. It was 2013, in 2014, we found an accelerator in New York; we were still just four founders. it took money to hire a team, but there was no money.

The accelerator gave us $40 000. We spent this money very safely for a long time, then received money from our first investor — $100 000. First, we hired one employee for marketing and one for support. We, ourselves, received a minimum wage, just enough to pay for rent and food.

The first developer was hired in December 2015. I found him on a social network through acquaintances. He still works with us. A year later, we hired two more developers. Then, we began to grow rapidly, and now there are 43 people on my IT team.


— Did you hire the first developers for the New York office?

— No, remotely from the beginning. To some extent, this was due to savings, because hiring in the CIS is much cheaper. The second reason is cultural. I needed people, who would understand me quickly, to whom I could say very clearly what I needed, including passing on obscene lexicon for a quick explanation.


— 43 people on the team — and all Russian-speaking?

— Yes, we communicate in Russian on Slack. The whole team is distributed: from Belarus to Hong Kong — 9 countries, 27 cities.

Initially, Slack was used only by developers, but then the whole company switched to this tool, communication speed greatly increased.

The team communicates directly with stakeholders. Now, for example, we are implementing a warehouse management system. I have only one person from New York City on the team — a business analyst. She's in the warehouse now, the team stays connected through Zoom to communicate and help.

— What was the most difficult thing about hiring these people?

— Hiring by itself. I had to communicate a lot, and communication takes a lot of energy, especially if you are an introvert.

More importantly, the hiring process involves a lot of writing communication. You need to understand how people perceive you when reading the text. Only after a long communication with a person can you begin to understand their mood from the way they write.

The most difficult thing about remote communication is feedback. If your staff is nearby, it is easy to go to the person and say: "Sasha, there is something wrong. Let's pay attention to this." In remote communication, you need competent feedback to become a habit.

Now, I give most of the hiring to the team, because I am sure that they understand what the team needs, including communication skills. In this chain, I come at the end, for the final interview, and make an offer.

— What is the stack of your developers?

— Back end development — Groovy/Grails. Quite specific, but we have been able to hire a lot of Java developers, took a lot of guys from enterprise, banks.

Large companies provide the necessary experience, understanding of what processes should take place in the company to make it work steadily. Not as it happens in a startup — wham, bam, and on to production. When there is a business that can quickly give money, you understand what processes are needed.

Front end development (we use React JS) is one of the most difficult to hire for because the stack is very young. It's difficult to find the best practices, people who understand these practices and can justify them while having an adult look at technology.

Specialists often pay attention to one technology, instead of maturing to the understanding that any technology has its pros and cons. Strong specialists own the technology effectively and can always explain one, know what else is on the market, follow that.

We have two people in Data Science and will expand it this year — that trend is heating up. In this direction, it is very difficult to value the skills of candidates, because many know how to make cool algorithms, but the value of the algorithm is worthless until it is tied to a certain business.

So, I test what people think about the business for which they are making algorithms. The specialist has to explain the business problem and the list of metrics, otherwise, it ends up being 'cool' mathematicians that enjoy the algorithms themselves, but do not achieve any profit.

Another specificity is QA. In the market, there are either people who are engaged only in automation or those who are engaged in manual testing. I am fundamentally looking for people who do both: who are used to first getting the user experience, communicating with analysts about requirements, assuming the cases when the user will make a wild combination of steps (because that is exactly what happens in real life, which is why everything breaks) and only then automating all of this. These are testing, Analytics, communication, and development skills at the same time.

Now we are starting to hire mobile developers and the second line of technical support.

— The stack is quite rare. In this case, it is more surprising that you managed to create a long-term effective team. Maybe you have a powerful HR brand or offer mountains of money? What do you attract the candidates with?

— Definitely not HR brand yet. Every time I answer the candidates' question, why do we need so many programmers and what are we still coding, selling perfume online is very simple, they say.

I have to take a close look at our HR brand this year: I will participate in conferences, talk about what we do from an engineering point of view. People are used to contacting with ordering pizza or buying online only as users, but, the backstage, all of that is not visible, yet is insanely interesting.

How do we find people? The market is changing. I really like Daniel Pink's book "Drive: The Surprising Truth About What Motivates Us". He says that for some types of work including development and all creativity, money is a motivator only to a certain level. As soon as people have a financial cushion, other motivators come to the forefront:

1. Autonomy (the ability to make decisions and not dependant on the office or boss).
2. Mission (to belong to something greater).
3. The prospect of becoming an expert.

The market is moving in this direction. Now, it is absolutely real to work from anywhere in the world — there is a technological opportunity for this, but most employers are not psychologically ready, yet.

There are two very illustrative examples. WordPress closed its office in San Francisco, and the team is completely distributed now. There's a great book about this by Scott Berkun, "The Year Without Pants: WordPress.com and the future of work".

The second example, with a large number of remote staff is American Express. That's exactly where the risks of improper communication are huge. They have an office in New York, but if they built an office for all the employees, it would be insanely expensive. Therefore, they decided that it's easier to build a culture of the company so as to be able to work remotely.

Such companies are becoming more and more common. It should be understood that the shortage of programmers in the US alone is a few million — crazy indicators. To look for employees, being limited to one territory, becomes a little silly. Yes, you need to adopt new rules of communication and company building, but it's worth it.

— And how is it organized at your company? How do you manage and interact with the team?

— When I hire people, we agree on the following:

• No matter where they live, it is necessary to work and be online from 10:00 AM to 2:00 PM in New York time. We plan all of our business calls during this time.
• I never keep track of how much the programmer works and how much code they write. There must be visible progress on the tasks and no hanging issues — this is important for me.

If these two simple requirements are met — I am satisfied.

At first, it was just one development team. But there is a rule: the software architecture corresponds to the division into departments within the company. This way the debate about whose tasks go forward is automatically solved. Now there are three teams working on the website.

• The team of fundamental functionality — Core.
• The team that solves problems of marketing for growth — Growth.
• The team that deals with tasks — Retention.

The teams have their own product-owners, they do not conflict for developers, all tasks move forward evenly.

Six months ago I formally appointed tech leads on every team. Formally, because they were de facto the ones who were asked for help or advice. Now, I defer my communication to them, as it is not easy to maintain communication with 43 employees at once. So, the team lead communicates with them, and if the problem can't be solved, I connect.

In companies, the biggest fear of managers is that without their control everything will fall apart. But, in fact, if we build a transparent system of interaction, everyone can immediately see who is working and who is not. Additionally, other people bring it up for discussion anyway. They say, "Sasha, where is the code? The task has been hanging for eight days."

Are there any regulations, rules, or traditions that you try to follow for greater efficiency? Because so far it seems that everything is arranged simply.

Sure. Every Monday we have a general call, where I talk about all updates, what happened last week, and the main goals for each project. Every two weeks on Friday, around 12 o'clock, we organize a town hall: departments talk about their work, for example, to help recently joined colleagues to understand how the warehouse works. Tech leads talk about technical challenges. It is really great to see all the remote members on the screen.

As for traditions, we congratulate employees on their birthday. It's always a pleasure. The last two years for the New year, I sent gifts to the group: our branded products and an individual gift — a book that I choose according to the interests of each member of the team.

In this case, Amazon helps with its fast delivery, but the mail, which often acts illogically, upsets by sending a parcel from New York to Kharkov through Chicago, Luxembourg and Azerbaijan.

— But don't you meet people in person at all?

— I met with the team live once last year, and this year we are planning a big meetup. Last time it was a one-day event, now we will spend a week devoting it to the development of some great functionality.

Some of them came to the New York office, moreover, they meet each other, travel a lot, intersect in different cities.

It's great to meet live. Returning to the question of hiring, one of the tech leads said that if you have nothing to talk about with someone over a glass of beer, it is likely, they will not be interesting for you as a colleague, either.

— And how do you check whether a person is ready for remote work? Were there any candidates that you liked, but knew that remote work didn't fit them?

— I have argued with many people about this, but I always give a test task: to develop some functionality for the back end candidates, to implement pieces of our design for the front-enders.

But, I always give a test with a request for a day to estimate how much time it will take to perform. Then I look at whether a specialist meets the timing or misses, what do they do when time is up, whether they communicate, asks any questions or not. So, the test directly reflects how the person will work.

I often hear that no one does the test task, no one is interested in it, because it takes a lot of time to do it. But, we are looking for people who can be disciplined, solve big problems and make decisions.

Because if you are QA in Novosibirsk, product-owner in New York, and there is a 12 hour time difference between you, at some point you have to make decisions, to be able to justify them and communicate with the owner. If you can't do it at the test level, I'm sorry, we can't work together.

I understand that we have high requirements for candidates. 75% of the team members are seniors, 25% are strong middles. Because it is remote work, because we are a startup that cannot afford time and budget for training employees yet. While training falls on the shoulders of the specialists themselves, they have access to corporate accounts on Udemy and Coursera.

— A lot of what you're saying sounds almost like quotes from "Remote." The book seems to be quite popular, translated into many languages, but why then is remote work still something completely alien and incomprehensible for entrepreneurs?

— First, the book is quite radical, you need to get used to it. Well, once you need to understand that to absorb-copy-wait for everything to work as it should — does not work. We need to adapt everything for ourselves, to a company's culture.

I think it's the mentality, the desire to control everything, but people should be trusted. The situation is changing now, just a little slower than it would be better for the market. Employers do not need to be afraid of remote work at least for one simple reason: you discover a pool of specialists, which is ten or a hundred times more than you have now.

Instead of looking for a developer in San Francisco, which is being chased in addition to you by 25 companies, better to look for them in Chicago, Novosibirsk or Sarajevo. Everywhere is full of talented people: self-taught, experienced, different. Most importantly — they are not worse than those who now sit at Google. Why do you artificially limit yourself by territory? Because you're used to it? Well, that's very strange.