Interview with the CEO of DeckRobot, Anton Urbanas

An interview with the CEO of the company responsible for the first AI-engine for creating presentations talking about his team scattered across different continents and time zones. It turns out that for DeckRobot this is not a difficulty, but a solid advantage: with no fear of any tsunami or Trump, and the work is carried out 24/7.

Anton Urbanas worked in consulting for 7 years, making thousands of slides, until one day he decided that spending his life moving text blocks in PowerPoint was not the best idea. Understanding the pain of millions of employees of large corporations, in 2017, Anton created DeckRobot — the world's first AI engine for the design and formatting of complex presentation slides.

The company is based in San Francisco, with three other offices in Kiev (Ukraine), London (UK), and Makati (Philippines). Anton has already written about the launch of his startup, from the ground floor of an idea to an international b-2-b company, however we had a chance to ask him about what is interesting to us, as evangelists of remote work — about creating a team scattered across different continents and time zones. It turned out that for DeckRobot this is not a difficulty, but a solid advantage: there's no fear of any tsunamis or Trump's decisions, as well as 24/7 development.

— Anton, tell us about your team. How many of you are there now?

— We are not able to speak about how many people are in the team and who does what, because we are in the process of closing the second round of investments and the picture will change greatly. But, I can say that the team is engineering, the main part of it is ML-engineers, and we have very few sales, for example. We are represented in the USA, Ukraine, the Philippines, and the UK.

— How did you come to the decision to assemble a team outside the States, and even in multiple countries? What was the main motivation? Was it the tough competition for developers in the States? Or reducing the cost of specialists?

— When it comes to Machine Learning and Data Science, competing in the Valley is not just difficult, but impossible. That was the main motivation. As for the cost of specialists, 10 mediocre, cheap pianists aren't better than an expensive and talented one; it's not primarily about savings. In the Valley, hiring IT-professionals is extremely difficult. It's not easy for Google, let alone a startup. A common story: a project from another state or country attracts a lot of investment, and then, six months later, can not hire specialists in the Valley and eventually fiddles with the idea of relocation.

In addition, we wanted to build a team that would function in different time zones. Our customers are also scattered around the world, and we want to ensure that they do not have to wait for product support. Having teams in different zones allows development to work almost 24/7.

For example, when it's late evening in San Francisco, we discuss with the team in Ukraine what needs to be done while they are just starting their working day there. By this time, the Philippine team has already been working half a day, and they have something to show.

So, by the morning of the next day, we already have updates on the development progress. Thanks to this, we can do customization for the client or a product update quickly, because there are even fewer days off at the company scale — there is one more working day due to the difference in time zones.

— What you're saying is, different time zones, one of the main difficulties for companies venturing to distributed teams, in your case turns out to be a huge advantage. What other advantages have you learned from your choice?

— As we hire developers in three countries, we have a large pool of talent, and the company is also protected from many risks, such as the reduction of work visas in the United States. And, even if there is a tsunami in the Philippines and no electricity for a week, the processes in the company will not stop.

Because of the holidays, there is the off-season In the United States from late November to early January: everyone goes on vacation. If you want to run a new feature-there will be no one to work on it. However, with a distributed team, you can balance the load and avoid such failure periods.

The code review is perfectly integrated into the scheme of the work of distributed teams. You do the work, go to bed, meanwhile your colleague is starting their work day, so in the morning you will see the results of the review. The same with QA. The production circle does not shift, because when the tester comes to work, a piece of code that needs to be tested is already waiting for them.

— And how do you manage to both synchronize everyone and ensure that one team can work independently of the other, which is sleeping?

— First, there are still overlaps in time between offices in different countries. And we try to distribute tasks across different teams so that some processes do not need to wait for actions from other people who have already gone to sleep. We seem to have learned to deal with this without losing development speed and quality. This is an organizational challenge, but if you do not synchronize, of course, there will be a mess.

— You're talking about a large pool of developers, which opened for you, regarding the organization of processes that allow development to work 24/7. But nevertheless, you abandoned the idea of a fully distributed team around the world and opened offices in Ukraine and the Philippines. Is this not a restriction on yourself?

