Эта статья окажется полезной для основателей стартапов на ранних стадиях, которым кажется, что у них есть проблемы с построением инженерной команды, мотивацией и управлением результативностью инженеров, структурированием работы и проектов, расстановкой приоритетов, выпуском продукта в срок.

Суть вот в чём: если вам кажется, что у вас есть эти проблемы, вероятно, правильное решение — ничего с этим не делать, не заниматься управлением и вернуться к продукту и общению с пользователями. Иначе говоря, с учетом моего опыта управления командами разных масштабов, я не считаю, что основателю стоит тратить время на «управление» инженерами на такой ранней стадии.

В следующих разделах я разберу самые типичные антипаттерны, с которыми сталкивался, и покажу, на что лучше потратить время, если вы оказались в одной из таких ситуаций.

Не пытайтесь «мотивировать» своих инженеров

Распространенная тревога многих основателей — убедиться, что инженеры действительно много работают. Это может выражаться в переработках, более интенсивной работе, чем у конкурентов, героическом переписывании кодовой базы и так далее. Когда таких внешних признаков усилий вроде бы не видно, основатели начинают переживать, что команда «не мотивирована», и появляется соблазн лечить симптомы вместо причин. Например:

• формировать культурную норму длинного рабочего дня — в духе «культуры 996», — либо требуя этого напрямую, либо публично поощряя;

• ставить регулярные или несрочные встречи на выходные, например субботние стендапы;

• заниматься микроменеджментом отдельных задач или просить сотрудников присылать отчеты о статусе и другие доказательства того, что они действительно работали.

У этих антипаттернов есть общий признак: они начинаются с того, что основатели пытаются активно что‑то сделать, чтобы мотивировать команду. Этот подход может повлечь за собой два неприятных последствия:

1. Такой подход может вытолкнуть из вашей инженерной культуры именно тех инженеров, которых вы хотите удержать, — тех, у кого есть большой выбор. Я знаю нескольких инженеров из условного топ-1% в Кремниевой долине, которые прекращают участие в найме, как только слышат про 996 или что‑то подобное.

2. Вы тратите когнитивные силы не на ту проблему.

Мотивация — врожденная характеристика сильных стартап‑инженеров. Ваша единственная задача — нанять таких людей, а затем поддерживать среду, в которой им хочется хорошо работать.

О том, как именно распознавать мотивацию при найме, я напишу отдельную статью. Но если коротко, обращайте внимание на следующее:

• самое очевидное — подтверждения того, что человек действительно проявлял эти внешние признаки мотивации на прошлых местах работы, причем без принуждения;

• признаки стойкости в карьере и жизненном пути: как человек реагировал на трудности, ставил ли он на кон свои прошлые успехи или репутацию ради нового вызова;

• интеллектуальное любопытство: хобби, увлечения и «гиковские» интересы, о которых человек может говорить с настоящим азартом;

• склонность быстро переходить к действию и высокая скорость принятия решений.

Наконец, как основатель вы точно должны быть самым мотивированным человеком в команде — причем по‑настоящему. Для кого‑то это героический рывок в коде, для кого‑то — созвоны с европейскими клиентами в два часа ночи, для кого‑то еще что‑то свое. Развивать собственную внутреннюю мотивацию — самый эффективный способ задать тон всей команде.

Не нанимайте менеджеров слишком рано

Самый заметный внешний признак того, что стартап переключился с создания продукта на построение компании, — появление управленческих ролей. Когда такой переход происходит преждевременно, много энергии уходит на проблемы, не соответствующие текущей стадии компании.

По определению инженерный менеджер должен управлять командой и проектами. Но если команда все еще пытается понять, что именно ей нужно строить, управлять пока нечем. Даже самый интеллектуально честный менеджер начнет производить «управленческую работу»: проводить со всеми встречи один на один, заниматься карьерным наставничеством, наводить порядок в хаосе потенциальных функций, раскладывая их по тикетам или задачам в JIRA, и так далее. Для вас как для основателя это означает следующее:

