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

We all roughly imagine how the development looks in a large company and how the development can differ from a small one. And what happens if the size of the company is changing rapidly, and the number of employees for a couple of years increases tenfold? When a startup is growing rapidly, and it is necessary to adapt to new circumstances on the move, how does this affect everything (from processes to technology)?

In our conference, HolyJS will take part the company ManyChat , which is just what happens. Therefore, we asked the technical development of the frontend of Evgeny Kuvshinov and specifically about ManyChat, and in general about what it is to engage in (frontend) development in a startup.
')
- First, tell us briefly what you do in ManyChat, and what the company itself does.

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

As a company, we are helping businesses use a 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 trying to emulate human interaction, but about scenarios where this is not required. With the help of our bots, you can simply do mailings, and you can set up more complex interactive things like bookings, reservations, loyalty programs. They are also made visually and clearly, and this can be done either by a fairly advanced business owner, or by a marketer without programming skills.

You can see how bots in Messenger work in general, with a specific example: just to HolyJS, we made a special bot .



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

- Yes. Perhaps most of all the expediency is proved not even by our case, but by the WeChat platform. This is an instant messenger that almost everyone uses in China, there are a lot of businesses in it, and such things as ordering a pizza or a taxi are actively taking place in China via WeChat. And it shows that certain interactive scenarios of communication between a person and a business really work well, it is convenient for both parties.

And those yuzkeys that were HYIPs a couple of years ago - like the fact that you can communicate with the bot as a person and he will offer the best option for a flight on a plane - well, it really does not work very well.

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

- Turning to the topic of growth: how long did the company appear, and how did it grow from that moment to our time?

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

In the meantime, 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 just for Facebook Messenger. The monthly audience of Messenger is 1.4 billion people, and on Facebook a lot of companies have their representative offices in the form of official pages. And for these pages you can create bots.

Initially, there were three employees: Mikael, Anton and another developer who made the very first version of the frontend. In the autumn of the same year, the first investments were received and it became clear that one could begin to expand the team. Then I and three other developers came to the company, so at the end of 2016 we were seven. And now, two years later, there are already more than fifty of us, and the 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: currently we are a profitable company, while continuing to look for investments in order to grow even more actively. Next year we plan to at least double the number of people.

- Startups are a very experimental area, where a lot is done by trial and error (like the aforementioned pivot, when we started with one concept, and then changed it on the fly). How does this affect development? Does this mean that you always have to be ready for the situation “the feature you implemented will be thrown out”?

- Indeed, there is such that you can make some kind of feature, but in the end it will not be in demand by users, it will have a low adoption. Or she may not get to production at all, because we ourselves, looking at the result, will realize that we do not like it.

In order to minimize the number of such situations, the very first thing we think about (not even in development, but at the beginning of product development, features) is motivation. Why do we do it, for whom, how much will it affect already existing users, how much do we like it ourselves (will we be happy and proud that such a thing has appeared in our product). Having decided on motivation, perhaps, having conducted surveys in our user community or some other interviews with our users, we will start the development. Next, we are preparing a feature for the sprint, such a process is called PBR (Product Backlog Refinement): first, it gets into the backlog, then rises there by rating, and at some point it, already well described, can get into the sprint.

Directly in the sprint, the first thing we do is, if we don’t understand how it will look, we make some kind of mockups and prototypes. But, however strange it may sound, sometimes it is already done with the development. Because sometimes it is very difficult to understand how the user will feel with the interface just by making some layouts and drawing illustrations.

Quite often on the front end we make prototypes or interactive features that, in principle, are already working, they can be called and felt. And then, in close cooperation with designers, we bring these prototypes to the version that goes into production. But, nevertheless, when creating these prototypes, this is also a frequent occurrence, when you make it, you look, and you understand “no, it will not go, it is inconvenient”. We try to use our own product, make bots, so that even before our users find out where any problems may arise. Well, in general, we focus on user experience, trying to build the most simple to use platform.

- With the rapid growth of the company, you are surely faced with the fact that the processes that worked for several people stop working when you switch to dozens of people. How did your development change from an organizational point of view?

- It was complicated. At the beginning of the year, we had a rather difficult situation, when we had already done several features for several months, they were always able to “finish a little more and roll out into production”, but this “still a little” did not come.

When we started, we were seven people. We had a scrum, there were sprints, everything was built and went on quite well. When we grew to 20-30 people, we, like many companies, had functional teams: backend, frontend. With their processes, with their sprints inside, with their queues of tasks. And we didn’t do the tasks that are specifically called “such a feature, which will benefit such and such a user”. The tasks of each team were called in the spirit of "frontend: to overturn this way a piece of the interface, add some button."

And it was bad for many reasons. First, when we have many different queues and pieces of the same business task are in them with different priorities, it becomes almost impossible to understand when the task will be completely ready. And it becomes more difficult for a particular developer to understand what he is doing. Because he does some piece described for him, and how the users will be happy with the result later, he doesn’t know, because he may not even know in many ways why all this is needed.

