Сидишь ты такой в корпорации, команды менеджишь, рассуждаешь, где правильно проводить границу их зон ответственности. И всё у тебя “по уму”: архитекторы, бекендеры, фронтенедеры, куэй, девопсы, а если совсем большой и взрослый, то и всякие скрам мастера, эджайл коучи и девелопер адвокаты. И решаешь, что познал дзен управления командой разработки и можешь делиться опытом. И вдруг к тебе приходит человек, у которого один фулл-стэк разработчик, а все остальные технари или на аутсорсе, или парт-тайм. И возникает вопрос — а вам вообще есть о чем поговорить? Мне кажется, что есть.

Во-первых, именно то, что каждая из перечисленных ролей — это своя зона ответственности, важно подсветить. Пока один единственный человек, отвечает за весь ваш сервис с технической точки зрения, вам придётся постоянно разрываться между условно удобством интерфейса, доступностью фичей в апи и найденными на проде багами. Но в какой-то момент вы закоммититесь перед клиентами на 99.99% аптайм и придёт время выделять девопс-задачи (админские, если вам так привычнее) в отдельного человека. Или придёт время пилить новый навороченный интерфейс и выделенная команда фронтенда приобретёт смысл.

И тут мы переходим к во-вторых. На мой взгляд, очень важно иметь в голове несколько картинок будущей структуры команды, чтобы принимать тактические решения уже сейчас. Представьте, что вы нашли инвестора и у вас есть возможность расширять команду настолько, насколько вы посчитаете нужным. Как вы её построите? Сколько людей какой специальности будет в команде? Какие руководящие роли появятся? Чего вы ждёте от каждой из этих ролей? Ваши текущие разработчики смогут до них подрасти или придётся искать на рынке? Чтобы ответить на все эти вопросы, вам придётся очень серьёзно закопаться и в суть вашего продукта, и в то, как работают те или иные люди. Поверьте, работать в рамках имеющихся ограничений во много раз проще, чем придумать и обосновать то, как вы будете работать, когда эти ограничения будут сняты. Зато, когда вы это сделаете, вы будете не беспорядочно нанимать людей, когда без них уже нет возможности потушить пожар, а будете постепенно идти в направлении той команды мечты, которая у вас уже описана. Но самое главное, когда вы нарисуете эту картинку с большой вероятностью у вас возникнут вопросы — а что мне мешает вот этот важный шаг сделать прямо сейчас? Или, например, а как мне уже сейчас начать растить хорошего тимлида внутри команды?

Ну и третье. Когда у тебя небольшая команда, ты, как менеджер, всегда перегружен. Из-за этого взгляд замыливается и расфокусируется. Короткий разговор с человеком со стороны помогает лучше для себя самого сформулировать то, что болит сильнее всего. А заодно получить на это свежий взгляд. Конечно, не всегда найдётся готовое простое решение. Но иногда даже одно ощущение того, что эти проблемы совершенно обычные, другие люди тоже с ними борются и справляются, уже заряжает энергией на то, чтобы продолжать свой непростой путь.