Skip to content
back to the episode
Episode summary2026CTO

How Dmitry Kushnikov Went Back to Engineering and Became Manychat’s CTO and COO

Dmitry Kushnikov had already been a CTO when he joined Manychat as a backend developer. In conversation with Alexander Polomodov, he recalls what failed startups taught him, how Manychat chose to build for marketers, and why the company’s growth led engineers to take ownership of quality and changed the scope of the CTO role.

Code of Leadership · S2E30 · Episode 889 min read

This summary condenses the episode. Examples and assessments reflect the participants’ experience.

The main thread of the material
01

What engineers learn by moving between projects

Kushnikov started at a web studio, where he could put what he learned about PHP to use right away. They compare that path with an internship at a large company, where a new hire can count on onboarding and a progression framework. Kushnikov prefers environments where he can test ideas and make mistakes quickly. He values stability when people have limited room to risk their time or income.

When a project where he had switched stacks closed, his job search exposed a gap. He had yet to build enough experience for a senior role in the new language, and PHP had moved on while he was away. He spent six months back at a web studio. This time he brought design practices from the previous project into his work with PHP 5. The return gave him a place to combine what he had learned in two different settings.

02

Strong engineering and weak demand

On a project to build a second brain, Kushnikov and a colleague paired on major changes. One wrote the code while the other thought through the decision, and then they swapped. He recalls that pairing sped up their work because they could settle difficult decisions together. Combined with test-driven development, it made the project a formative engineering experience. Yet the release attracted too few users to sustain funding. The team seriously explored who would use the product only in its final months.

A job interview exposed another version of the problem. Given a dossier on two factories, Kushnikov was asked where to invest. He compared the options and overlooked the possibility of keeping the money. His calculations helped him choose between the factories as presented. Once he included the status quo, the question changed to whether the expected result justified taking the investment risk at all.

03

Where the commission model broke down

A group-buying service helped organizers aggregate orders from several buyers. The founders kept payments outside the platform and planned to earn a commission. That left organizers in control of the transactions on which the company depended for revenue. Kushnikov also recalls legal difficulties structuring the commission. Keeping the rate low was part of the service’s appeal, which left the founders little room to adjust.

04

Returning to code and choosing whom to build for

Dmitry had already led engineers when he applied for a backend job at Manychat. He wanted to write code again and learn how the product worked inside a small company. There was no leadership opening for him at the time. He connects that choice to a broader career question. When changing industries or countries, keeping the same level can be difficult, and familiar work gives you a way to learn the new environment.

The team started with broadcasts on Telegram and then moved into Facebook Messenger when it launched a bot platform. Flow Builder, a visual automation editor, was a major early release. Its workflows resembled a programming language under the hood, but the editor constrained what users could do to fit marketers’ needs. This gave the team a test for new features. Would they help a marketer automate communication with an audience? Kushnikov credits that focus with giving users a reason to pay. The company later added Instagram, which had become its primary channel by the time of the conversation.

05

How growth changed engineering responsibilities

As the product grew, Kushnikov helped hire engineers, took charge of development, and eventually became CTO. The technical co-founder focused on architecture and infrastructure. Dmitry recalls that posting vacancies and waiting for applications got them only so far. Established employers already had a name in the market, so Manychat started talking about its engineering work at conferences.

Growth also changed how teams divided the work. The head of QA helped transfer responsibility for quality to the engineers themselves. Dmitry describes it as owning the result across the entire delivery process. Around the same time, the company moved from Scrum to LeSS, an approach to organizing several teams around one product. The episode treats them as two changes from the same period, when Manychat was rethinking where quality checks happen and how teams coordinate product development.

06

When values become assessment criteria

When the group was small, people could agree on how to work in person. As Manychat grew, the team held a series of working sessions to articulate shared values, including care for quality, results for customers, and collective success. Those principles made their way into interviews, feedback, and performance reviews. Dmitry singles out care for quality. He cares about the outcome and how people go about achieving it.

Assessment brings a side effect. Alexander invokes Goodhart’s law. When an observable behavior becomes a target, people learn to display it. Dmitry wants people to have room to work out what a principle means and apply it to the situation. He recalls a small group that chose how to try AI tools and how to check the results. The leader’s job in that setting is to describe where the team is going and give people room to work out how to get there.

07

How operations became part of the CTO’s job

The move into operations began before the title changed. Kushnikov helped build the people function and later took on analytics. To learn an unfamiliar area, he spoke to people at other companies, asked them for introductions, and explained to candidates what product and team Manychat wanted to build. Running the Moscow office gave him experience he could draw on when the team relocated and opened offices in Yerevan, Barcelona, and Amsterdam.

International expansion meant rebuilding hiring and relationships with candidates. Dmitry credits co-founder Mike Yan’s trust with giving him the confidence to take on work at that scale. He could make a mistake and still count on support. Kushnikov tries to give his team the same latitude. People who put their energy into avoiding every mistake are less likely to try a new way of working.

08

Why engineers were given time to experiment with AI

Flow Builder executes a workflow according to predictable rules. Generative AI changes that property when its output becomes part of a customer conversation. Kushnikov says early AI experiments had uses internally, but the quality of the responses still stood in the way of using them externally. Marketers and creators were using Manychat to talk to their audiences, where a poorly judged message carried more risk than it did in an internal experiment.

By the time of the recording, the company had paused much of its product development to give engineers time to experiment with AI on their own. Dmitry wants people to start with work they understand and can check. They can then bring that experience into the team and use it to decide which features to offer customers. The results of the experiment were still to come.

Takeaways

What to take away

  1. 01A specific audience gives a team a way to draw product boundaries. Flow Builder gave marketers the freedom to build workflows from a set of actions they could understand.
  2. 02Values guide people when they understand which decisions those values can inform. Scoring a visible behavior gives people an incentive to reproduce the behavior itself.
  3. 03Trying AI internally helps a team learn how to check the output and what is at stake before putting a feature into customer conversations.

Sources