At some point, we realized that it was impossible to go on like this. Yes, you can gradually tyunit, iterate, continue to carry out sprints and daily stand-ups (which have already started to take more than half an hour, because the whole team was present, but they 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 brought to us the information that there is such a thing, which is called LeSS or Large-Scale Scrum: scrum for already large and growing teams. After sitting a few nights in negotiations, discussing everything that is happening here, the CEO and CTO (Mika and Anton) made a very difficult business decision: we will throw the whole development process (as we design features, implement and roll out) into the trash. Let's finish the sprint that is going now, and then build it all over again.

The decision was difficult, and realizing that we are doing this, we still thought long enough: “Damn, will it work out or not?” But we decided to try it anyway, turning to the book on LeSS and certified trainers. We started in a new way, made cross-functional teams - there were three at the start. We launched short weekly sprints according to the rules of LeSS (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 eight tasks that seemed to hang on us, which we have not been able to roll out for several months already, we rolled out into production, if not all, then most. 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 new puzzles, solve them in cross-functional teams much faster.

Of course, there were some difficulties and misunderstandings too. But on the whole, probably, most of the team is very pleased with the emerging process, because we have significantly reduced time to market for features, we can do everything very quickly, roll out into 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 rolled out the front end after we switched to LeSS. We realized that now we are divided into separate cross-functional teams, and the first time (at least before the front-end community works), we will communicate much less. And we learned to roll out the frontend at any time “at the click of the fingers” when we need it ... We had one single meeting before the start of the 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 must build an integration UI test system that will check every build, that there should be a huge percentage of coverage, and only if it is “green” can we roll. But it was some kind of unrealizable dream, because the product is growing very fast, and in this case, no matter how hard you try, you still don’t have time to hold a huge percentage of coverage. As a result, having agreed with all the developers and having given them this responsibility, we managed to make sure that now the code from our main branch really always works and we can always just take and roll out any assembly that we need.

- Wow, thanks for the detailed answer. I would like to suggest that, in addition to the described transition, there was also a transition from “full stack” to narrow specialization: when only a few people do everything in the project, they have to do various things willy-nilly, and when there are more than fifty, each has a clear circle tasks. This is true?

- When we were few, we really had to solve many problems from different areas. For example, I spent some time a little and did 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 everyone is now locked in narrow roles. When you come to the company, you have the core competence (even if it’s a backender, even a designer), and no one will stop you from pumping this particular vertical into space, but at the same time, LeSS gives you the opportunity (exactly the opportunity) to develop in adjacent 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 side by side at adjacent tables. So, the fender can always communicate with the back-tender, and with the designer. Besides the fact that in this way cool communication is built, you can also learn from these guys. And we welcome if a person who is engaged in the front, for example, wants to take some small backend task for this sprint and pump this area. Because, the more knowledge you have from different areas, the more you focus on the entire product, and then you are better able to solve your problems. When you begin to understand why designers do this, why productologists do it, sometimes you can start building an interface yourself, which you will then simply show them, and they will say “yes, great”. And, accordingly, you can do your work 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 it does not turn into a pursuit of "shiny new things" that could harm the company?

- The short answer: yes, supernovae, cool and interesting can be, we strongly welcome it. But, of course, there are certain criteria for the introduction of new technologies.

If you find some technology that you are interested in, then you need to bring it to the community. Although we do not have a front-end team in the company anymore, there is a front-end community in which we periodically gather and just discuss similar issues. There you can tell everyone why it’s great and why it will be easier for us to live with it in the future. Some companies probably have some specific selection system, a complicated table with comparisons that needs to be filled. We have nothing 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 quite quickly.

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

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

- More about the "edge of progress": I would like to assume that the startup allows you to quietly sigh, "you will not have to deal with the Legacy code." This is true?

- Well, the word "legacy" everyone understands in his 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 does not exist. But it is possible to toughen this concept, then we will have a certain percentage of Legacy code. From the point of view that even if it was written not three years ago, but only a few months ago, but then we did not know how to do something right, but now we 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 the development in a startup contribute to “cycling”? While the giant companies are doing everything inside, you don’t care? Or is a startup just a place where everything is done in its own way?

“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 major problems, then we boldly take it and use it. - - , , . — - .

— , ? , - «»?

— , — . , , , , - , - . : , .

. ManyChat React, Baobab. , React . view React, store Baobab. , , .

2017 . React, Redux middleware – Thunk Fetch API. , . , , , , .

— , , , . -, «» ?

— c , Flow, — Flow Builder. , :



, , 2D-. Flow Builder PixiJS — WebGL/Canvas.

. , . PixiJS requestAnimationFrame . , , , , . ( 12- MacBook, , ). , , , .

, , -, - , - , , , . 2D-.

— «»? , , ?

— , , , , , … , HTML, Canvas WebGL , . Pixi, .

: , Canvas, - WebGL. Pixi , , . , - . , issue, GitHub , , , .

, , , Canvas , HTML CSS. , Flexbox layout', . . Canvas, : Canvas, textarea, CSS scale , : Canvas - , HTML.

, . , Pixi - , , Flow Chart . - - , : , . , , , , . .

— . , , , . - , - ?

— , , . , - , . , - , .

: - -, - - , , , . , , . , , - -. , , , , . -, , , , .