• вы все еще пытаетесь найти соответствие продукта рынку (product‑market fit) и собрать первую версию продукта;

• инженерный менеджер помогает вам делать это более эффективно, но он оптимизирует движущуюся цель, поэтому существенного улучшения это не дает;

• вы не понимаете, в чем проблема: этот инженерный менеджер плохо справляется со своей работой, инженеры недостаточно результативны, продукт не востребован на рынке — или всё это сразу.

Как тогда определить, что значит «слишком рано»? Разберем несколько типичных переломных моментов, предполагая, что хотя бы один из основателей — технический специалист.

Этап основания компании: 5–6 инженеров, включая основателей

Очевидно, что на этом этапе слишком рано нанимать менеджеров или переводить кого‑то в менеджерскую роль. Единственные управленческие задачи основателей — найм и увольнение. В остальном команда в значительной степени должна быть самоорганизующейся и самодостаточной, с легковесными инструментами: трекером задач может быть простой документ, встречи один на один происходят по необходимости и нечасто, и так далее.

В целом установка должна быть такой: ничего не делать в части управления и делать все возможное в части найма выдающихся людей, которые по своей природе хорошо работают вместе.

Этап нескольких команд: 2–3 команды по 5 инженеров, всего 10–15 человек

Это может быть поздняя посевная стадия или Series A, когда уже есть намек на работающий продукт. Многие команды решают внедрять управление именно на этом этапе, потому что это кажется естественным следующим шагом. В таком решении много нюансов, но я бы настоятельно рекомендовал, чтобы все инженеры по‑прежнему подчинялись одному человеку — в идеале CTO‑сооснователю. Почему? В первую очередь из‑за скорости исполнения и культуры:

• при 15 инженерах одному человеку вполне реально держать в поле зрения работу каждого и обеспечивать согласованность действий;

• это критический момент, когда вы формируете инженерную культуру, которая должна провести вас от текущей точки к сотням инженеров: как мы нанимаем, что мы ценим, как мы работаем вместе и так далее. Делать это гораздо проще в плоской команде с одним лидером;

• пивоты и радикальные решения все еще могут происходить часто, а проводить инженеров через такие изменения будет экспоненциально сложнее, если управлять ими через двух‑трех линейных менеджеров.

Единственный нюанс, который я бы добавил: если вам действительно нужно начинать структурировать команду, выбирайте гибридные роли. Например, это может быть очень вовлеченный в практическую работу менеджер, который все еще пишет код 70% времени. Или можно повысить нескольких ключевых инженеров до неформальных позиций технических лидов.

Ранний этап роста: переход от 20 к 50 инженерам

Это та точка, где польза от добавления управленческого слоя и более четкой структуры должна перевешивать издержки от неизбежного хаоса, который в большой команде начинает жить собственной жизнью. Но даже здесь я настоятельно рекомендовал бы подход «лучше меньше, да лучше».

Вот несколько признаков, что вы дошли до этой стадии:

• CTO или тот, кто управляет всей командой, начинает выгорать под нагрузкой;

• добавление новых инженеров больше не увеличивает результат, то есть вы уперлись в неэффективность команды;

• команда отлично справляется с результатом на горизонте недели, но никто, похоже, не способен просчитать, что будет через 3–6 месяцев.

Это большая тема, и я посвящу этой стадии отдельную статью, в том числе о том, как нанять первого руководителя разработки.

Не копируйте Google

В этом разделе речь пойдет о двух сторонах одной медали. Обе связаны с гало‑эффектом, который возникает вокруг великих компаний и, в частности, вокруг их управленческих практик:

• применение управленческих идей, о которых рассказывал Google или другая успешная компания и которые они сделали популярными;

• применение метаидеи о том, что в управлении тоже нужно заниматься инновациями, как в свое время это делал Google.

Сразу перейду к выводу, а ниже объясню:

если сомневаетесь, всегда выбирайте «Node и Postgres» в качестве стека управления. Не изобретайте новое, придерживайтесь классики.

