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

Далее вы увидите стадии взросления компании (по моему субъективному мнению) и их особенности, а также я постараюсь выделить, на что обращать внимание — как руководителю, так и рядовому сотруднику. 

Чего не будет — точных алгоритмов, как решать те самые проблемы в процессе взросления компании и команды. Об этом подготовлю отдельную статью с примерами и планом действий. Так что подписывайтесь, если вам интересна эта тема.

Попробуйте собрать БИНГО из этих ситуаций. И также не забудьте проголосовать, какая стадия ближе вашей компании сейчас.

P.S. Бонусный опрос про крУжки не менее важен.

Немного обо мне

Всем привет. Меня зовут Александр, и я работаю руководителем отдела разработки в компании Каруна. Кроме того, в прошлом я инжиниринг менеджер, тимлид и Java разработчик. Хотя почему в прошлом. Если надо, могу и закодить. Но как ответственный технический менеджер стараюсь этого не делать.

С чего вдруг решил поделиться своими мыслями?

Натолкнула меня на эту статью пара книг: “The Manager's Path” от Camille Fournier и "Principles" от Ray Dalio. В них я узнал отчасти себя, свой путь, и то, как руководитель должен строить процессы вокруг.

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

Как всё началось

В один момент я сел обновлять своё резюме на линкедине (периодически это делаю, чтобы через год не забыть, чем интересным я занимался) и понял, что вся моя карьера в хронологическом порядке идёт от “обратного пути” развития компании.

Что я имею в виду? Наверно, переход от компании большой и стабильной к небольшой и более живой, что ли.

Но давайте рассмотрим жизненный цикл “абстрактной продуктовой” компании.

Стадии “любой” продуктовой компании*

Зародыш стартапа

Сначала пара идейных людей собрались и организовали стартап. Как это обычно выглядит?

Код пишется на том, на чём умеют его основатели, скорее всего, не тестируется и сразу релизится в прод. Процессы — потом. Главное — получить рабочий MVP, чтобы начал приносить первую прибыль. И это правильно: если будешь долго запрягать, выискивая подходящие фреймворки и подходящих людей, либо конкуренты обскачут со своим решением, либо инвесторы разочаруются и вложат свои деньжата в какой-либо процветающий бизнес.

Собственно, стартап

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

Тут начинается интересное. Людей нанимают в спешке,
ведь нужно ещё быстрее выпускать фичи, быстрее поднимать новые сервисы, БД и
так далее. Тестирование?

Не у всех так, но буду подавать более утрированно. Я же статью пишу, а не мемуары?

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

Поставка фич регулярная, без остановки на регрес, а/б тесты и прочее. Лишь бы докрутить решение и обойти конкурентов по самому вырвиглазному дизайну или по объёму фич, доступных юзеру.

Стартап-переросток

Следующая фаза — фаза осознания, что всё самое логичное и местами нелогичное уже реализовали, вышли в топ-10 продуктов в данном сегменте, и с каждым днём разработка становится всё сложнее, система начинает давать сбои, а юзеры всё больше жалуются на баги. На данном этапе, если собственники всё-таки решили не продаваться, то возникает вопрос: а что дальше?

Стоит ли безостановочно пилить фичи или попытаться разобраться с проблемами быстрого роста? Денег-то вроде заработали, стабильный поток прибыли есть, и, наверно, пора задуматься о будущем. Тут начинается самое интересное. Эксперименты.

Поизучав проблемы и, наверно, наняв нового СТО/СРО или ещё какого-либо С, компания видит, что команда разработки в 30-50 человек сама себе мешает, упускает простейшие баги ввиду отсутствия тестирования как такового, постоянно ломает себе мастер из-за отсутствия нормального релизного процесса, и так далее. Список проблем может быть запредельный, и это — только процессные вещи. Уж проблемы с масштабированием инфры типа кластеров кубера или кафки я описывать не буду. Это решается тоже не одним днём.

Посмотрев на это всё, новый менеджер (ну, или старый, которого отправили на супер тренинги к известному коучу) приходит к собственникам и говорит, что тут нужен Скрам (без него вообще никак), или что-то ещё аджайлоподобное, но с чёткими традициями, желательно готовым фреймворком, который надо натянуть на всю эту команду.

Люди отошли от дел, могут поверить на слово прокаченному менеджеру и дают добро. Как говорится, поехали.

