Leading a Team with AI — Dmitry Tverdokhlebov

Dmitry starts with an obstacle he repeatedly encounters at large clients: the wish to keep all information inside the organization and reproduce cloud model capabilities within that boundary. In his experience, this can slow adoption more than technical complexity. He explicitly acknowledges that his client sample is weighted toward large corporations; smaller businesses often move more flexibly. Omnius.team therefore starts with problems where information flows from outside the company inward. It gathers external material, analyzes it, and delivers a useful result without initially needing sensitive internal data. Alexander challenges the limits of this approach: a successful side project does not automatically transform the core business. Dmitry says the pilot must reach decision makers. Once they see a working result, they can provide sponsorship, resources, and a path through further approvals. The next stage still involves preparing interfaces, documentation, and integration into the client’s environment. The agency may supervise the architecture while another team performs the implementation.

Three examples illustrate this entry point. For an oil company, the team monitors tax legislation across countries of operation, combining public information and paid databases into relevant updates for finance specialists. A second tool helps create Telegram advertisements: it examines the business and channel content, estimates whether proposed copy will pass moderation, and suggests alternatives. The guest does not disclose a consistent numerical measure of business impact, so the conversation cannot substantiate a specific conversion uplift. A third system explores substitutions between construction materials. Sixteen agents examine engineering, financial, legal, and other constraints, with additional critics challenging intermediate conclusions. Dmitry compares 30–40 minutes of system work with a month of work by two or three analysts. This is his estimate of effort saved, not an independent benchmark or demonstrated incremental revenue. For a manager, the useful distinction between these cases lies in the problem chosen, the information available, and the way value becomes visible to the client.

The agency has nine people, and Dmitry deliberately limits its growth: his goal is to employ no more than ten by the end of the year. He treats the first hires as the people who establish the future culture. Broad areas of work go to independent specialists without detailed daily supervision. An internal assistant, Omnius, helps maintain coordination. It has access to work calendars, email, and meeting recordings, with restrictions around sensitive topics. It retrieves agreements, remembers commitments, and helps identify what people are waiting for. Linear tasks emerge as a reflection of discussions; the purpose is to reduce dependence on the founder’s memory. Yet Dmitry rates the organization only three or four out of ten against his own desired state. The system is useful, but he does not present a finished management model. Scaling it to dozens or hundreds of employees remains a hypothesis: he expects shared context to become more valuable when personal relationships no longer provide sufficient coordination.

The assistant’s rules evolve through actual mistakes. A salary discussion in a one-to-one meeting must not appear in a public team channel, for example, and the bot should join a discussion when the question is genuinely directed at it. This connects to a shift in engineering work: when generated code contains a defect, the engineer should also correct the instructions and conditions that produced it. Reading code still matters because the output needs verification. Alexander extends the argument: if implementation can be regenerated, knowledge about the system must live in requirements, architecture, decision rationale, and checks, rather than only in the current code. Rebuilding a component and verifying its behavior can test whether that knowledge is complete. This is an engineering direction, not a claim that any system can safely be rewritten with one request. An organizational assistant likewise needs to learn the rules of its particular workplace. Both speakers stress that there is no ready recipe: a practice that works elsewhere must be tested against the people, processes, and constraints of the adopting team.

Dmitry describes three hiring signals. First, candidates should have tried solving their own problems with generative AI, even when an experiment failed. He values that experience over polished résumé language. Spending on tools is a personal signal of engagement in his account, not a universal qualification standard. Second, people need to express a thought clearly, define the problem and desired outcome, and lay out the steps toward it. Systems thinking and critical thinking help them question model output. Third, he looks for motivation to build useful things and compatibility with the team’s culture. He does not condemn people driven primarily by money, but considers that motivation less suitable for his own agency. Technical skills can be developed; a fundamental mismatch in how someone treats people and approaches work is harder to change. These are one founder’s criteria for choosing colleagues, and they do not replace assessing the capabilities required for a specific role.

Talant.club proposes a separate model for small and medium-sized businesses that cannot afford a boutique agency. The platform gathers vetted AI engineers, supports knowledge exchange, and turns a client’s vague need into a technical specification. Several teams can submit working solutions. AI performs an initial check against the specification, while the client chooses the winner using their own criteria, which might include speed, accuracy, usability, or appearance. As Dmitry describes it, the winning team receives half the budget; the remainder is shared among participants after a small platform operating fee. The community has five people at the time of the conversation, making this an early initiative rather than a proven model at scale. The idea draws on his experience with service marketplaces such as YouDo and Yandex Services: cheaper software production allows suppliers to compete with completed results instead of promises. The conversation does not explain the arrangements for ongoing maintenance. The final recommendation to managers is similarly practical: personally solve one small problem with AI, then use that experience to inform larger changes.