— We stopped at the offices because independent developers with remote work experience, who have learned to negotiate with themselves and get up in the morning on time — is not too common, to look for such employees is like setting the criterion of "blue-eyed, one-legged, brunette, two meters tall". You can, of course, look for such a lone samurai, but for what? (there is no filter on eye color yet, but lone samurais are available to be found and selected on 6nomads.com — 6nomads' note)

For the same reason we made changes after we initially looked only for English speaking professionals. We realized that by using this qualifier we cut off a huge number of talented engineers. Then, we just hired tutors for these hires. Since all the communication in Slack and most of the verbal communication is in English, even those who had a zero level built up their level in just a couple of months.

You can put any artificial restrictions on hiring, but it makes sense to think about the pros and cons of each of them. It's necessary to understand that there are many engineers in the world, but there are few engineers who you can use that have both the skill set required as well as an interest in your tasks.This is already a pretty harsh filter.

We also think it's important that people fit into our company culture. We have a lot of independence, almost no bosses, a flat structure. Not everyone likes this style and not everyone fits. But, in our opinion, only at organizations with such freedoms do specialists quickly solve problems, avoid pushing off responsibility onto "the administration", and act without waiting for a command from anybody. This point is very important for us and we are ready to narrow the funnel for such a filter.

Having two specified cities for developer teams doesn't limit us so much, they are convenient hubs for talent: developers are ready to move to Kiev from all over Ukraine, from Belarus, and often from Russia. It's not as complicated as relocating to California. The same goes for the Philippines, which is a convenient hub for all of Southeast Asia.

It makes no sense for us to look for talent in Western Europe: the pool of specialists there is not as competitive as in Eastern Europe or California. In terms of recruitment, California is very expensive and very good, Eastern Europe is not so expensive but very good, and Western Europe is both expensive and not very good, plus there are a lot of bureaucratic difficulties with hiring.

— Tell us how you built the process of attracting, selecting, hiring? What mistakes did you make, what conclusions did you draw?

— We have had many stages of evolution, made many mistakes, even used outsourcing, until we realized that there is no case where outsourcing is a good choice. Then we tried outstaffing, it was also expensive and ineffective, not enough motivation. Then we turned to recruiters, but there were many questions about the recruitment process and the quality of candidates who came from them.

As a result, we came to hiring specialists by ourselves: we use open resources where you can place a vacancy. People respond, we select them, we devote a lot of time to this process. More and more specialists come to us by recommendation. Creating a reputation in the market takes time, but it needs to be done.

We do not communicate with candidates without a test task. I know that many people are against that and developers do not like doing tests, but for us, it is a clear criterion. That's how we objectify hiring. A good University, experience, and other resume bullet points often mean nothing.

We had a candidate with a very weak CV, without any education in Computer Science, from a region where the last thing you think about is looking for a strong engineer. If we had started by looking at his resume, we would have found it pointless to waste time. But, since we started with a test task, we immediately had a very good impression of the candidate. At first, he worked with us remotely, and then we helped him move. This employee brought a lot to the team, and we could have missed out on him with the classic hiring process.

Google in many areas, too, refuses to look at CV's and hires based on the results of a test.

— Was it easy to attract strong specialists to your project?

— We are changing what has been working poorly for the last 30 years. There are half a billion PowerPoint users from around the world who agonize with creating presentations almost every day. There are a huge number of man-hours, which we can influence, and, already strongly influence. There is a lot of potential in this; the product has a wow-effect.

Screening for the purpose of candidates occurs at the same stage we get a response to the vacancy. If candidates want to save a rare species of hares from extinction, they simply do not respond to the vacancy and do not engage in PowerPoint slides.

— Despite the office culture appearance, how "free" are your employees? And how did you learn to maintain a balance of freedom and control?

— We try to minimize restrictions, the schedule for employees is relatively free. Yes, it is necessary to attend the calls, but someone can do it from home.

Only culture, maturity, and motivation allow for maintaining a balance of freedom and organization in the company. We make it possible for all the people in the company to grow quickly: there is not a single engineer who has worked at least a year without a salary increase, with the area of responsibility improving at the same time, of course.

In this culture, it's very simple to take notice of the people, who lag behind and work at half strength, or those who abuse the freedom. We detect such situations at once and burn them with fire.

— And how do you establish high-quality employee interaction with employees from completely different cultures? Does it create its own difficulties?

— For people from different countries to successfully collaborate with each other, you need to have a common culture within the company that connects them all. But, it is also impossible not to consider features of mentality, especially in distributed teams, if you want to be able to understand the look of work correctly and to put tasks properly.

For example, it will be difficult for specialists in the Philippines and the States if you give them an abstract description of the tasks. Guys from Eastern Europe tend to give the most optimistic timelines, can easily work on the weekend, and do not see a big disaster if a deadline is missed by a couple of days or weeks. American colleagues can be shocked by a request to work on the weekend, but they are more scrupulous about the timing.

— What was the main discovery for you personally? What did you not suspect when you ventured into the organization of a distributed team?

— The main insight is the importance of culture. It seems that the culture and values dictate the things that the whole HR departments of large companies do. HR just has nothing to do. But this is super important to know about culture and values, it determines productivity, especially for a distributed team.

We tried to make a pyramidal structure with the project managers, team leads, etc, but it worked poorly. And when we chose a flat structure and realized the importance of culture in the team, productivity grew incredibly. In two weeks, we do more than what we used to in two months. Despite the fact that the developers have remained the same.

Many professional investors say: how you work the first couple of years will determine the whole direction forward. And it's true.