Франкенштейн

Фаза промежуточная. Самое интересно начинается тут.

Компанию будет шатать как никогда не шатало. Ведь за скрамом последуют самые последние тренды на рынке: кроссфункциональные команды, парное программирование, требование Т-шейп к разработчикам, переписывание всего и вся на модный молодежный го/котлин и тд, а может даже, начнут внедрять low-code решения. Если доберутся до миграции из ДЦ и своих БД в облака, будет вообще огонь. Но, как я и писал раньше, статья не про это.

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

Середнячок

Далее молодая продуктовая компания, пережив смутные времена, приводит дела в порядок и находит СВОИ процессы. Почему свои? Да потому, что ни один скрам при попытке натянуть его бездумно надолго не останется. Если люди не дураки и не будут следовать каким-то жёстким требованиям очередного Аутсорс Скрам супер-пупер коуча, то вскоре поймут, что их компания уникальна, и им нужно где-то чуточку свободы, где-то немножко хаоса, чтобы взбодриться, ну или где-то прибить жёсткими регламентами некоторые аджайл процессы (как бы тупо это ни звучало). На этом этапе люди, потратившие месяцы и годы труда на то, чтобы всё это выровнять, очень надеются выдохнуть. Хочется пожить, так сказать, в удовольствие и полюбоваться полученным результатом. Но не тут-то было.

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

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

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

Кому повезёт, получают премии, новые должности, а, может даже, и какие-никакие опционы/акции.

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

Ко всему прочему на этом этапе из-за количества команд начинает меняться организационная структура. Количество тимлидов начинает зашкаливать, руководители отделов не справляются с огромным потоком 1-1, квартальных планов и прочего. Так появляются различные промежуточные позиции типа Engineering Manager, Engineering Director. Их названия и их количество может отличаться. Где-то появляются отдельные Трайбы, а где-то целые кластера из этих трайбов.

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

На этом же этапе начинает формироваться деление продукта на направления развития (не зря же столько менеджеров и директоров назначили), или же компания решает диверсифицировать свой бизнес и выпустить на рынок пару новых продуктов.

Тут пути таких компаний расходятся, хотя и не сильно.

Первые делают упор на свой бренд, пытаются спихнуть с рынка конкурентов, купив их, или выпустив новую киллер-фичу. Могут начать локализацию продукта на новые гео, выходят на рынки других стран, меняя название бренда и делая с десяток дочек.

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

Крупнячок

Вот и все, компания становится гигантом, в ней больше 1000+ сотрудников, и это только технический отдел. Процессы на этом этапе, скорее всего, опять подверглись изменениям ввиду масштабирования. Но если концепты управления заложили правильные изначально, и корпоративная культура не превратилась в одно требование работать в офисе с 10 и до 18, то сильно бюрократизироваться не должно. Базой для дальнейшего развития служит сильная команда менеджеров, которая сможет сплотить команды, не засыпая их горами денег, и которая будет вовремя выруливать в различных кризисных ситуациях.

Корпорация

Фаза N+1 — это годы работы и усилий во всех направлениях сразу. Основатели Гугла, Фейсбука и прочих мета-корпораций могут написать трехтомник по тому, сколько они пережили и сколько раз принимали неверные решения, но все же достигли своего текущего состояния. У меня нет опыта работы в настолько больших корпорациях, поэтому на этом шаге я не буду фантазировать и буду закругляться.

Саммари

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

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

Поэтому мой посыл прост: развивайтесь вместе с компанией, не будьте якорем (и душнилой).

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

P.S.

Если говорить о себе, то прямо сейчас я работаю в некотором “середнячке” по тем меркам, что я описал. Ну или “почти середнячке”. Так что часть болей мне знакома не понаслышке. За последний год мы запустили много изменений (от аджайл трансформации до распила монолита) и собрали много обратной связи. Я сам был и на стороне инициаторов и на стороне тех, кому уже досталось исполнять решения. Мне повезло, что вокруг много неравнодушных людей: кто не готов бросать дело на полпути, и не кидается из крайности в крайность. Рецепт наших успешных трансформаций — это сильная команда и баланс между продуктом, процессами и технологиями.

А что насчет вас? На какой стадии сейчас находится ваша компания? Уже раздаете кружки за лояльность?