“There will always have to develop”: an interview with Evgeny Kuvshinov (ManyChat) about development in a startup

We all roughly imagine what development looks like in a large company and how small development can differ from it. But what happens if the size of a company changes rapidly and the number of employees increases tenfold over a couple of years? When a startup grows rapidly, and you need to adapt to new circumstances on the go, how does this affect everything (from processes to technologies)?

In our conference HolyJS company will participate ManyChat , in which just so happens. Therefore, we asked technical support for the development of the frontend of Evgeny Kuvshinov and specifically about ManyChat, and in general about what it is like to do (front-end) development in a startup.

- First, tell us briefly what you do at ManyChat and what the company itself does.

- I came to the company as just a front-end developer, six months later I grew up to the lead of the front-end team. Then we still had such functional teams - front, back, testing, product. And after we rebuilt all of our processes on LeSS, I returned to development, and I had almost no previous organizational tasks. I am engaged in user experience, I try to relate to the product part, partly grow as a product manager, but at the same time constantly write code.

As a company, we help businesses use the relatively new communication channel, Facebook Messenger. ManyChat is a platform for quickly and easily creating chat bots for Messenger. This is not about artificial intelligence, not about attempts to emulate human communication, but about scenarios where this is not required. With the help of our bots you can just do newsletters, and you can set up more complex interactive things like orders, reservations, loyalty programs. They are also done visually and clearly, and this can be done either by a fairly advanced business owner or a marketer without programming skills.

You can see how bots work in Messenger in general, using a specific example: in time for HolyJS, we made a special bot .



- Surely you constantly hear the words "But the chat bots failed a couple of years ago." Does your experience show that, in general, in a certain context, are they quite appropriate?

- Yes. Perhaps most of all, the expediency is proved not even by our case, but by the WeChat platform. This is a messenger that almost everyone uses in China, there are a lot of businesses in it, and things like ordering pizza or a taxi in China are now actively happening through WeChat. And this shows that certain interactive scenarios of human and business communication really work well, it is convenient for both parties.

And those usages that were hype a couple of years ago - like you can communicate with a bot as a person and he will offer the best version of a flight to an airplane - well, that really doesn’t work very well.

And we are implementing something close to WeChat, but in other markets: in the first place, in the USA, although all over the world too. We have a fairly large number of customers from Europe, and in countries near China, too, many now use Facebook Messenger.

- Turning to the topic of growth: how long has the company appeared, and how has it grown from that moment to our time?

- The company appeared in 2015. It began with the fact that its co-founder Mikael Jan needed to do a newsletter on Telegram (then there were no channels there yet). He realized that it was quite complicated, and a special tool would be useful. As a result, Michael and Anton Gorin first made a platform for creating bots in Telegram. The platform began to grow quickly enough, they hit the startup accelerator in the Valley.

And while they were in the accelerator, Facebook opened the API for Messenger. And that was the moment when they decided to make a sharp pivot, to make a new product specifically for Facebook Messenger. The monthly audience of Messenger is 1.4 billion people, and on Facebook many companies have their representations in the form of official pages. And for these pages you can create bots.

Initially, there were three employees: Michael, Anton and another developer who made the very first version of the frontend. In the fall of the same year, the first investments were received and it became clear that you can begin to expand the team. Then I and three other developers came to the company, so at the end of 2016 there were seven of us. And now, two years later, there are already more than fifty of us, and growth continues.

If you look at the numbers of the platform itself, then we already have more than 400,000 connected bots. And we are growing well in terms of financial indicators: already at the moment we are a profitable company, while we continue to search for investments in order to grow even more actively. Next year we plan to double at least in terms of the number of people.

- Startups are a very experimental field where much is done by trial and error (like the mentioned pivot, when we started with one concept, and then changed on the go). How does this affect development? Does this mean that you always need to be prepared for the situation "the feature you implemented will be thrown out"?

- Indeed, there is such a thing that you can do some feature, but in the end it will not be in demand by users, it will have low adoption. Or she may not get to production at all, because we ourselves, looking at what happened, will understand that we don’t like it.

To minimize the number of such situations, the very first thing we think about (not even during development, but at the beginning of product development of a feature) is motivation. Why are we doing it, for whom, how much will it affect existing users, how much do we like it ourselves (will we be glad and proud that such a thing has appeared in our product). Having decided on the motivation, perhaps by conducting surveys in our user community or some other interviews with our users, we begin to develop. Next, we prepare the feature for sprinting, such a process is called PBR (Product Backlog Refinement): first it goes to the backlog, then it goes up there in the rating, and at some point it, already well described, may fall into the sprint.