Что я имею в виду под «Node и Postgres» в управлении

У Node и Postgres есть общие черты: огромные сообщества, ошибки и особенности, которые уже изучили миллионы людей, поэтому для стартапов на ранней стадии это отличный выбор по сравнению, скажем, с C++ и OracleDB. Что бы вы ни думали об их технических достоинствах, будет очень сложно указать на них как на причину провала стартапа. Это просто надежные, скучные инструменты, которые работают на ранней стадии.

Такой же тип скучных, широко распространенных и соответствующих стадии инструментов стоит использовать и в управлении стартапом. Каждая единица «инноваций», которую вы тратите на организационную структуру, подход к названиям ролей или новомодные встречи один на один, — это единица внимания, которую вы не тратите на продукт. На посевной стадии ваша культура должна быть уникальной не из‑за хитроумной системы обратной связи между коллегами, а из‑за скорости, с которой вы решаете проблемы клиентов.

Что входит в скучный стек управления на посевной стадии

В завершение этого раздела и всей статьи я хочу, как ни парадоксально, перечислить несколько управленческих действий, которые действительно полезны именно на ранней стадии. Почти все они строятся на одном и том же «неохотном» подходе к инженерному управлению. На мой взгляд, для такой стадии это здоровый лидерский подход.

• Нанимайте людей с внутренней мотивацией: см. первый раздел.

• Не пытайтесь выстраивать управление так, чтобы компенсировать ошибку найма. Быстро и корректно расставайтесь с такими людьми.

• Асинхронные обновления статуса: не внедряйте все ритуалы Scrum — стендапы, ретроспективы и прочее — целиком. А если внедряете, оставляйте их асинхронными. У устного обновления статуса мало дополнительной ценности, даже если вам приятно думать, что люди действительно работают и вовремя приходят на стендап.

• Сдержанное отношение к Slack: хотя Slack сегодня воспринимается как данность в распределенных и гибридных командах, он быстро может превратиться в поглотитель внимания, особенно для инженеров, которым нужно время на сконцентрированную работу. Держите это под контролем.

• Встречи один на один должны быть по потребностям, а не регулярными: пусть они будут ситуативными и привязанными к конкретным темам, а не инструментом поддержания отношений, как это часто бывает в корпоративном мире.

• Неструктурированные документы вместо систем учета: если вам не нужно детально фиксировать задачи для аудита, несколько документов в Notion или Google Docs вполне могут масштабироваться на 10–15 инженеров, особенно с учетом современных AI‑инструментов. У них очень низкие накладные расходы, и по гибкости с ними сложно конкурировать.

• Предельная прозрачность: дайте всем доступ ко всему — заметкам по звонкам с клиентами, обновлениям для инвесторов, бюджетам и так далее. Так вы не только укрепите доверие внутри команды, но и уберете необходимость «коммуницировать» в менеджерском смысле: фильтровать и перерабатывать информацию. А это типичная управленческая задача.

Для ясности: многие из этих практик не масштабируются за пределы 20–25 инженеров. Но в этом и есть часть смысла.

Если после этой статьи вы поймали себя на мысли «кажется, у нас тоже часть проблем лечат не там», посмотрите открытые уроки OTUS на близкие темы. На них разбирают похожие ошибки: когда команда буксует не из‑за «немотивированных инженеров», почему переход из кода в управление часто ломается об лишние ритуалы и как не подменить работу с продуктом разговорами о процессах.

• 20 мая 20:00. «Системная диагностика команды и группы команд». Записаться

• 2 июня 20:00. «От кода к людям: как вырасти в руководителя команды и не возненавидеть свою работу». Записаться

• 3 июня 19:00. «Про кастдевы с интерактивом / исследование потребителей в теории и на практике». Записаться

Уроки бесплатные и проходят в рамках онлайн‑курсов. Можно познакомиться с преподавателями‑практиками, задать вопросы и проверить, где в вашей команде действительно проблема: в людях, процессах, продукте или стадии роста.