Directly in the sprint, the first thing we do is if we do not understand how it will look, we make some mock-ups and prototypes. But, no matter how strange it may sound, sometimes it is already done with the development. Because sometimes it’s very difficult to understand how the user will feel with the interface, simply by making some kind of layouts and drawing illustrations.

Quite often, at the front end, we make prototypes or interactive features that, in principle, already work, you can click on and feel them. And then, in close work with designers, we bring these prototypes to an option that will go into production. But, nevertheless, when creating these prototypes here, it’s also not uncommon when you make it, look, and you understand yourself “no, it won’t stop, it’s inconvenient”. We try to use our own product, make bots, so that even before our users find out where some problems may arise. Well, in general, we focus on user experience, we are trying to build the most easy-to-use platform.

- With the rapid growth of the company, you probably come across the fact that processes that worked for several people cease to work when moving to dozens of people. How has your development changed from an organizational point of view?

- It was complicated. At the beginning of the year, we had a rather difficult situation, when we did several features for several months, they were constantly able to “finish it a bit and roll it into production”, but this “still a little bit” didn’t come.

When we first started, there were seven of us. We had a scrum, there were sprints, everything was built and was going well enough. When we grew up to 20-30 people, we, like in many companies, appeared functional teams: backend, frontend. With its own processes, with its own sprints inside, with its own task queues. And we did not do tasks that are specifically called "such and such a feature that will bring such and such a benefit to such and such a user." The tasks of each team were called in the spirit of “frontend: to rearrange such a piece of the interface so, add some button”.

And that was bad for many reasons. First of all, when we have many different queues and pieces of the same business task, they have different priorities, it becomes almost impossible to understand when the task will be completely ready. And it becomes more difficult for a specific developer to understand what he is doing. Because he makes some piece described for him, and how users will then rejoice at the result, he does not know, because he may not even know in many ways why all this is necessary.

At some point, we realized that this is impossible next. Yes, you can tune a little, iterate, continue to carry out sprints and daily stand-ups (which began to take longer than half an hour, because they were attended by the whole team, but which did not give anything). But these are cosmetic measures that do not solve the main problem.

And at that moment one of the guys in the company informed us that there was such a thing called LeSS or Large-Scale Scrum: a scrum for already large and growing teams. After sitting for several evenings in the meeting rooms, discussing everything that was going on at all, CEO and CTO (Mika and Anton) made a very difficult business decision: we will throw the entire development process (how we design features, implement and roll out) into the trash. We will finish the sprint now going on, and then we will build everything anew.

The decision was difficult, and realizing that we were doing this, we thought for a long time: “Damn, will it work or not?” But we decided to try it all the same, turning to the book on LeSS and to certified trainers. They started in a new way, made cross-functional teams - at the start there were three of them. We launched short weekly sprints according to the LeSS rules (rules in the sense of what set of meetings should be on these sprints). I will not tell all the details, but for the first weekly sprint of the eight tasks that seem to hang on us that we could not roll out for several months, we rolled out in production, if not all, then most of it. And we just did not understand what was happening. How so? Why couldn't we do this before? And why did it happen? It was very cool and we began to move on, take on new tasks,

Of course, there were some difficulties and misunderstandings too. But on the whole, probably, for most of the team, the emerging process is very popular, because the time to market for our features has been significantly reduced, you can do everything very quickly, roll out to production. And besides this, we try to convey feedback from our users so that developers can see how much people like what they do.

Another interesting point was how we roll out the frontend after we switched to LeSS. We realized that we are now divided into separate cross-functional teams, and the first time (at least before the front-end community starts working), we will communicate much less. And we learned to roll out the frontend any time “at the click of a finger”, when we need it ... We had one single meeting before the start of a new sprint, where we said that we have our main branch, and it can be rolled out at any time . Before that, I had thoughts that we should definitely build a system of integration UI tests that would check every assembly, that there should be a huge percentage of coverage, and only if it is “green” we can roll. But it was a pipe dream, because the product is growing very fast, and in this case, no matter how hard you try, you still won’t have time to keep a huge percentage of coverage. As a result, having agreed with all the developers and giving them this responsibility, we managed to make it so that now the code from our main branch really always works and we can always just take and roll out any assembly we need from there.

- Wow, thanks for the detailed answer. I would like to assume that, in addition to the transition described, a transition from “full stacking” to a narrow specialization was also to take place: when only a few people do everything in the project, willy-nilly have to do a variety of things, and when more than fifty, everyone has a clear circle tasks. This is true?

- When we were few, we really had to solve many problems from different areas. For example, for some time I was engaged in system administration and set up a CI system. And now, with the transition to LeSS, this is much less.

But this does not mean that now everyone is locked in narrow roles. When you come to the company, you have the main competence (be it at least a back-end, at least a designer), and no one will stop you from pumping exactly this vertical into space, but at the same time, LeSS provides an opportunity (just an opportunity) to develop in related directions .

We are divided into small standard scrum-teams in which there are six (plus or minus three) people who are gathered together and sit next to adjacent tables. This means that the front-end can always communicate with both the back-end and the designer. Besides the fact that cool communication is built in this way, you can also learn from these guys. And we welcome if the person who is involved in the front, for example, for this sprint wants to take on some small backend task and pump this area. Because the more knowledge you have from different areas, the more you focus on the whole product, and then you better manage to solve your problems. When you begin to understand why designers do this, why product experts do it, sometimes you can start building an interface yourself, which you then simply show them, and they say “yes, cool". And, accordingly, you can do your job faster.

- Startups are at the forefront of progress. Does this mean that when choosing technologies you can easily drag something completely new into production? And are there any precautions so that this does not turn into a pursuit of “shiny new things” that could harm companies?

- The short answer is yes, a supernova, cool and interesting is possible, we welcome this in every way. But, of course, there are certain criteria for the introduction of new technologies.

If you find any technology that interests you, then you need to bring it to the community. Although we no longer have a front-end team in our company, there is a front-end community in which we periodically gather and discuss such issues. There you can tell everyone why it is great and why it will be easier to live with it in the future. Some companies probably have some kind of specific selection system, a complicated table with comparisons that needs to be filled out. We don’t have anything like that, all decisions are made at the level of some very subjective sensations, but at the same time, really good and interesting technologies appear quickly enough.

Sometimes there are things that have not yet reached the release. We started using the library to create panels in React, when it was still raw enough, and, as far as I remember, even a little bit there was donated. We started using Babel 7 with some kind of beta because it allowed us to build the project a little faster than the previous one.

And, probably, no one in the team ever complained that he wanted some new cool thing, but they said to him: “No, we have such a policy, we will not do that.” And while I can not recall a single problem that would cause such an approach, welcoming new interesting technologies. It is very strange for me, because, in my previous experience, I made many wrong decisions at this level. But in ManyChat, maybe just with the help of the community, maybe for some other reason, we don’t have these files when we chose something, and then we had to take and rewrite half the code base to another technology, because this one has not entered.

- More about the "tip of progress": I want to assume that a startup allows you to calmly breathe "you don’t have to deal with a legacy code." This is true?

- Well, everyone understands the word "legacy" in their own way. If we mean by it, for example, a code older than three years, then in a company under three years old, of course, it is not. But you can tighten this concept, then we will have some percentage of legacy code. From the point of view that it was written not three years ago, but only a few months ago, but then we did not know how to do something correctly, but now we have learned, we can do a hundred lines instead of a thousand, and they will do the same is even more reliable. Such code, of course, is, it is inevitable. But there is nothing for which we would have to look for some “bearded developers”, because only they know this programming language, and we cannot refuse it.

- How much does startup development contribute to “bicycle building”? While giant companies are doing everything inside, aren't you up to it? Or is a startup just such a place where everyone does their own thing?

- For us, business value comes first. We are already profitable, but if we slow down and start losing to someone, it will be very painful. Therefore, if third-party development is consistent with business requirements, solves business problems, and it does not have any big problems, then we can safely take and use it. And if some dissatisfaction arises when using it, we set ourselves the task of technical debt that we want to do it ourselves cooler and better. But the most important thing is to close the task from the very beginning and give our customers the required features.

- And how does active growth affect the technologies used in development? How often does it happen that something “outgrows”?

- Well, rapid growth is more about the backend. Our backend employees face a nearly double load every month, they have to scale everything, add iron somewhere, speed something up. And at our front-end everything is much simpler: there are more new users, but each of them comes with his own hardware and launches our application in his browser.

But there are changes. The first version of ManyChat was immediately on React, but we used the Baobab library to store the state. This is such an implementation of the immutable tree, and all this was connected with React through a custom binding with actions. From the layers of abstraction there was actually a view with React, custom actions and a store with Baobab. It was not very convenient, a lot of things were missing, and in principle, immersing in it was also quite difficult.

Therefore, in 2017, we decided to take the technologies known to us and widespread in the front-end. We left React, added Redux with a small middleware suite for it - took Thunk and wrote some of our own for working with the backend via the Fetch API. Reducers and selectors have been added to the layers of abstraction, and we have been living with this core for two years now. In principle, everything completely suits us, and the application grows in functionality, but remains good, responsive.

- Since startups solve problems that they did not solve before, technological tasks in them may turn out to be not the ones that everybody faces every day. Did you have something different from the “regular” frontend?

- We have a tool for visual programming of interaction schemes between the subscriber and the bot, we call these schemes Flow, and the tool itself is Flow Builder. Here you can see how it looks:



It turned out that creating a responsive and smooth map interface with zoom, panning and a large number of objects can not do without 2D graphics. As a result, our Flow Builder technically works on PixiJS, the universal renderer for WebGL / Canvas.

In Russia, this technology is mostly familiar to game developers. But since we are not a game dev, we have our own specifics. In PixiJS games, each time after rendering, it pulls requestAnimationFrame and draws constantly. If we do the same, the user will leave the laptop with the tab open for half an hour, and when he returns, he finds that the laptop is dead. Moreover, the user’s laptop can be completely non-gaming (I had a 12-inch MacBook then, which cannot boast of performance, I tested it on it). In general, I had to look for different solutions so that everything was smooth and fast on it, while not discharging the laptop.

As a result, for all geometry elements and everything that we use, we made our proxy wrappers that register some changes, plus made our handler wrappers for various browser events, and made it possible for us to render only when it is necessary. It so happened to make actually a fairly quick and convenient tool for 2D-drawing.

- And how much do such tasks complicate life in comparison with the "typical"? For example, did you encounter in this situation that Google does not give answers to questions?

- Well, I would like to say, of course, that everything was terribly complicated, and no one has done it before us ... Yes, most services remain within the native HTML, and when you have to go to Canvas and WebGL to draw a significant part of the interface, there are difficulties . But choosing Pixi, we made a pretty good choice.

We then studied a large number of technologies: checked a lot of libraries that just draw on Canvas, took some other renders under WebGL. But Pixi turned out to be the fastest and most convenient for us, and most importantly, there is a fairly large community around it. The guys are actively willing to answer questions, help fix bugs or find some workarounds. We didn’t even have to contribute, but on a few issue that we opened on GitHub, they answered very quickly, told what and how to do.

Problems, however, arise because on Canvas you are left without everything that HTML and CSS give. You have to write all the layout and layout yourself manually in coordinates, there is no Flexbox and no block layout, and layout takes a lot of time. There is no work with text and user input. In the near future we will have input fields directly on Canvas, this is done through a hack: when you click on this text on Canvas, textarea is drawn on top of it, it scales via CSS scale and emulates approximately the same position and the same text size, and the user remains unnoticed: he writes something in Canvas, but in fact, a layer in HTML is drawn on top of it.

Another interesting thing was that I had to remember the math. For example, Pixi makes it possible to draw some lines, Bezier curves, our objects on the Flow Chart are connected by such smooth lines. But they considered it not very necessary to make these lines somewhat interactive, so that standard events worked for them: mouse hovering, clicks, and so on. And in order to calculate the area that the line occupies, we had to recall mathematics, trigonometry and learn to draw polygons around Bezier curves to create these interactive areas. It was fun.

- The last question. Probably, among the readers of the interview there are developers who do not understand how much work in a startup would suit them. From the interview they could already draw some conclusions, but would you like to tell them something else?

- Probably, a startup is good for those who are willing to constantly learn. If you want a quiet job, when you have learned to do one thing and are ready to repeat it over the years with minor changes, this is not about us. Here you always have to develop, learn something new, apply new technologies.

And one more thing: it will sound like a cliche, but if you want to change something in the world and achieve something, then this is just for startups, those places where new products or technologies are created. I personally like the state of things that has developed with us, very much to my liking. But at the same time, I have great respect and understanding towards the people who build and support existing products, some kind of large volume enterprise solutions. This is also great, this is a huge job, which also affects a large number of users and every day makes their life easier, better, more convenient. But still, if you want development, if you want achievements, then I think it's about a startup.